[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Completions in Semantic

From: Lluis
Subject: Re: Completions in Semantic
Date: Tue, 27 Oct 2009 22:21:18 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Sorry for the delay and the scarce response... too much work.

El Thu, Oct 22, 2009 at 04:12:09PM -0400, Stefan Monnier ens deleit� amb les 
seg�ents paraules:
> > I don't know about the features of current code, but I miss some
> > features on some (if not all) the completion interfaces I've tested.
> > So here's a list of (my) desired features (all of which should be
> > configurable by the user):
> Sounds interesting, but I must be missing some context because there's
> a lot of references I don't understand.  Could you expand on them?


> > - symbol name
> >   Of course, this is what already provides every completion UI
> No idea what you're talking about here.
> > - extra information
> >   This can be filled ub with symbol "metadata".  Which metadata
> >   appears on the completion UI should be configurable by the user:
> >     - return type
> >     - arguments (type and/or name)
> >     - definition location (aka file)
> >     - short documentation
> >     - long documentation
> >   All this metadata should be located anywhere around the symbol name
> >   and/or the minibuffer (e.g., I think company-mode shows short
> >   documentation on minibuffer, until user presses F1, when full
> >   documentation is shown.  Some metadata might be shown in the
> >   minibuffer after completion selection (e.g., prototype).
> Oh... wait, are you talking specifically about completion in code
> buffers, so "symbol name" above referred to the ability to complete an
> identifier?

That's right.

> 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).

> 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.

> > - 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).

> > - 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).

This could be achieved if completions where "complex objects", so each could
describe what/where to show on the specific current completion UI, a "hover"
callback (e.g. show short doc or symbol signature on minibuffer), and a
selection callback (e.g., same possibilities as hover, plus the skeleton thing).

Read you,

 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom

reply via email to

[Prev in Thread] Current Thread [Next in Thread]