[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to determine the current table (really) being used for minibuffe
Re: how to determine the current table (really) being used for minibuffer completion?
Fri, 25 Sep 2009 21:53:53 -0400
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)
> 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
> 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.