emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#31872: closed (27.0.50; nil is nil but maybe insid


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#31872: closed (27.0.50; nil is nil but maybe inside a list)
Date: Sat, 23 Jun 2018 07:41:01 +0000

Your message dated Sat, 23 Jun 2018 10:40:27 +0300
with message-id <address@hidden>
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
address@hidden)


-- 
31872: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31872
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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
address@hidden; if two or three arguments, @code{d} and @code{e} are
address@hidden; 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
address@hidden @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



--- End Message ---
--- Begin Message --- 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 <address@hidden>
> 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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]