[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Completions in Semantic
From: |
Stefan Monnier |
Subject: |
Re: Completions in Semantic |
Date: |
Tue, 27 Oct 2009 20:56:40 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
>> As for this "extra info", I see what you mean, but usually completion
>> involves several potential candidates, so listing them all plus all
>> their info would take way too much space in general (if not, then
>> something like completion-annotate-function should work).
> What I described is similar to `completion-annotate-function', but
> more flexible (prefixed in the symbol/identifier, postfixed; some in
> overlay, some in minibuffer, etc).
Right, so the question is: how should the generic code make such
flexibility available (and conversely) how shojuld the client of the
completion code be able to exploit/provide such flexibility.
I'm very interested in adding such hooks into the completion code, but
I haven't come up with any convincing idea of what they should look like
(the closest I got is completion-annotate-function which is very
limited). So suggestions are welcome (patches as well, of course, tho
it's not crucial).
>> So usually this extra info is provided outside of the completion
>> functionality (e.g. via eldoc-mode or something similar). But, yes,
>> I'd like to extend the *Completions* buffer so that you could ask for
>> more info (either on all entries, or just on one at a time).
> The key here is that completions do not necessarily have to go (only)
> into the *Completions* buffer.
Of course. company-mode is an obvious example.
>> > - result narrowing
>> > A-la company-mode.
>> No idea to what this is referring.
> Company-mode provides a binding that, given the current table of
> possible completions, the user can narrow it through various
> mechanisms (e.g., regexps).
Would that be like IDO's C-SPC (aka ido-restrict-to-matches)?
It shouldn't be too hard to add that to the default completion.
Maybe even without having to change minibuffer.el (i.e. there should
already be enough hooks for that).
>> > - argument placeholders So that argument type and/or name is shown as
>> > placeholders, such that the user simply TABs (or whatever) to fill-in
>> > the blanks.
>>
>> Idem. Unless you mean something like skeletons/templates, but then
>> I fail to see the connection with completion.
> Completing a symbol triggers an arbitrary function, which could, for example:
> - show symbol definition
> - show short and/or extended documentation for symbol
> - insert skeleton/template-like symbol definition (such that user simply
> tabs to sellect next argument placeholder, which initially contains
> argument name and/or type).
That would be like the minibuffer-exit-hook, but for completion inside
a normal buffer, right? That sounds like a good idea. Currently,
figuring out when such "inline completion" ends is actually pretty
difficult, but it's something very much needed.
Stefan
- Re: Completions in Semantic, (continued)
- Re: Completions in Semantic, Stefan Monnier, 2009/10/19
- Re: Completions in Semantic, Eric M. Ludlam, 2009/10/20
- Re: Completions in Semantic, Lluis, 2009/10/21
- Re: Completions in Semantic, Eric M. Ludlam, 2009/10/21
- Re: Completions in Semantic, Lluis, 2009/10/21
- Re: Completions in Semantic, Eric M. Ludlam, 2009/10/21
- Re: Completions in Semantic, Stefan Monnier, 2009/10/22
- Re: Completions in Semantic, Lluis, 2009/10/27
- Re: Completions in Semantic,
Stefan Monnier <=
- Re: Completions in Semantic, Eric M. Ludlam, 2009/10/27
- Re: Completions in Semantic, Stefan Monnier, 2009/10/27
- Re: Completions in Semantic, Lluis, 2009/10/29
- Re: Completions in Semantic, Stefan Monnier, 2009/10/31
- Re: Completions in Semantic, Stefan Monnier, 2009/10/22
Re: Completions in Semantic, Eric M. Ludlam, 2009/10/19