From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <87k21o8m8x.fsf@rose> <1188947996.68721.1504023031457@webmail.mailhostbox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d688c068537055979da8a" X-Trace: blaine.gmane.org 1505754802 23205 195.159.176.226 (18 Sep 2017 17:13:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Sep 2017 17:13:22 +0000 (UTC) Cc: 28258@debbugs.gnu.org To: Glenn Morris , Mohammed Sadiq Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 18 19:13:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dtzbc-0005Xh-Ae for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Sep 2017 19:13:12 +0200 Original-Received: from localhost ([::1]:37969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtzbj-0001te-IC for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Sep 2017 13:13:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtzbX-0001r0-Vz for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2017 13:13:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dtzbS-0004zH-TO for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2017 13:13:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38057) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dtzbS-0004zA-Pd for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2017 13:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dtzbS-0002Bh-Hb for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2017 13:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Sep 2017 17:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28258 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 28258-submit@debbugs.gnu.org id=B28258.15057547768395 (code B ref 28258); Mon, 18 Sep 2017 17:13:02 +0000 Original-Received: (at 28258) by debbugs.gnu.org; 18 Sep 2017 17:12:56 +0000 Original-Received: from localhost ([127.0.0.1]:46738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dtzbM-0002BK-9l for submit@debbugs.gnu.org; Mon, 18 Sep 2017 13:12:56 -0400 Original-Received: from mail-io0-f179.google.com ([209.85.223.179]:44572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dtzbK-0002B6-5C for 28258@debbugs.gnu.org; Mon, 18 Sep 2017 13:12:54 -0400 Original-Received: by mail-io0-f179.google.com with SMTP id v36so3851023ioi.1 for <28258@debbugs.gnu.org>; Mon, 18 Sep 2017 10:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gAkLfqGy76O5Rs+qqAsHxl+eDheHpZ435V9VPedb9mM=; b=q/8J8NEdb8CMMV8CMTm6IUoTtL1nb+gHSjb4i/kTLmh79MqVeXcae6oUNi1FArV3Ia bdu7rlwDVlNwtzUd3fCpK3FsGJTQm39FisoSgN0DjSmFSAbDyQIHMsFBc8IPFnAAgsmm lacif4XxlcmDhPIBCQKoJ9jddLVXrKemHDfojDBA2aH4Dkrmlsh1MEpgsnnuM4RTTm3j w6m/ML6qXazFPu+EMdRdMl1o2/WH5v21dfrZiTcGuH+AyrejJbcXGJZTNmLmAy3bIX/z fIQFZIxbVfjkbqt0OcSu/y1/0xeeQmb8Fe+FMpFpKTRSZybQHbnL0xTuYPEQznwXnpyq sHjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gAkLfqGy76O5Rs+qqAsHxl+eDheHpZ435V9VPedb9mM=; b=sXVNUdcMs14+TWQT/sjq2mn7ziTO4YeBaDSwrr9RfzXNfK+xIC5aqmvpVMZtZcC/sz /inoh5lZdOxF56sYbl0XSR2xZFrOMiMUK3VwaghigUHuT2U92nV0p5QI5lnYYkXHOymA tklIfVIY/qxt4sRTYoWw+ZYMmlDRvZZeGNxhd3sGqmcfWJM6jyegyZDak6vXNe3gqH6N xQcRuLZ+l2NOhlNNi5q0QtyQVjNZv1BqVpMccwE6lIGXtnHoL5wKumBBJiQ9gXXDTnT8 4A+7LytiYmrHZ2W6pdr9aY6TwMpJ/j2L0iAGmrHdPkqjCB1oG7zh0BvknhdOgE5HcSoZ X8AA== X-Gm-Message-State: AHPjjUivNaIxOU4obkl35vZ0Onani5Cj1+QxitT+Ltx5SSFcj8RiGKUz oElvYCSKuidJo08j5rWf5mkjVTVfl4x/LtToNZ0= X-Google-Smtp-Source: AOwi7QDETW1n+5TohKl3Tr9E/JeFGkv/79HUHsqhUDj26Z6B5sOmGEEoZ8Cxf0U8fnR+p6E32ssOgGV5sxEcP88FdII= X-Received: by 10.202.66.196 with SMTP id p187mr11062301oia.52.1505754767327; Mon, 18 Sep 2017 10:12:47 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137067 Archived-At: --001a113d688c068537055979da8a Content-Type: text/plain; charset="UTF-8" Glenn Morris 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)? --001a113d688c068537055979da8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Glenn = Morris <rgm@gnu.org> schrieb am Di= ., 29. Aug. 2017 um 19:03=C2=A0Uhr:
Mohammed Sadiq wrote:

>> IIUC: file-name-base currently errors when called with no applicab= le
>> file name, and you want it to instead return nil? This seems rathe= r
>> unusual for an Emacs file-related function. I would have thought t= his
>> unlikely to be applied, but maybe you could explain why you want i= t?
>
> The signature of `file-name-base' is (file-name-base &optional= FILENAME).
> That is, the FILENAME argument is optional. So I believe it shouldn= 9;t
> be an error to not give the optional argument. And so calling the func= tion
> 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 th= e
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 retu= rning nil is a breaking change: callers currently can rely on the return va= lue being never nil, and can rely on errors being raised. Changing this wou= ld break these assumptions.
Even ignoring that, I think raising a= n 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 rea= ction to this. (There are already way too many Elisp functions that silentl= y ignore errorneous situations.)
I do agree that the calling conv= ention of `file-name-base' is odd. How about making the argument mandat= ory (initially only by changing the advertised calling convention and the d= ocstring)?
--001a113d688c068537055979da8a--