From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62732: 29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD Date: Mon, 10 Jul 2023 17:25:45 +0300 Message-ID: <83jzv7972u.fsf@gnu.org> References: <87h6tpn8d5.fsf@catern.com> <87edotn7sx.fsf@catern.com> <87edlhm6wq.fsf@catern.com> <87o7kklf9c.fsf@catern.com> <83r0pf9b7d.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29891"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@catern.com, monnier@iro.umontreal.ca, 62732@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 10 16:26:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qIrqJ-0007Sn-I1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jul 2023 16:26:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIrq2-0006O9-VL; Mon, 10 Jul 2023 10:26:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIrpz-0006Nl-7a for bug-gnu-emacs@gnu.org; Mon, 10 Jul 2023 10:26:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIrpy-0004PW-Tt for bug-gnu-emacs@gnu.org; Mon, 10 Jul 2023 10:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qIrpy-0004a9-7A for bug-gnu-emacs@gnu.org; Mon, 10 Jul 2023 10:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Jul 2023 14:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62732 X-GNU-PR-Package: emacs Original-Received: via spool by 62732-submit@debbugs.gnu.org id=B62732.168899914817592 (code B ref 62732); Mon, 10 Jul 2023 14:26:02 +0000 Original-Received: (at 62732) by debbugs.gnu.org; 10 Jul 2023 14:25:48 +0000 Original-Received: from localhost ([127.0.0.1]:48928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIrpj-0004Zg-Pe for submit@debbugs.gnu.org; Mon, 10 Jul 2023 10:25:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIrpe-0004ZM-RE for 62732@debbugs.gnu.org; Mon, 10 Jul 2023 10:25:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIrpX-0004LA-QK; Mon, 10 Jul 2023 10:25:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s2hARU43Ixusy/v2f+K2Z5HW68lWAv/i8oyXqZ4jFW4=; b=kZlDOJVxT9S5 cPlaNa+jDKmHIClFOaL/D4wvzAoDAkEN9eD3mGm2plsky5YrXBp/VT6inb+qSaCNZi0wKu0AlQhyb tRJfC8MMPNaqNGH3Jk/+pZgQ1+Rjnghp4wC1U81568ZgmMWDMIVOqyEPdHEcLwvGdAW5qjW32jXEE jze42V5kOLwi5RNJb9S8TcUNy8whHU+XEU/oLQf262EBJP5+3x1b6NAgdTi2sQhCAVhKTvINCxnBp m0WRCUdcBtQ+48lTjgzCqfCw0l3yci6MZRGbmP5Y/jApNOnXSBgfRqH5ntcoOXD7y6BoH5X/ycCjC ue7OTven0iqH2J8TrqSHOA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIrpX-0005sy-AN; Mon, 10 Jul 2023 10:25:35 -0400 In-Reply-To: (message from Spencer Baugh on Mon, 10 Jul 2023 09:39:10 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264891 Archived-At: > From: Spencer Baugh > Cc: sbaugh@catern.com, monnier@iro.umontreal.ca, 62732@debbugs.gnu.org > Date: Mon, 10 Jul 2023 09:39:10 -0400 > > Eli Zaretskii writes: > > >> - (setq buffer (create-file-buffer (directory-file-name dirname)))) > >> + (setq buffer (create-file-buffer dirname))) > > > > This seems to imply that callers of create-file-buffer will now have > > to remember to ensure the argument ends in a slash if it is the name > > of a directory. If so, I'd prefer that create-file-buffer did that > > internally, when its argument is a directory. Callers shouldn't know > > to much about the internals of the callee. > > I can (and should) add this to the docstring of create-file-buffer. It > seems intuitive to me that the last non-empty component of the filename > passed in by the caller is what create-file-buffer uses, including if > that "last component" ends in a slash. (It's a nice way to avoid the > additional DIRECTORY argument which says whether the filename is > intended to refer to a directory) If the only reason is to avoid an additional argument, I'd prefer an additional argument. Documenting a problematic design doesn't mean the design ceases to be problematic, and relies too heavily on people paying attention to subtle aspects of the documented behavior. > By doing this internally in create-file-buffer, you mean running > file-directory-p to see if the filename actually points to an existing > directory? I'm hesitant to do that: > > - That prevents running create-file-buffer to create a buffer to visit a > directory which does not yet exist (in the same way you can visit a file > which does not yet exist). dired doesn't currently support that but > other packages might want to. Didn't that problem exist before your changes? And anyway, if we want to support that, adding an extra variable, or even requiring the trailing slash only for non-existing directories, would be a better solution. > - Checking file-directory-p is what uniquify did which caused these bugs > in the first place, and I think this could partially recreate the same > bug, where we add a trailing slash just because there happens to be a > directory of the right name. (Although I'm not sure, just worried) I don't see why that would follow. It is a very minor change in the code, and doesn't affect the logic, AFAICT. > - It adds filesystem access to what is currently a pure function. But create-file-buffer is not documented as not hitting the disk, so I don't see a problem here. > > Does this changeset have any user-facing behavior changes? If so, > > they should be at least in NEWS. > > The only user-facing behavior change is fixing the two bugs mentioned in > the commit message. Is that appropriate to include in NEWS? Does the fix result in different buffer names? If so, it is not just a bugfix, it changes user-facing behavior.