Subject: Re: bug#74709: [PATCH] Avoid empty unique qualifier in buffer name
From: Eli Zaretskii <[email-masked]>
To: Manuel Giraud <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 21 Dec 2024 11:11:36 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> Cc: [email-masked]
> Date: Sat, 07 Dec 2024 11:04:14 +0100
> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> Visuwesh <[email-masked]> writes:
> 
> > [வெள்ளி டிசம்பர் 06, 2024] Manuel Giraud wrote:
> >
> >> Visuwesh <[email-masked]> writes:
> >>
> >>> [வெள்ளி டிசம்பர் 06, 2024] Manuel Giraud via "Bug reports for GNU Emacs,
> >>> the Swiss army knife of text editors" wrote:
> >>>
> >>>> Tags: patch
> >>>>
> >>>> Hi,
> >>>>
> >>>> This patch prevents from having an empty unique qualifier in the buffer
> >>>> name.  Maybe this could happen with others file buffer as well but, most
> >>>> of the time, you could witness it with Dired buffer in homedir.  Here is
> >>>> a recipe:
> >>>>
> >>>>   - emacs -Q
> >>>>   - C-x d /ssh:somewhere: ;; This buffer is named "~</ssh:somewhere:>"
> >>>>   - C-x d /~/             ;; This buffer is named "~<>"
> >>>>
> >>>> With this patch, the last buffer will simply be named "~" instead.
> >>>
> >>> I usually have ~/tmp visited in a Dired buffer.  Sometimes I also visit
> >>> /tmp which gets named as "tmp<>".  With this patch, /tmp's buffer is
> >>> named "tmp" instead.  This confuses me as I am used to seeing "tmp" for
> >>> ~/tmp's Dired buffer more often than not.  Can we gate this new
> >>> behaviour behind a user option please?
> >>
> >> I don't think that there is more confusion then if you only have /tmp
> >> opened which will have its buffer named "tmp", no?
> >
> > Sorry, I meant having /tmp being "tmp" when both ~/tmp and /tmp are open
> > is confusing for the aforementioned reason.
> 
> Yes, you're right.  Thinking a bit more about it, I don't think this
> patch was a good idea anymore.  When a buffer is named "tmp<>" it
> conveys the information that there is another buffer with the same base
> name.  If it is just named "tmp", we have lost this bit of information.

Thanks.  Since there were no further comments withing 2 weeks, I'm now
closing this bug.