GNU bug report logs -
#27158
25.2; Eliminating old usage of completing-read from built-in files
Previous Next
Reported by: Ryan <rct <at> thompsonclan.org>
Date: Wed, 31 May 2017 04:43:02 UTC
Severity: minor
Tags: wontfix
Found in version 25.2
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #41 received at 27158 <at> debbugs.gnu.org (full text, mbox):
On 6/1/17 2:16 AM, Drew Adams wrote:
> The value of that variable is supposed to accept the same
> args as `completing-read'. Understood is that `completing-read'
> just passes its args along to the value of `completing-read-function'.
That will change.
> Anything else makes it impossible for `completing-read-function'
> to be as general as it should be.
(defun completing-read (prompt collection &optional predicate
require-match initial-input hist def
inherit-input-method)
(funcall completing-read-function
prompt collection predicate require-match
initial-input hist (or def "") inherit-input-method))
should suffice.
> It should be able to do
> exactly what `completing-read' does now, if it wants.
The function does not want anything.
> And if that is insufficient for some reason, can't you use
> `advice-add' to redefine `completing-read' (e.g. in some
> scope or for some duration) to do exactly what you need?
>
> I sense that you have a real problem, but I'm not sure what it is.
Maybe try reading? I've sent a pretty long explanation to you in the
previous message.
> What prevents you from making `completing-read' behave that
> way (or any other way) within your context? Why is it
> insufficient for you to do that in your value of
> `completing-read-function' or by advising `completing-read'
> for the duration?
My context is "the whole of Emacs". That's what Ido Ubiquitous is
supposed to be affecting and improving.
This bug report was last modified 4 years and 330 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.