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

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

bug#45879: 28.0.50; [PATCH] missing defvar for keymap-name-history


From: James N . V . Cash
Subject: bug#45879: 28.0.50; [PATCH] missing defvar for keymap-name-history
Date: Fri, 15 Jan 2021 10:08:56 -0500

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I don't think it's required for the HIST arg
> of `completing-read' (or `read-from-minibuffer') to
> be predefined.  It can be any symbol, which is taken
> as a variable - no need for a defvar.

Ah, okay -- reading the help for `completing-read', it says that HIST
"can be a symbol, which is the history list variable to use", which I
took to mean that it should refer to a variable.

> E.g. in `emacs -Q':
>
>  (completing-read "aaa: " obarray nil nil nil 'toto)
>
> No error occurs, and `toto' gets populated correctly
> as a variable, starting with an initial value of nil,
> and regardless of input.
>
> (And the byte-compiler issues no warning either.)

Indeed, I noticed this as well, but I wasn't sure if that was intended,
or just a coincidence of implementation that it happened to work.

> But it sounds (just a guess) like it's Helm that has
> a bug here.  Again though, it's good to provide a
> defvar anyway.

Hah, funnily enough, Helm also says that this an Emacs bug:
https://github.com/emacs-helm/helm/issues/2327#issuecomment-647912917

😆 Not entirely sure how to resolve this then, other than just defining
the variable myself in my own config.

> I thought this "feature" was documented, but I don't
> find it now in the Elisp manual or doc strings.
> Perhaps it's there somewhere.  (Not very important
> anyway.)

If this is indeed intended behaviour, I can submit a patch to clarify
the docstring for completing-read.





reply via email to

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