From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>,
Ryan Thompson <rct@thompsonclan.org>,
27158@debbugs.gnu.org
Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files
Date: Wed, 31 May 2017 19:23:12 -0700 (PDT) [thread overview]
Message-ID: <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> (raw)
In-Reply-To: <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru>
> > 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.
I certainly hope not, a priori. No good reason has been given
for that. Just a trumpian pronouncement of a change to come.
> > 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 doesn't suffice. This should suffice, as advertised:
(funcall completing-read-function
prompt collection predicate require-match
initial-input hist def inherit-input-method)
And in your `completing-read-function': (setq def (or def "")).
End of story. It really seems like you are making a mountain
out of a mole hill. You want DEF = nil to act like DEF = "".
Big deal. Just do that in the right place: inside your
`completing-read-function'.
> > 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.
Really? Even when `ido-ubiquitous-mode' is off?
What about users who do not want to use `ido-ubiquitous-mode'?
Do they count too? Do you mean that all of Emacs will succumb
to `ido-ubiquitous-mode'? Will you be expecting all Emacs users
and libraries to adhere to the "improvement" of Ido Uber Alles?
Not every user is an Ido user. `completing-read' does not
belong to Ido - it is more general than the restricted
behavior you've been pitching. Having nil DEF act like ""
is a special case.
If that behavior is contained within `ido-ubiquitous-mode'
then that mode should already be able to impose whatever
completion behavior it wants.
Isn't that fair enough: Keep Ido Ubiquitous completion
behavior for `ido-ubiquitous-mode', and not for all of
Emacs and all the time?
And it should be able to do that without changing anything in
`completing-read' or `completing-read-function'. And if it
does need to change the value of `completing-read-function'
for the duration, it can do that. And if it needs to advise
`completing-read' for the duration, it can do that. That
seems clear enough. Your mode can use any kind of completion
it wants.
Again: 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?
No answer. Just a statement that your context is the World
Of Emacs, that you "will change" the behavior not just for
Ido Ubiquitous but for all of Emacs. Sheesh.
Please do whatever you need to do to `completing-read'
inside the mode only. That's why it's a mode. That's
why it's called `ido-ubiquitous-mode' and not "Emacs".
I change the behavior of `completing-read' considerably
more than what you've described, but I do it only inside
`icicle-mode'. When the mode is off, the vanilla behavior
returns to `completing-read'. Not a big deal. Normal.
Icicles completion too applies to "the whole of Emacs".
That's what Icicles "affects and improves". And it
does so only when Icicle mode is on.
I don't see why `ido-ubiquitous-mode' can't act similarly.
What's so special about it, that it needs to not only
modify `completing-read' behavior when the mode is on
but modify more generally, for all uses, regardless of
whether `ido-ubiquitous-mode' is on?
next prev parent reply other threads:[~2017-06-01 2:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 4:41 bug#27158: 25.2; Eliminating old usage of completing-read from built-in files Ryan
2017-05-31 5:52 ` Drew Adams
2017-05-31 11:45 ` Ryan Thompson
2017-05-31 14:51 ` Drew Adams
2017-05-31 12:23 ` Dmitry Gutov
2017-05-31 14:51 ` Drew Adams
2017-05-31 14:59 ` Dmitry Gutov
2017-05-31 15:19 ` Drew Adams
2017-05-31 15:44 ` Ryan Thompson
2017-05-31 22:41 ` Dmitry Gutov
2017-05-31 23:16 ` Drew Adams
2017-05-31 23:54 ` Dmitry Gutov
2017-06-01 2:23 ` Drew Adams [this message]
2017-06-01 9:27 ` Dmitry Gutov
2017-06-01 14:57 ` Drew Adams
2017-06-01 20:53 ` Dmitry Gutov
2017-06-01 21:04 ` Ryan Thompson
2017-06-05 23:01 ` Dmitry Gutov
2017-06-06 0:06 ` Ryan Thompson
2017-06-06 0:09 ` Dmitry Gutov
2017-05-31 21:20 ` Dmitry Gutov
2020-08-24 14:58 ` Lars Ingebrigtsen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7897022a-fea7-44cf-9781-8dd6a1da2f3e@default \
--to=drew.adams@oracle.com \
--cc=27158@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=rct@thompsonclan.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.