[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.