unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Spencer Baugh <sbaugh@janestreet.com>,
	62732@debbugs.gnu.org, sbaugh@catern.com
Subject: bug#62732: 29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD
Date: Wed, 12 Jul 2023 09:04:40 -0400	[thread overview]
Message-ID: <jwvttu9e1ip.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83pm4y79dw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 11 Jul 2023 18:31:07 +0300")

I'm not sure what to make of this discussion.

The issue at hand is the following: `create-file-buffer` needs to know
if the filename it receives is for a directory or not so it can decide
whether the buffer name should end in / or not according to
`uniquify-trailing-separator-p`.

I can see 3 ways to provide this info:

1- use `file-directory-p`.
2- add a boolean `directory` argument to `create-file-buffer`.
3- use the presence of a trailing directory separator in the filename.

Those 3 are very close to each other, in practice, so we're pretty much
in bikeshed territory.

My preference is (3) first, (2) second, and (1) last.

(1) is my least favorite because it makes it impossible/difficult to
create a "directory buffer" if `file-directory-p` returns nil and
vice versa, even tho I can imagine scenarios where this could be useful
(such as the scenario mentioned by Spencer where we want to create
a "directory buffer" for an archive that Emacs's file-name-handlers
don't understand).

(3) is my favorite because it doesn't need an extra argument and instead
uses an existing piece of information: if I pass "/a/b/c/" then it seems
clear that I mean this to be a "directory buffer" rather than a "file
buffer".  Representing the information "this is meant to be a directory"
in the file name via a trailing / is a standard practice in ELisp (and
POSIX in general), embodied by things like `file-name-as-directory` and
`directory-file-name`, so it seems only natural (or even a mere a bug
fix) to let `create-file-buffer` make use of that info instead of
throwing it away.

But I prefer any one of those 3 choices over the status quo, so I'll
stop arguing here.  Just let me know which one I should install.


        Stefan


Eli Zaretskii [2023-07-11 18:31:07] wrote:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  sbaugh@catern.com,
>>    62732@debbugs.gnu.org
>> Date: Tue, 11 Jul 2023 08:31:51 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > My comments assumed that indeed we will (almost) always want to tell
>> > create-file-buffer this is a directory.
>> 
>> One contribution, not intended to be exhaustive of all use cases, and
>> not intended to be definitively a good idea: a user could want opened
>> tar files with their file listing view to have a trailing slash, even
>> though they aren't actually directories.
>
> But users don't call create-file-buffer, do they?  So this is not
> user-level option, at least not directly so.
>
>> And with my approach that is possibly just by running
>> file-name-as-directory over the name before passing it to
>> create-file-buffer.
>
> If you worry about users, they can be told to append a slash by hand,
> when they mean a directory and that directory does not yet exist.  We
> do this elsewhere in Emacs.






  reply	other threads:[~2023-07-12 13:04 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-09  1:37 bug#62732: 29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD sbaugh
2023-04-09  1:49 ` sbaugh
2023-04-09 12:13   ` sbaugh
2023-04-21 20:59     ` sbaugh
2023-05-05  6:06       ` Eli Zaretskii
2023-07-03 18:54         ` sbaugh
2023-07-03 19:19           ` Eli Zaretskii
2023-05-05 20:30     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-08 17:48       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-09 14:49         ` sbaugh
2023-05-05 20:13   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-05 20:37     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-05 21:14     ` Spencer Baugh
2023-07-09 15:38     ` sbaugh
2023-07-09 16:15       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10  1:36         ` sbaugh
2023-07-10  2:04           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10  2:55             ` sbaugh
2023-07-10  3:38               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 12:57             ` Eli Zaretskii
2023-07-10 12:56           ` Eli Zaretskii
2023-07-10 13:39             ` Spencer Baugh
2023-07-10 14:25               ` Eli Zaretskii
2023-07-10 16:53             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 19:12               ` Eli Zaretskii
2023-07-10 19:18                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-11  2:25                   ` Eli Zaretskii
2023-07-11  2:55                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-11 12:01                       ` Eli Zaretskii
2023-07-11 12:31                         ` Spencer Baugh
2023-07-11 15:31                           ` Eli Zaretskii
2023-07-12 13:04                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-07-12 13:42                               ` Eli Zaretskii
2023-07-12 13:57                                 ` Spencer Baugh
2023-07-12 19:43                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13  4:50                                 ` Eli Zaretskii
2023-07-13 15:52                                   ` sbaugh
2023-07-13 16:02                                     ` Eli Zaretskii
2023-07-13 16:21                                       ` sbaugh
2023-07-17  5:03                                         ` Michael Heerdegen
2023-07-17 11:35                                           ` Eli Zaretskii
2023-07-18  4:13                                             ` Michael Heerdegen
2023-07-18 11:12                                               ` Eli Zaretskii
2023-07-13 21:51                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvttu9e1ip.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=62732@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=sbaugh@catern.com \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).