[Top][All Lists]

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

[debbugs-tracker] bug#34794: closed (26.1; doc of `read-buffer')

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#34794: closed (26.1; doc of `read-buffer')
Date: Sat, 09 Mar 2019 18:28:02 +0000

Your message dated Sat, 09 Mar 2019 20:26:31 +0200
with message-id <address@hidden>
and subject line Re: bug#34794: 26.1; doc of `read-buffer'
has caused the debbugs.gnu.org bug report #34794,
regarding 26.1; doc of `read-buffer'
to be marked as done.

(If you believe you have received this mail in error, please contact

34794: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34794
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 26.1; doc of `read-buffer' Date: Sat, 9 Mar 2019 08:31:38 -0800 (PST)
AFAICT neither the doc string nor the Elisp manual states what the
default value is if argument DEF is nil.  IOW, what is the default
buffer name if no explicit default is provided?  It seems (without
thorough testing) to be the value of `(buffer-name (current-buffer))'.

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30 built on CIRROCUMULUS
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor 'Microsoft Corp.', version 10.0.17134

--- End Message ---
--- Begin Message --- Subject: Re: bug#34794: 26.1; doc of `read-buffer' Date: Sat, 09 Mar 2019 20:26:31 +0200
> Date: Sat, 09 Mar 2019 20:16:22 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > I cannot tell from the doc string that the default value,
> > i.e., the value returned when DEF is nil, is the empty
> > string.
>   Optional second arg DEF is value to return if user enters an empty line.
> Doesn't this say that when DEF is omitted the function will return
> that empty line?

I made a small change to make it even more clear.

> > It's not hard to state what the default DEF behavior
> > is, and then later say that if `read-buffer-function'
> > is non-nil then the use of the other args is up to it,
> > i.e., not necessarily as described above.  This is
> > not unusual for a function that optionally accepts a
> > function arg as one possibility.
> Please suggest such a text, because I definitely don't see an easy way
> of saying that, without triggering more bug reports like this one.

Didn't do anything about this.  Feel free to reopen if you think the
bug is not done without that.

--- End Message ---

reply via email to

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