From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: how to determine the current table (really) being used for minibuffer completion?
Date: Fri, 25 Sep 2009 21:53:53 -0400 [thread overview]
Message-ID: <jwvbpkyfq0x.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <137402B99D584CEE9AF2E4B23116527A@us.oracle.com> (Drew Adams's message of "Fri, 25 Sep 2009 14:22:26 -0700")
> How I used to do what? There is no concrete example.
Please, then say clearly that your problem is hypothetical, that will
help us answer your questions more directly.
> So you've confirmed what I said: one cannot know. The request is to be
> able to know. IOW, to be able to have some finer-grain knowledge of
> the completion state.
Define what you mean by "have some finer-grain knownledge of the
completion state". I think this request is like a solution waiting for
a problem. So once we find a concrete problem, we'll know better how to
solve it. But in the abstract like that, it's really unclear what kind
of solution would be needed/possible.
> The point is that now there can be radically different kinds of
> completion that are used, all within the same
> `read-file-name-internal' (for example).
That has always been a possibility. Maybe this is used a bit more now, tho.
> I would like to be able to know which phase of that completion
> processing I'm in,
When? Who's "I"?
Do you mean, given the position of point which kind of completion will
take place? The closest right now is to use completion-boundaries,
which won't tell you what completion table will be used, but at least
it'll tell you which part of the buffer around point will be "affected".
> I would like, for instance (just an example), to be able to distinguish
> file-name completion per se from env var completion, both of which are now
> included as part of "file-name" completion in a larger sense.
completion-boundaries can help you do that. But again, without knowing to
what purpose you want to distinguish those two cases, it's hard to know
what would really be a good answer.
> Only in a general way. `foo' or `read-file-name-internal' is the
> overall completion function, to be sure, but the completion processing
> is now decomposed into several distinct cases (as you say, next). For
> `read-file-name-internal', these are
> `completion--embedded-envvar-table' and `completion--file-name-table'.
> `read-file-name-internal' doesn't really call directly for any
> low-level completion act (e.g. `try-completion') anymore.
read-file-name-internal is pretty much the only one that I changed in
this way, BTW. It can now complete either files or env-vars. In the
future it will probably also be able to complete ~<user> user names.
>> > So not only is checking `minibuffer-completion-table' against
>> > `read-file-name-internal' useless,
>> Comparing functions is usually a bad idea. Sometimes,
>> there's not much else we can do, admittedly.
> The Emacs code still compares `minibuffer-completion-table' against
> `read-file-name-internal', in particular, in many locations.
Not sure how you define "many", but my grep found only one place where
we do it: in complete.el which could advise read-file-name-internal
instead (but since it's on the way to obsolescence, it doesn't matter
much either way).
> I assume that all of those occurrences still work as intended. ;-)
Why wouldn't they? ;-)
BTW, all the uses I've ever found (other than complete.el's) were
changed to use minibuffer-completing-file-name or to work in all cases.
> It is a general request.
We have plenty of real concrete problems to address and improvements to
implement, so yours will inevitably end up at the very bottom of
the lot.
> I obviously don't have a great feel for how to best implement what I'm
> asking for or how best to use it.
Come back when you do know.
Stefan
next prev parent reply other threads:[~2009-09-26 1:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-25 17:20 how to determine the current table (really) being used for minibuffer completion? Drew Adams
2009-09-25 20:01 ` Stefan Monnier
2009-09-25 21:22 ` Drew Adams
2009-09-26 1:53 ` Stefan Monnier [this message]
2009-09-26 14:58 ` Drew Adams
2009-09-26 21:26 ` Stefan Monnier
2009-09-27 0:02 ` Drew Adams
2009-09-27 18:24 ` Stefan Monnier
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=jwvbpkyfq0x.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@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).