unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 34794@debbugs.gnu.org
Subject: bug#34794: 26.1; doc of `read-buffer'
Date: Sun, 10 Mar 2019 15:23:05 -0700 (PDT)	[thread overview]
Message-ID: <48406c96-9f8e-47cf-92f1-525a9ea7077e@default> (raw)
In-Reply-To: <<83o96i615x.fsf@gnu.org>>

> I used some ideas from your suggestion.

Thanks.  Do you have a URL to the updated doc?

> > 4. There appears to be a fairly large bug in the
> > behavior, BTW.  The function is supposed to return a
> > buffer name, which is presumably a string.
> >
> > But try this, hitting `RET' with empty minibuffer input:
> >  (read-buffer "b: " (selected-window) t)
> > That returns a window!  And this returns a number, not
> > a numeric string: (read-buffer "b: " 42 t)
> > It apparently can return anything at all.
> 
> AFAICT, it just behaves according to documentation of DEF.
> 
> > This is in spite of the fact that the REQUIRE-MATCH
> > arg is `t', and according to the doc that should
> > mean that you cannot exit the minibuffer unless the
> > input corresponds to an existing buffer.
> 
> That's only valid for something the user types, AFAIU.

Yes, you're right about that.  "`t' means that the user
is not allowed to exit unless the input is (or completes
to) an element of COLLECTION __or is null__."  I forgot
about that last part.

> > Do you prefer a separate bug report for this bug, or
> > can you fix it based on this report?
> 
> I don't really see what is there to fix.

I guess not.  I would have thought that a DEF that
isn't a buffer name - or at least a string - might
helpfully raise an error.

Let me see what other `read-*' functions do...

`read-string', `read-passwd', and `read-regexps' act
the same way: the DEFAULT(S) arg can be anything
at all, and it is returned as is upon empty input.
`read-string' doesn'tt necessarily return a string,
and so on.

Not great, I'd say.  But at least `read-buffer' is
not alone in such behavior.

And I suppose there is some code somewhere that even
takes advantage of such a "feature" somehow...

I'm happy, however, to see that at least some `read-*'
commands do raise an error if the DEFAULT arg is not
a string or nil.

`read-command', for example, raises an error if DEF
is not a string (it doesn't require a command name,
but that test is better than nothing):

Hitting RET with no input here:
 (read-command "Command: " (selected-window))
raises
 wrong-type-argument stringp #<window 136 on *Help*>

Same thing for `read-number', though at least that
tests for the expected type:
 (read-number "Number: " (selected-window))
 wrong-type-argument numberp #<window 8 on *Help*>)

`read-face-name' raises an error even before trying
to read!  It doesn't wait for input:

 (read-face-name "Face: " (selected-window))
 wrong-type-argument listp #<window 136 on *Help*>

BTW, `read-from-minibuffer' with non-nil READ arg
and with DEFAULT-VALUE not a string or nil ends
with an `End of file during parsing error':

Hitting RET with no input here:
 (read-from-minibuffer "Input: " nil nil t nil
                       (selected-window))

DEFAULT-VALUE of course "should be a string", but
if it's not the error message is not as helpful
as it could be.  There's nothing to be done about
this one, however, I guess.  Perhaps it could spit
out the thing it was passed as DEFAULT-VALUE, to
let you know what `read' choked on.  

`read-input-method-name' seems a bit problematic
when passed a non-string, non-nil DEFAULT-VALUE arg.
It tries to insert it into the prompt's "%s", which
ends in an error such as 
 wrong-type-argument sequencep #<window 8 on *Help*>)

`read-language-name' raises a similar error:
wrong-type-argument sequencep #<window 8 on *Help*>)

There isn't much consistency in these `read-*'
functions wrt their handling of the DEFAULT arg.
IMO at least some of them might be made better by
testing whether that arg is of the proper type and
raising a (somewhat relevant) error if not.





       reply	other threads:[~2019-03-10 22:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<<<b9668c05-e18f-4a3b-9c95-128b7f81fcda@default>
     [not found] ` <<<<831s3g7zv1.fsf@gnu.org>
     [not found]   ` <<<f996f3c7-0c92-4075-8888-ed0aab13eb33@default>
     [not found]     ` <<<83r2bf7w21.fsf@gnu.org>
     [not found]       ` <<d87f0188-3a25-4a7e-a4f3-71e434b21ab2@default>
     [not found]         ` <<83o96i615x.fsf@gnu.org>
2019-03-10 22:23           ` Drew Adams [this message]
2019-03-11 14:26             ` bug#34794: 26.1; doc of `read-buffer' Eli Zaretskii
2019-03-11 15:06               ` Drew Adams
2019-03-11 15:13                 ` Eli Zaretskii
2019-03-11 15:21                   ` Drew Adams
2019-03-11 16:09           ` Drew Adams
     [not found] <<<b9668c05-e18f-4a3b-9c95-128b7f81fcda@default>
     [not found] ` <<<831s3g7zv1.fsf@gnu.org>
     [not found]   ` <<f996f3c7-0c92-4075-8888-ed0aab13eb33@default>
     [not found]     ` <<83r2bf7w21.fsf@gnu.org>
2019-03-09 22:32       ` Drew Adams
2019-03-10 18:21         ` Eli Zaretskii
     [not found]       ` <<83o96j7vl4.fsf@gnu.org>
2019-03-09 22:34         ` Drew Adams
     [not found] <<b9668c05-e18f-4a3b-9c95-128b7f81fcda@default>
     [not found] ` <<831s3g7zv1.fsf@gnu.org>
2019-03-09 17:43   ` Drew Adams
2019-03-09 18:16     ` Eli Zaretskii
2019-03-09 18:26       ` Eli Zaretskii
2019-03-09 16:31 Drew Adams
2019-03-09 16:54 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48406c96-9f8e-47cf-92f1-525a9ea7077e@default \
    --to=drew.adams@oracle.com \
    --cc=34794@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).