unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Lluis <xscript@gmx.net>, emacs-devel@gnu.org
Subject: Re: Completions in Semantic
Date: Tue, 27 Oct 2009 22:25:07 -0400	[thread overview]
Message-ID: <1256696707.5333.214.camel@projectile.siege-engine.com> (raw)
In-Reply-To: <jwvocnswdq2.fsf-monnier+emacs@gnu.org>

On Tue, 2009-10-27 at 20:56 -0400, Stefan Monnier wrote:
> >> 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).

Are you looking for examples of hooks that would be needed, or examples
of behaviors that need hooks to be designed?

Here are some thoughts:

* Annotate completions buffer output (as you describe)
- I used to add () to a fcn, or other little things but clicking on a
  completion name would then insert too much, so I removed the feature
  from my version.

* Alternate completion list display mechanisms
- Inline completions like using a popup window.  I used a tooltip, but 
  it doesn't doesn't look as nice and isn't interactive

* Focus concept
- Once a completions list is short enough, TABs that don't complete can
  instead 'focus' on a completion.  Each new TAB moves the focus.

  The focus could do almost anything depending on what is being
completed.  For tags, it will flash the location of the tag in a buffer.
It could show doc, or any other differentiating data that might be
available.  ie - in Info nodes it could show the first paragraph.  For
files it could show the first 500 bytes or some file status, for a
buffer it could flip to it temporarily.  I expect most completable
things could do something special.

  For inline completion, the focus can be used to ghost in the text that
would be inserted if one selected that focus.  Pressing RET when
something is focused makes that item become the select entry w/out
having to type it.

Eric




  reply	other threads:[~2009-10-28  2:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-18 23:00 Completions in Semantic Chong Yidong
2009-10-18 23:55 ` Miles Bader
2009-10-19  3:50 ` Eric M. Ludlam
2009-10-19 13:48   ` Stefan Monnier
2009-10-19 16:26     ` Eric M. Ludlam
2009-10-19 18:29       ` Stefan Monnier
2009-10-19 19:33         ` Eric M. Ludlam
2009-10-19 20:06           ` Stefan Monnier
2009-10-19 22:17             ` Eric M. Ludlam
2009-10-20  0:07               ` Lennart Borgman
2009-10-30 21:17                 ` Toby Cubitt
2009-10-30 21:37                   ` Lennart Borgman
2009-10-20  0:14               ` Stefan Monnier
2009-10-20 20:20                 ` Eric M. Ludlam
2009-10-21 10:58                   ` Lluis
2009-10-21 12:35                     ` Eric M. Ludlam
2009-10-21 13:28                       ` Lluis
2009-10-21 17:35                         ` Eric M. Ludlam
2009-10-22 20:12                     ` Stefan Monnier
2009-10-27 21:21                       ` Lluis
2009-10-28  0:56                         ` Stefan Monnier
2009-10-28  2:25                           ` Eric M. Ludlam [this message]
2009-10-28  3:23                             ` Stefan Monnier
2009-10-29 14:38                               ` Lluis
2009-10-31 20:18                                 ` Stefan Monnier
2009-11-01 16:01                                   ` Lluís
2009-11-02  6:12                                     ` Stefan Monnier
2009-11-02 12:13                                       ` Eric M. Ludlam
2009-10-22 20:00                   ` Stefan Monnier
2009-10-19 23:52   ` Eric M. Ludlam
2009-10-21 14:07     ` Chong Yidong
2009-10-21 16:10       ` Eric M. Ludlam
2009-10-23  1:01         ` Chong Yidong
2009-10-23  1:28           ` Eric M. Ludlam

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=1256696707.5333.214.camel@projectile.siege-engine.com \
    --to=eric@siege-engine.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=xscript@gmx.net \
    /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).