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".)
next prev 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
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=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.
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).