all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: dont.spam.earl@gmail.com, help-gnu-emacs@gnu.org
Subject: RE: Looking for universal completion with simple UI
Date: Sun, 5 Oct 2014 22:53:01 -0700 (PDT)	[thread overview]
Message-ID: <12143513-c124-4343-a69a-d43048dad2b6@default> (raw)
In-Reply-To: <778b7522-e7b5-4ee7-89fa-10548516d79c@googlegroups.com>

> Drew - thanks for the response. Yes, Icicles is the most
> comprehensive package for completion I've found, particularly for
> the mini buffer. I found it especially helpful to read you
> explaining the philosophy here:
> http://stackoverflow.com/questions/2100166/making-sense-out-of-
> emacs-completion-mode-choices
> 
> It appears Icicles is focused on mini-buffer completion though.
> Any tips for the various forms of in-buffer completion: searching,
> cycling through killed text, etc.?

One consideration is where you type the text to be completed, i.e.,
whether you type it first in the minibuffer or you type it directly
in the destination buffer.

IOW, even if you are completing text that you type into a buffer
(e.g., code), completion can use the minibuffer for (temporary)
text entry and another buffer (e.g. `*Completions*') for candidate
display. (Or it could, Ido-style, use the minibuffer for both input
and candidate display.)

To complete text in a buffer it is more common that you type there
and hit a key to complete there, without opening a minibuffer for
temporary text entry.  But where you enter the text is relevant
only to UI convenience, not to what kinds of completion are
available, for what contexts, etc.  Typing directly into the buffer
does have the advantage that you need not temporarily move your eye elsewhere (i.e., to the minibuffer or to `*Completions*').

It is true that Icicles does not have a lot of direct, particular
support for completing different kinds of buffer text.  It supports 
general, dynamic text completion (`dabbrev', `completion.el'). It supports BBDB text completion, comint (shell) text completion, and
Lisp symbol completion.  Other than those, it does not offer
anything special completing different kinds of text.

But if another library uses `completing-read' to provide a
particular form of text completion (e.g., completion for terms
in a particular programming language), then you can take
advantage of Icicles completion.  Most do not, AFAIK - they tend
to use in-buffer prefix entry and in-place cycling of completion
candidates.

Wrt which packages provide particular support for different
programming languages, others will no doubt chime in with
suggestions.  For vanilla Emacs there are CEDET and Semantic,
and various programming-language modes should offer some text
completion.

If you look at the code for the Icicles versions of `dabbrev'
etc. completion (command `icicle-dabbrev-completion'), you will
see that it is essentially the vanilla code with Icicles
completion added to handle the multiple-candidates case.

This means that if you have some existing text-completion code,
you can likely convert it easily to take advantage of Icicles
completion for the multiple-candidates case.

(Dunno what you mean by "searching, cycling through killed text"
as "forms of in-buffer completion".  Icicles provides completion
for searching; for yanking kill-ring text; and for navigating
using Imenu, bookmarks, the mark-ring, tag files, Info nodes,
grep or occur hits, buffer narrowings, etc.  But I don't really
see such things as being forms of "in-buffer completion".)



  parent reply	other threads:[~2014-10-06  5:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-05 20:26 Looking for universal completion with simple UI dont.spam.earl
2014-10-06  3:28 ` Drew Adams
     [not found] ` <mailman.10545.1412566158.1147.help-gnu-emacs@gnu.org>
2014-10-06  4:40   ` dont.spam.earl
2014-10-06  5:02     ` Eric Abrahamsen
2014-10-06  5:53     ` Drew Adams [this message]
     [not found]     ` <mailman.10546.1412571788.1147.help-gnu-emacs@gnu.org>
2014-10-07 15:38       ` dont.spam.earl
2014-10-07 16:51         ` Eric Abrahamsen
     [not found]     ` <mailman.10548.1412574805.1147.help-gnu-emacs@gnu.org>
2014-10-07 15:39       ` dont.spam.earl
2014-10-08 16:49         ` Drew Adams
     [not found]         ` <mailman.10751.1412786977.1147.help-gnu-emacs@gnu.org>
2014-10-17 15:19           ` dont.spam.earl
2014-10-17 16:31             ` Drew Adams
2014-10-20 21:48               ` Drew Adams
     [not found]               ` <mailman.11604.1413841750.1147.help-gnu-emacs@gnu.org>
2014-10-30 21:09                 ` dont.spam.earl
2014-10-08  5:42 ` Tu, Do
2014-10-17 15:18   ` dont.spam.earl

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12143513-c124-4343-a69a-d43048dad2b6@default \
    --to=drew.adams@oracle.com \
    --cc=dont.spam.earl@gmail.com \
    --cc=help-gnu-emacs@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.