GNU bug report logs - #31872
27.0.50; nil is nil but maybe inside a list

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#31872: closed (27.0.50; nil is nil but maybe inside a list)
Date: Sat, 23 Jun 2018 07:41:01 +0000

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

Your message dated Sat, 23 Jun 2018 10:40:27 +0300
with message-id <83h8luuf10.fsf <at> gnu.org>
and subject line Re: bug#31872: 27.0.50; nil is nil but maybe inside a list
has caused the debbugs.gnu.org bug report #31872,
regarding 27.0.50; nil is nil but maybe inside a list
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
31872: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31872
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Tomas Nordin <tomasn <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; nil is nil but maybe inside a list
Date: Sun, 17 Jun 2018 12:51:37 +0200

Hello List

I was confused some day ago about the effect of providing an explicit
nil for a &rest argument in a call to a comint function. Reading the
documentation on argument lists I thought there might be some room for
improvement (or to make it easier to read).

Hoping I have not misunderstood the workings of &rest all along, what do
you think about this diff:

1 file changed, 8 insertions(+), 4 deletions(-)
doc/lispref/functions.texi | 12 ++++++++----

modified   doc/lispref/functions.texi
@@ -412,10 +412,14 @@ Argument List
 binds @code{a} and @code{b} to the first two actual arguments, which are
 required.  If one or two more arguments are provided, @code{c} and
 @code{d} are bound to them respectively; any arguments after the first
-four are collected into a list and @code{e} is bound to that list.  If
-there are only two arguments, @code{c} is @code{nil}; if two or three
-arguments, @code{d} is @code{nil}; if four arguments or fewer, @code{e}
-is @code{nil}.
+four are collected into a list and @code{e} is bound to that list.  So,
+if there are only two arguments, @code{c}, @code{d} and @code{e} are
+@code{nil}; if two or three arguments, @code{d} and @code{e} are
+@code{nil}; if four arguments or fewer, @code{e} is @code{nil}.  Observe
+that with five arguments with an explicit @code{nil} argument provided
+for @code{e}, that @code{nil} argument is collected into a list with one
+element (which is @code{nil}), as with any other single value for
+@code{e}---the @code{&rest} argument.
 
   There is no way to have required arguments following optional
 ones---it would not make sense.  To see why this must be so, suppose



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-12-17 built on fliptop
Repository revision: b4486de0c6484a09dcd6485c19062419279ca296
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9.4 (stretch)

Best regards
--
Tomas

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: 31872-done <at> debbugs.gnu.org
Subject: Re: bug#31872: 27.0.50; nil is nil but maybe inside a list
Date: Sat, 23 Jun 2018 10:40:27 +0300

> From: Tomas Nordin <tomasn <at> posteo.net>
> Date: Sun, 17 Jun 2018 12:51:37 +0200
> 
> I was confused some day ago about the effect of providing an explicit
> nil for a &rest argument in a call to a comint function. Reading the
> documentation on argument lists I thought there might be some room for
> improvement (or to make it easier to read).
> 
> Hoping I have not misunderstood the workings of &rest all along, what do
> you think about this diff:

Thanks, I made a similar change in the manual to clarify the
explanation.

Previous Next

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