all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: dont.spam.earl@gmail.com
To: help-gnu-emacs@gnu.org
Subject: Re: Looking for universal completion with simple UI
Date: Tue, 7 Oct 2014 08:39:15 -0700 (PDT)	[thread overview]
Message-ID: <0a07ca5d-d79f-42d8-b74c-f8e7b8fdfae0@googlegroups.com> (raw)
In-Reply-To: <mailman.10548.1412574805.1147.help-gnu-emacs@gnu.org>

Yes, these are important UI considerations that I hadn't thought through yet. Thanks for outlining the possibilities. 

I see now how Icicles does indeed provide much of the functionality I'd like including supporting comint inputs, search history, etc.

Drew - The one unresolved issue for me is simplicity: the documentation for Icicles spans dozens of pages on emacswiki.org. Even after using it for a few months, I'm still surprised and turned-off by some of the defaults. I can envision an "Emacs Starter Kit"-style layer on top of icicles that provides a simpler interface and smoother learning curve. This might come at the cost of some of the advanced features and configurability however. If it were to have a different name yet acknowledge Icicles in its documentation, is that something you'd oppose?

Thanks,
Earl







On Sunday, October 5, 2014 10:53:01 PM UTC-7, Drew Adams wrote:
> > 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-07 15:39 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
     [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 [this message]
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=0a07ca5d-d79f-42d8-b74c-f8e7b8fdfae0@googlegroups.com \
    --to=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.