GNU bug report logs - #28258
26.0.50; [PATCH] Let file-name-base succeed when buffer-file-name is nil

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28258 in the body.
You can then email your comments to 28258 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mohammed Sadiq <sadiq <at> sadiqpk.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50;
 [PATCH] Let file-name-base succeed when buffer-file-name is nil
Date: Mon, 28 Aug 2017 07:52:22 +0530

[Message part 1 (text/plain, inline)]

Let file-name-base succeed when buffer-file-name is nil.

Hi. This is my first patch to GNU Emacs. Please let me know if it is
sensible or not.

Thanks

[0001-Let-file-name-base-succeed-when-buffer-file-name-is-.patch (text/x-diff, inline)]

From efb4f12c9083ad3930eaf5da8929d4e6b33609eb Mon Sep 17 00:00:00 2001
From: "Mohammed Sadik P. K" <sadiq <at> sadiqpk.org>
Date: Mon, 28 Aug 2017 07:34:25 +0530
Subject: [PATCH] Let file-name-base succeed when buffer-file-name is nil

FILENAME is an optional argument for file-name-base.  So it shouldn't
fail when no filename is associated with current buffer.

* lisp/files.el (file-name-base): Don't fail when buffer-file-name
is nil.
---
 lisp/files.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/files.el b/lisp/files.el
index 872fc46e87..d75d402545 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -4467,8 +4467,9 @@ file-name-extension
 (defun file-name-base (&optional filename)
   "Return the base name of the FILENAME: no directory, no extension.
 FILENAME defaults to `buffer-file-name'."
-  (file-name-sans-extension
-   (file-name-nondirectory (or filename (buffer-file-name)))))
+  (let ((filename (or filename (buffer-file-name))))
+    (and filename
+        (file-name-sans-extension (file-name-nondirectory filename)))))
 
 (defcustom make-backup-file-name-function
   #'make-backup-file-name--default-function
-- 
2.11.0

[Message part 3 (text/plain, inline)]

In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-08-27 built on rose
Repository revision: 853ed4533bbddf16c50ad12ed1db70fa252715fb
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.1 (stretch)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
delete-backward-char: Text is read-only

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LIBSYSTEMD

Important settings:
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95499 5650)
 (symbols 48 20292 1)
 (miscs 40 43 93)
 (strings 32 28804 1235)
 (string-bytes 1 763186)
 (vectors 16 14660)
 (vector-slots 8 492593 5734)
 (floats 8 49 67)
 (intervals 56 217 0)
 (buffers 992 12))

Message #8 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28258 <at> debbugs.gnu.org
Subject: Re: bug#28258: 26.0.50;
 [PATCH] Let file-name-base succeed when buffer-file-name is nil
Date: Tue, 29 Aug 2017 11:54:55 -0400

Mohammed Sadiq wrote:

> * lisp/files.el (file-name-base): Don't fail when buffer-file-name
> is nil.
[...]
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -4467,8 +4467,9 @@ file-name-extension
>  (defun file-name-base (&optional filename)
>    "Return the base name of the FILENAME: no directory, no extension.
>  FILENAME defaults to `buffer-file-name'."
> -  (file-name-sans-extension
> -   (file-name-nondirectory (or filename (buffer-file-name)))))
> +  (let ((filename (or filename (buffer-file-name))))
> +    (and filename
> +        (file-name-sans-extension (file-name-nondirectory filename)))))

Hi, and thanks for the patch.
IIUC: file-name-base currently errors when called with no applicable
file name, and you want it to instead return nil? This seems rather
unusual for an Emacs file-related function. I would have thought this
unlikely to be applied, but maybe you could explain why you want it?

Message #11 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Mohammed Sadiq <sadiq <at> sadiqpk.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28258 <at> debbugs.gnu.org
Subject: Re: bug#28258: 26.0.50; [PATCH] Let file-name-base succeed when
 buffer-file-name is nil
Date: Tue, 29 Aug 2017 21:40:31 +0530 (IST)

> On August 29, 2017 at 9:24 PM Glenn Morris <rgm <at> gnu.org> wrote:

> Hi, and thanks for the patch.
> IIUC: file-name-base currently errors when called with no applicable
> file name, and you want it to instead return nil? This seems rather
> unusual for an Emacs file-related function. I would have thought this
> unlikely to be applied, but maybe you could explain why you want it?

The signature of `file-name-base' is (file-name-base &optional FILENAME).
That is, the FILENAME argument is optional. So I believe it shouldn't
be an error to not give the optional argument. And so calling the function
in a buffer with no file associated shouldn't be an error. I'm not sure
if my assertion is right.

Feel free to do what it is felt to be right. :)

Message #14 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28258 <at> debbugs.gnu.org
Subject: Re: bug#28258: 26.0.50;
 [PATCH] Let file-name-base succeed when buffer-file-name is nil
Date: Tue, 29 Aug 2017 13:02:31 -0400

Mohammed Sadiq wrote:

>> IIUC: file-name-base currently errors when called with no applicable
>> file name, and you want it to instead return nil? This seems rather
>> unusual for an Emacs file-related function. I would have thought this
>> unlikely to be applied, but maybe you could explain why you want it?
>
> The signature of `file-name-base' is (file-name-base &optional FILENAME).
> That is, the FILENAME argument is optional. So I believe it shouldn't
> be an error to not give the optional argument. And so calling the function
> in a buffer with no file associated shouldn't be an error. I'm not sure
> if my assertion is right.

Thanks for explaining. I don't think I agree, but then the fact that the
argument is optional and defaults to buffer-file-name also seems
atypical to me (eg I don't think any other file-name- functions behaves
like that). Let's wait and see if anyone else feels strongly one way or
the other.

Message #17 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28258 <at> debbugs.gnu.org
Subject: Re: bug#28258: 26.0.50; [PATCH] Let file-name-base succeed when
 buffer-file-name is nil
Date: Mon, 18 Sep 2017 17:12:36 +0000

[Message part 1 (text/plain, inline)]

Glenn Morris <rgm <at> gnu.org> schrieb am Di., 29. Aug. 2017 um 19:03 Uhr:

> Mohammed Sadiq wrote:
>
> >> IIUC: file-name-base currently errors when called with no applicable
> >> file name, and you want it to instead return nil? This seems rather
> >> unusual for an Emacs file-related function. I would have thought this
> >> unlikely to be applied, but maybe you could explain why you want it?
> >
> > The signature of `file-name-base' is (file-name-base &optional FILENAME).
> > That is, the FILENAME argument is optional. So I believe it shouldn't
> > be an error to not give the optional argument. And so calling the
> function
> > in a buffer with no file associated shouldn't be an error. I'm not sure
> > if my assertion is right.
>
> Thanks for explaining. I don't think I agree, but then the fact that the
> argument is optional and defaults to buffer-file-name also seems
> atypical to me (eg I don't think any other file-name- functions behaves
> like that). Let's wait and see if anyone else feels strongly one way or
> the other.
>
>
>
>
Changing from raising an error to returning nil is a breaking change:
callers currently can rely on the return value being never nil, and can
rely on errors being raised. Changing this would break these assumptions.
Even ignoring that, I think raising an error is the right thing to do:
unless given a filename, the function can't fulfil its promise, and raising
an error is the most appropriate reaction to this. (There are already way
too many Elisp functions that silently ignore errorneous situations.)
I do agree that the calling convention of `file-name-base' is odd. How
about making the argument mandatory (initially only by changing the
advertised calling convention and the docstring)?

[Message part 2 (text/html, inline)]

Message #20 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 28258 <at> debbugs.gnu.org, Mohammed Sadiq <sadiq <at> sadiqpk.org>
Subject: Re: bug#28258: 26.0.50;
 [PATCH] Let file-name-base succeed when buffer-file-name is nil
Date: Mon, 18 Sep 2017 20:41:52 -0400

Philipp Stephani wrote:

> Changing from raising an error to returning nil is a breaking change:
> callers currently can rely on the return value being never nil, and can
> rely on errors being raised. Changing this would break these assumptions.
> Even ignoring that, I think raising an error is the right thing to do:
> unless given a filename, the function can't fulfil its promise, and raising
> an error is the most appropriate reaction to this. (There are already way
> too many Elisp functions that silently ignore errorneous situations.)

I think you've summarized things very well.

> I do agree that the calling convention of `file-name-base' is odd. How
> about making the argument mandatory (initially only by changing the
> advertised calling convention and the docstring)?

Sounds good to me.

Message #23 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28258 <at> debbugs.gnu.org, Mohammed Sadiq <sadiq <at> sadiqpk.org>
Subject: Re: bug#28258: 26.0.50; [PATCH] Let file-name-base succeed when
 buffer-file-name is nil
Date: Tue, 19 Sep 2017 08:31:29 +0000

[Message part 1 (text/plain, inline)]

Glenn Morris <rgm <at> gnu.org> schrieb am Di., 19. Sep. 2017 um 02:41 Uhr:

>
> > I do agree that the calling convention of `file-name-base' is odd. How
> > about making the argument mandatory (initially only by changing the
> > advertised calling convention and the docstring)?
>
> Sounds good to me.
>

OK, here's a patch.

[Message part 2 (text/html, inline)]

[0001-lisp-files.el-file-name-base-Make-FILENAME-argument-ma.txt (text/plain, attachment)]

Message #26 received at 28258 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28258 <at> debbugs.gnu.org, Mohammed Sadiq <sadiq <at> sadiqpk.org>
Subject: Re: bug#28258: 26.0.50; [PATCH] Let file-name-base succeed when
 buffer-file-name is nil
Date: Tue, 19 Sep 2017 08:46:30 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 19. Sep. 2017 um
10:31 Uhr:

> Glenn Morris <rgm <at> gnu.org> schrieb am Di., 19. Sep. 2017 um 02:41 Uhr:
>
>>
>> > I do agree that the calling convention of `file-name-base' is odd. How
>> > about making the argument mandatory (initially only by changing the
>> > advertised calling convention and the docstring)?
>>
>> Sounds good to me.
>>
>
> OK, here's a patch.
>

New version of the patch, with all callers and the manual fixed.

[Message part 2 (text/html, inline)]

[0001-Make-FILENAME-argument-of-file-name-base-mandatory.txt (text/plain, attachment)]

Message #31 received at 28258-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, 28258-done <at> debbugs.gnu.org
Cc: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Subject: Re: bug#28258: 26.0.50; [PATCH] Let file-name-base succeed when
 buffer-file-name is nil
Date: Sun, 24 Sep 2017 08:07:18 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 19. Sep. 2017 um
10:46 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 19. Sep. 2017 um
> 10:31 Uhr:
>
>> Glenn Morris <rgm <at> gnu.org> schrieb am Di., 19. Sep. 2017 um 02:41 Uhr:
>>
>>>
>>> > I do agree that the calling convention of `file-name-base' is odd. How
>>> > about making the argument mandatory (initially only by changing the
>>> > advertised calling convention and the docstring)?
>>>
>>> Sounds good to me.
>>>
>>
>> OK, here's a patch.
>>
>
> New version of the patch, with all callers and the manual fixed.
>

Pushed to master as 1eb4e5c3c8.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.