Looking for universal completion with simple UI

Looking for universal completion with simple UI

[dont.spam.earl]

Hi all,

I'm posting to ask about a completion model I have in mind. Before I code it up myself I'm trying to find any packages that already implement most or all of this functionality.

The Emacs Wiki Category page for Completion lists packages for minibuffer completion and text completion:
http://www.emacswiki.org/emacs/CategoryCompletion

I want a package for completion both INSIDE and OUTSIDE of the minibuffer with a universal UI:
- Minibuffer Input Completion:
  - finding files
  - switching buffers
  - apropos for functions and variables
  - and any other minibuffer history lists
- Text Completion in a Buffer:
  - code completion
  - executables/commands at a comint prompt
  - i-searching in the current buffer
  - cycling through killed text for yanking

Further, I want to navigate via a couple "dimensions" of context, both historical (previous inputs I've entered), and alphabetical (previous and next alphabetically, as in files in a directory).

The UI model and keybindings for this might be as simple as:
- show prefix candidates with TAB
- show substring candidates with S-TAB
- with candidates already shown, the second TAB/S-TAB would select the first candidate
- navigate candidates alphabetically with C-r, C-s
- navigate candidates historically with C-p, C-n

Do any packages implement this already?

Thanks,
Earl

RE: Looking for universal completion with simple UI

[Drew Adams]

> I'm posting to ask about a completion model I have in mind. Before I
> code it up myself I'm trying to find any packages that already
> implement most or all of this functionality.
> 
> The Emacs Wiki Category page for Completion lists packages for
> minibuffer completion and text completion:
> http://www.emacswiki.org/emacs/CategoryCompletion
> 
> I want a package for completion both INSIDE and OUTSIDE of the
> minibuffer with a universal UI:
> - Minibuffer Input Completion:
>   - finding files
>   - switching buffers
>   - apropos for functions and variables
>   - and any other minibuffer history lists
> - Text Completion in a Buffer:
>   - code completion
>   - executables/commands at a comint prompt
>   - i-searching in the current buffer
>   - cycling through killed text for yanking
> 
> Further, I want to navigate via a couple "dimensions" of context,
> both historical (previous inputs I've entered), and alphabetical
> (previous and next alphabetically, as in files in a directory).
> 
> The UI model and keybindings for this might be as simple as:
> - show prefix candidates with TAB
> - show substring candidates with S-TAB
> - with candidates already shown, the second TAB/S-TAB would select
>   the first candidate
> - navigate candidates alphabetically with C-r, C-s
> - navigate candidates historically with C-p, C-n
> 
> Do any packages implement this already?

I think you will find that several packages support much or even
all of what you request.  Even vanilla Emacs supports much of it.

I can't speak for other packages (others will), but Icicles
supports pretty much all of what you mention.

Icicle features apply mainly to the minibuffer.

For in-buffer text (code) completion, whenever there are
multiple candidates matching the buffer text to be completed,
Icicles extends some vanilla commands to let you use its
minibuffer completion features (regexp or substring matching,
multiple-pattern matching, candidate sorting, cycling, etc.)

So for text completion, instead of cycling among multiple
candidates in place, Icicles uses the minibuffer and shows
the candidates in `*Completions*'.  When there is only one
candidate, text completion in Icicles reverts to vanilla,
in-place completion.

Apart from Emacs Lisp, Icicles offers nothing particular for
code completion that is language-specific.  But its completion
features are automatically available for any code-specific
completion that uses `completing-read'.

You can download Icicles from Emacs Wiki or MELPA, to try it.
http://www.emacswiki.org/Icicles

Re: Looking for universal completion with simple UI

[dont.spam.earl]

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


On Sunday, October 5, 2014 8:28:54 PM UTC-7, Drew Adams wrote:
> > I'm posting to ask about a completion model I have in mind. Before I
> 
> > code it up myself I'm trying to find any packages that already
> 
> > implement most or all of this functionality.
> 
> > 
> 
> > The Emacs Wiki Category page for Completion lists packages for
> 
> > minibuffer completion and text completion:
> 
> > http://www.emacswiki.org/emacs/CategoryCompletion
> 
> > 
> 
> > I want a package for completion both INSIDE and OUTSIDE of the
> 
> > minibuffer with a universal UI:
> 
> > - Minibuffer Input Completion:
> 
> >   - finding files
> 
> >   - switching buffers
> 
> >   - apropos for functions and variables
> 
> >   - and any other minibuffer history lists
> 
> > - Text Completion in a Buffer:
> 
> >   - code completion
> 
> >   - executables/commands at a comint prompt
> 
> >   - i-searching in the current buffer
> 
> >   - cycling through killed text for yanking
> 
> > 
> 
> > Further, I want to navigate via a couple "dimensions" of context,
> 
> > both historical (previous inputs I've entered), and alphabetical
> 
> > (previous and next alphabetically, as in files in a directory).
> 
> > 
> 
> > The UI model and keybindings for this might be as simple as:
> 
> > - show prefix candidates with TAB
> 
> > - show substring candidates with S-TAB
> 
> > - with candidates already shown, the second TAB/S-TAB would select
> 
> >   the first candidate
> 
> > - navigate candidates alphabetically with C-r, C-s
> 
> > - navigate candidates historically with C-p, C-n
> 
> > 
> 
> > Do any packages implement this already?
> 
> 
> 
> I think you will find that several packages support much or even
> 
> all of what you request.  Even vanilla Emacs supports much of it.
> 
> 
> 
> I can't speak for other packages (others will), but Icicles
> 
> supports pretty much all of what you mention.
> 
> 
> 
> Icicle features apply mainly to the minibuffer.
> 
> 
> 
> For in-buffer text (code) completion, whenever there are
> 
> multiple candidates matching the buffer text to be completed,
> 
> Icicles extends some vanilla commands to let you use its
> 
> minibuffer completion features (regexp or substring matching,
> 
> multiple-pattern matching, candidate sorting, cycling, etc.)
> 
> 
> 
> So for text completion, instead of cycling among multiple
> 
> candidates in place, Icicles uses the minibuffer and shows
> 
> the candidates in `*Completions*'.  When there is only one
> 
> candidate, text completion in Icicles reverts to vanilla,
> 
> in-place completion.
> 
> 
> 
> Apart from Emacs Lisp, Icicles offers nothing particular for
> 
> code completion that is language-specific.  But its completion
> 
> features are automatically available for any code-specific
> 
> completion that uses `completing-read'.
> 
> 
> 
> You can download Icicles from Emacs Wiki or MELPA, to try it.
> 
> http://www.emacswiki.org/Icicles

Re: Looking for universal completion with simple UI

[Eric Abrahamsen]

dont.spam.earl@gmail.com writes:

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

I think "helm" is becoming the standard response to this question -- it
does all the minibuffer stuff, and provides a unified completion
mechanism over find/grep/kill-ring/mark-ring, etc etc. People have made
backends for an astonishing amount of stuff. You can also use it for
in-buffer text completion by using the auto-complete backend.

> On Sunday, October 5, 2014 8:28:54 PM UTC-7, Drew Adams wrote:
>> > I'm posting to ask about a completion model I have in mind. Before I
>> 
>> > code it up myself I'm trying to find any packages that already
>> 
>> > implement most or all of this functionality.
>> 
>> > 
>> 
>> > The Emacs Wiki Category page for Completion lists packages for
>> 
>> > minibuffer completion and text completion:
>> 
>> > http://www.emacswiki.org/emacs/CategoryCompletion
>> 
>> > 
>> 
>> > I want a package for completion both INSIDE and OUTSIDE of the
>> 
>> > minibuffer with a universal UI:
>> 
>> > - Minibuffer Input Completion:
>> 
>> >   - finding files
>> 
>> >   - switching buffers
>> 
>> >   - apropos for functions and variables
>> 
>> >   - and any other minibuffer history lists
>> 
>> > - Text Completion in a Buffer:
>> 
>> >   - code completion
>> 
>> >   - executables/commands at a comint prompt
>> 
>> >   - i-searching in the current buffer
>> 
>> >   - cycling through killed text for yanking
>> 
>> > 
>> 
>> > Further, I want to navigate via a couple "dimensions" of context,
>> 
>> > both historical (previous inputs I've entered), and alphabetical
>> 
>> > (previous and next alphabetically, as in files in a directory).
>> 
>> > 
>> 
>> > The UI model and keybindings for this might be as simple as:
>> 
>> > - show prefix candidates with TAB
>> 
>> > - show substring candidates with S-TAB
>> 
>> > - with candidates already shown, the second TAB/S-TAB would select
>> 
>> >   the first candidate
>> 
>> > - navigate candidates alphabetically with C-r, C-s
>> 
>> > - navigate candidates historically with C-p, C-n
>> 
>> > 
>> 
>> > Do any packages implement this already?
>> 
>> 
>> 
>> I think you will find that several packages support much or even
>> 
>> all of what you request.  Even vanilla Emacs supports much of it.
>> 
>> 
>> 
>> I can't speak for other packages (others will), but Icicles
>> 
>> supports pretty much all of what you mention.
>> 
>> 
>> 
>> Icicle features apply mainly to the minibuffer.
>> 
>> 
>> 
>> For in-buffer text (code) completion, whenever there are
>> 
>> multiple candidates matching the buffer text to be completed,
>> 
>> Icicles extends some vanilla commands to let you use its
>> 
>> minibuffer completion features (regexp or substring matching,
>> 
>> multiple-pattern matching, candidate sorting, cycling, etc.)
>> 
>> 
>> 
>> So for text completion, instead of cycling among multiple
>> 
>> candidates in place, Icicles uses the minibuffer and shows
>> 
>> the candidates in `*Completions*'.  When there is only one
>> 
>> candidate, text completion in Icicles reverts to vanilla,
>> 
>> in-place completion.
>> 
>> 
>> 
>> Apart from Emacs Lisp, Icicles offers nothing particular for
>> 
>> code completion that is language-specific.  But its completion
>> 
>> features are automatically available for any code-specific
>> 
>> completion that uses `completing-read'.
>> 
>> 
>> 
>> You can download Icicles from Emacs Wiki or MELPA, to try it.
>> 
>> http://www.emacswiki.org/Icicles

RE: Looking for universal completion with simple UI

[Drew Adams]

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

Re: Looking for universal completion with simple UI

[dont.spam.earl]

Great - thanks for the pointer! I see it appears to occupy the same niche as Company. While both are being actively developed on github, searching doesn't uncover any recent comparisons of the two.

How would you compare them? And why Helm over Company?


On Sunday, October 5, 2014 10:02:44 PM UTC-7, Eric Abrahamsen wrote:
> dont.spam.earl writes:
> 
> 
> 
> > 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.?
> 
> 
> 
> I think "helm" is becoming the standard response to this question -- it
> 
> does all the minibuffer stuff, and provides a unified completion
> 
> mechanism over find/grep/kill-ring/mark-ring, etc etc. People have made
> 
> backends for an astonishing amount of stuff. You can also use it for
> 
> in-buffer text completion by using the auto-complete backend.
> 
> 
> 
> > On Sunday, October 5, 2014 8:28:54 PM UTC-7, Drew Adams wrote:
> 
> >> > I'm posting to ask about a completion model I have in mind. Before I
> 
> >> 
> 
> >> > code it up myself I'm trying to find any packages that already
> 
> >> 
> 
> >> > implement most or all of this functionality.
> 
> >> 
> 
> >> > 
> 
> >> 
> 
> >> > The Emacs Wiki Category page for Completion lists packages for
> 
> >> 
> 
> >> > minibuffer completion and text completion:
> 
> >> 
> 
> >> > http://www.emacswiki.org/emacs/CategoryCompletion
> 
> >> 
> 
> >> > 
> 
> >> 
> 
> >> > I want a package for completion both INSIDE and OUTSIDE of the
> 
> >> 
> 
> >> > minibuffer with a universal UI:
> 
> >> 
> 
> >> > - Minibuffer Input Completion:
> 
> >> 
> 
> >> >   - finding files
> 
> >> 
> 
> >> >   - switching buffers
> 
> >> 
> 
> >> >   - apropos for functions and variables
> 
> >> 
> 
> >> >   - and any other minibuffer history lists
> 
> >> 
> 
> >> > - Text Completion in a Buffer:
> 
> >> 
> 
> >> >   - code completion
> 
> >> 
> 
> >> >   - executables/commands at a comint prompt
> 
> >> 
> 
> >> >   - i-searching in the current buffer
> 
> >> 
> 
> >> >   - cycling through killed text for yanking
> 
> >> 
> 
> >> > 
> 
> >> 
> 
> >> > Further, I want to navigate via a couple "dimensions" of context,
> 
> >> 
> 
> >> > both historical (previous inputs I've entered), and alphabetical
> 
> >> 
> 
> >> > (previous and next alphabetically, as in files in a directory).
> 
> >> 
> 
> >> > 
> 
> >> 
> 
> >> > The UI model and keybindings for this might be as simple as:
> 
> >> 
> 
> >> > - show prefix candidates with TAB
> 
> >> 
> 
> >> > - show substring candidates with S-TAB
> 
> >> 
> 
> >> > - with candidates already shown, the second TAB/S-TAB would select
> 
> >> 
> 
> >> >   the first candidate
> 
> >> 
> 
> >> > - navigate candidates alphabetically with C-r, C-s
> 
> >> 
> 
> >> > - navigate candidates historically with C-p, C-n
> 
> >> 
> 
> >> > 
> 
> >> 
> 
> >> > Do any packages implement this already?
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> I think you will find that several packages support much or even
> 
> >> 
> 
> >> all of what you request.  Even vanilla Emacs supports much of it.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> I can't speak for other packages (others will), but Icicles
> 
> >> 
> 
> >> supports pretty much all of what you mention.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> Icicle features apply mainly to the minibuffer.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> For in-buffer text (code) completion, whenever there are
> 
> >> 
> 
> >> multiple candidates matching the buffer text to be completed,
> 
> >> 
> 
> >> Icicles extends some vanilla commands to let you use its
> 
> >> 
> 
> >> minibuffer completion features (regexp or substring matching,
> 
> >> 
> 
> >> multiple-pattern matching, candidate sorting, cycling, etc.)
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> So for text completion, instead of cycling among multiple
> 
> >> 
> 
> >> candidates in place, Icicles uses the minibuffer and shows
> 
> >> 
> 
> >> the candidates in `*Completions*'.  When there is only one
> 
> >> 
> 
> >> candidate, text completion in Icicles reverts to vanilla,
> 
> >> 
> 
> >> in-place completion.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> Apart from Emacs Lisp, Icicles offers nothing particular for
> 
> >> 
> 
> >> code completion that is language-specific.  But its completion
> 
> >> 
> 
> >> features are automatically available for any code-specific
> 
> >> 
> 
> >> completion that uses `completing-read'.
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> You can download Icicles from Emacs Wiki or MELPA, to try it.
> 
> >> 
> 
> >> http://www.emacswiki.org/Icicles

Re: Looking for universal completion with simple UI

[Eric Abrahamsen]

dont.spam.earl@gmail.com writes:

> Great - thanks for the pointer! I see it appears to occupy the same
> niche as Company. While both are being actively developed on github,
> searching doesn't uncover any recent comparisons of the two.
>
> How would you compare them? And why Helm over Company?

I've never used Company, so I can't say. I picked Helm because "ooh,
shiny!"

If you're concerned about simplicity and the ease of adoption, do look
closely at Helm before you jump in. Its defaults surprise the heck out
some people. Particularly when it comes to file selection, one of the
most basic Emacs UI elements there is -- it takes a bit of getting used
to.

> On Sunday, October 5, 2014 10:02:44 PM UTC-7, Eric Abrahamsen wrote:
>> dont.spam.earl writes:
>> 
>> 
>> 
>> > 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.?
>> 
>> 
>> 
>> I think "helm" is becoming the standard response to this question -- it
>> 
>> does all the minibuffer stuff, and provides a unified completion
>> 
>> mechanism over find/grep/kill-ring/mark-ring, etc etc. People have made
>> 
>> backends for an astonishing amount of stuff. You can also use it for
>> 
>> in-buffer text completion by using the auto-complete backend.
>> 
>> 
>> 
>> > On Sunday, October 5, 2014 8:28:54 PM UTC-7, Drew Adams wrote:
>> 
>> >> > I'm posting to ask about a completion model I have in mind. Before I
>> 
>> >> 
>> 
>> >> > code it up myself I'm trying to find any packages that already
>> 
>> >> 
>> 
>> >> > implement most or all of this functionality.
>> 
>> >> 
>> 
>> >> > 
>> 
>> >> 
>> 
>> >> > The Emacs Wiki Category page for Completion lists packages for
>> 
>> >> 
>> 
>> >> > minibuffer completion and text completion:
>> 
>> >> 
>> 
>> >> > http://www.emacswiki.org/emacs/CategoryCompletion
>> 
>> >> 
>> 
>> >> > 
>> 
>> >> 
>> 
>> >> > I want a package for completion both INSIDE and OUTSIDE of the
>> 
>> >> 
>> 
>> >> > minibuffer with a universal UI:
>> 
>> >> 
>> 
>> >> > - Minibuffer Input Completion:
>> 
>> >> 
>> 
>> >> >   - finding files
>> 
>> >> 
>> 
>> >> >   - switching buffers
>> 
>> >> 
>> 
>> >> >   - apropos for functions and variables
>> 
>> >> 
>> 
>> >> >   - and any other minibuffer history lists
>> 
>> >> 
>> 
>> >> > - Text Completion in a Buffer:
>> 
>> >> 
>> 
>> >> >   - code completion
>> 
>> >> 
>> 
>> >> >   - executables/commands at a comint prompt
>> 
>> >> 
>> 
>> >> >   - i-searching in the current buffer
>> 
>> >> 
>> 
>> >> >   - cycling through killed text for yanking
>> 
>> >> 
>> 
>> >> > 
>> 
>> >> 
>> 
>> >> > Further, I want to navigate via a couple "dimensions" of context,
>> 
>> >> 
>> 
>> >> > both historical (previous inputs I've entered), and alphabetical
>> 
>> >> 
>> 
>> >> > (previous and next alphabetically, as in files in a directory).
>> 
>> >> 
>> 
>> >> > 
>> 
>> >> 
>> 
>> >> > The UI model and keybindings for this might be as simple as:
>> 
>> >> 
>> 
>> >> > - show prefix candidates with TAB
>> 
>> >> 
>> 
>> >> > - show substring candidates with S-TAB
>> 
>> >> 
>> 
>> >> > - with candidates already shown, the second TAB/S-TAB would select
>> 
>> >> 
>> 
>> >> >   the first candidate
>> 
>> >> 
>> 
>> >> > - navigate candidates alphabetically with C-r, C-s
>> 
>> >> 
>> 
>> >> > - navigate candidates historically with C-p, C-n
>> 
>> >> 
>> 
>> >> > 
>> 
>> >> 
>> 
>> >> > Do any packages implement this already?
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> I think you will find that several packages support much or even
>> 
>> >> 
>> 
>> >> all of what you request.  Even vanilla Emacs supports much of it.
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> I can't speak for other packages (others will), but Icicles
>> 
>> >> 
>> 
>> >> supports pretty much all of what you mention.
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> Icicle features apply mainly to the minibuffer.
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> For in-buffer text (code) completion, whenever there are
>> 
>> >> 
>> 
>> >> multiple candidates matching the buffer text to be completed,
>> 
>> >> 
>> 
>> >> Icicles extends some vanilla commands to let you use its
>> 
>> >> 
>> 
>> >> minibuffer completion features (regexp or substring matching,
>> 
>> >> 
>> 
>> >> multiple-pattern matching, candidate sorting, cycling, etc.)
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> So for text completion, instead of cycling among multiple
>> 
>> >> 
>> 
>> >> candidates in place, Icicles uses the minibuffer and shows
>> 
>> >> 
>> 
>> >> the candidates in `*Completions*'.  When there is only one
>> 
>> >> 
>> 
>> >> candidate, text completion in Icicles reverts to vanilla,
>> 
>> >> 
>> 
>> >> in-place completion.
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> Apart from Emacs Lisp, Icicles offers nothing particular for
>> 
>> >> 
>> 
>> >> code completion that is language-specific.  But its completion
>> 
>> >> 
>> 
>> >> features are automatically available for any code-specific
>> 
>> >> 
>> 
>> >> completion that uses `completing-read'.
>> 
>> >> 
>> 
>> >> 
>> 
>> >> 
>> 
>> >> You can download Icicles from Emacs Wiki or MELPA, to try it.
>> 
>> >> 
>> 
>> >> http://www.emacswiki.org/Icicles

Re: Looking for universal completion with simple UI

[dont.spam.earl]

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

RE: Looking for universal completion with simple UI

[Drew Adams]

> Drew - The one unresolved issue for me is simplicity: the
> documentation for Icicles spans dozens of pages on emacswiki.org.

Earl - The doc starts with a 14-sentence "README for NON-Readers":  
http://www.emacswiki.org/Icicles_-_Nutshell_View#READMEforNonReaders

After the first 7 sentences, the 8th is "You now know enough to
use Icicles."  And the 9th is "If you have doc-phobia or are easily
overwhelmed by explanations, then read no more - just try it!"
I stand by that.

The rest of that page is an overview of Icicles, with examples.
If you are up to reading more than 14 sentences then that nutshell
view is the next level of help.  You can stop there too.

You do not need to read lots of doc to use Icicles.  The fact that
there *is* lots of doc does not mean that you need to read it all.

> Even after using it for a few months, I'm still surprised and
> turned-off by some of the defaults.

Too vague to be helpful, but OK, your preferences differ from the
default behavior.  Nothing wrong with that.

And you have been using it for a few months but you still don't
feel comfortable with it.  That's OK.  People are different.
Thanks for trying it.  Sorry it doesn't fit your needs.

Icicles is not for everyone.  (Nor is Emacs, for that matter.)
And those who do use Icicles use it in very different ways and
have different preferences.  (Likewise, Emacs.)

> ... a simpler interface and smoother learning curve.

Please address particular issues or suggestions *specifically*,
using `M-x icicle-send-bug-report'.

It is trivial for a user to remove all top-level Icicles key
bindings from the equation, by just setting option
`icicle-top-level-key-bindings' to nil.

If you do that, and if you never use `S-TAB' to complete, you never
repeat `TAB' to cycle among completion candidates, and you never
bother with any of the special minibuffer keys (which are anyway
not bound in vanilla Emacs or are otherwise not useful in the
minibuffer), then the behavior you get is pretty close to that of
vanilla Emacs.  And you can toggle `icy-mode' to return to vanilla
Emacs anytime.

No one is required to use Icicles or find it helpful or useful.
Emacs is much bigger than Icicles.  Happy hacking.

Re: Looking for universal completion with simple UI

[dont.spam.earl]

Drew, thanks for your response. Yes, I've been using it for a few months, iterating several times in reading the documentation, setting variables, and adjusting my workflow. In no way do I want to complain about or criticize Icicles. It's clearly very powerful - unique in enabling the user to interactively create and narrow sets of items to apply operations to.

I didn't mean my post to be a bug report, and I'm certainly not interested in changing how YOU use Icicles, or the standard interface you've developed. What I have in mind is much narrower: developing a set of customizations to the interface. As with other Emacs packages - and as you did with Icicles itself - I may want to share those customizations down the line if I think they form a coherent whole. That's the connection I was making to Emacs starter packages. They offer a variety of ways to get started with Emacs, and reflect different people's perspectives on how that can be done.

So I'm interested in hearing whether you have any concerns about this idea from the outset.

On Wednesday, October 8, 2014 9:49:14 AM UTC-7, Drew Adams wrote:
> > Drew - The one unresolved issue for me is simplicity: the
> 
> > documentation for Icicles spans dozens of pages on emacswiki.org.
> 
> 
> 
> Earl - The doc starts with a 14-sentence "README for NON-Readers":  
> 
> http://www.emacswiki.org/Icicles_-_Nutshell_View#READMEforNonReaders
> 
> 
> 
> After the first 7 sentences, the 8th is "You now know enough to
> 
> use Icicles."  And the 9th is "If you have doc-phobia or are easily
> 
> overwhelmed by explanations, then read no more - just try it!"
> 
> I stand by that.
> 
> 
> 
> The rest of that page is an overview of Icicles, with examples.
> 
> If you are up to reading more than 14 sentences then that nutshell
> 
> view is the next level of help.  You can stop there too.
> 
> 
> 
> You do not need to read lots of doc to use Icicles.  The fact that
> 
> there *is* lots of doc does not mean that you need to read it all.
> 
> 
> 
> > Even after using it for a few months, I'm still surprised and
> 
> > turned-off by some of the defaults.
> 
> 
> 
> Too vague to be helpful, but OK, your preferences differ from the
> 
> default behavior.  Nothing wrong with that.
> 
> 
> 
> And you have been using it for a few months but you still don't
> 
> feel comfortable with it.  That's OK.  People are different.
> 
> Thanks for trying it.  Sorry it doesn't fit your needs.
> 
> 
> 
> Icicles is not for everyone.  (Nor is Emacs, for that matter.)
> 
> And those who do use Icicles use it in very different ways and
> 
> have different preferences.  (Likewise, Emacs.)
> 
> 
> 
> > ... a simpler interface and smoother learning curve.
> 
> 
> 
> Please address particular issues or suggestions *specifically*,
> 
> using `M-x icicle-send-bug-report'.
> 
> 
> 
> It is trivial for a user to remove all top-level Icicles key
> 
> bindings from the equation, by just setting option
> 
> `icicle-top-level-key-bindings' to nil.
> 
> 
> 
> If you do that, and if you never use `S-TAB' to complete, you never
> 
> repeat `TAB' to cycle among completion candidates, and you never
> 
> bother with any of the special minibuffer keys (which are anyway
> 
> not bound in vanilla Emacs or are otherwise not useful in the
> 
> minibuffer), then the behavior you get is pretty close to that of
> 
> vanilla Emacs.  And you can toggle `icy-mode' to return to vanilla
> 
> Emacs anytime.
> 
> 
> 
> No one is required to use Icicles or find it helpful or useful.
> 
> Emacs is much bigger than Icicles.  Happy hacking.

RE: Looking for universal completion with simple UI

[Drew Adams]

> What I have in mind is much narrower:
> developing a set of customizations to the interface. As with other
> Emacs packages - and as you did with Icicles itself - I may want to
> share those customizations down the line if I think they form a
> coherent whole. That's the connection I was making to Emacs starter
> packages. They offer a variety of ways to get started with Emacs,
> and reflect different people's perspectives on how that can be done.
> So I'm interested in hearing whether you have any concerns about
> this idea from the outset.

First, as I said before, setting `icicle-top-level-key-bindings'
to nil gives you just such a minimal "starter package".

With that, if you use Emacs as if it were vanilla Emacs (i.e.,
you don't try any Icicles keys in the minibuffer) then you get
pretty much vanilla Emacs behavior.  Not exactly, but pretty close.

And you can then, if you want, progressively choose to use some
of the Icicles minibuffer keys.  That lets you indulge in Icicles
features on demand, at your own speed, and to any limited extent.
Runtime, on-demand, make-your-own-starter-kit. You or anyone else.

For example:

1. Trying `S-TAB' instead of `TAB' lets you try substring or
   regexp completion.

2. Trying `S-SPC' after completing lets you try progressive
   completion (narrow the candidates using another pattern).

3. Trying `<down> <down>'... followed by `RET' lets you try
   cycling among completion candidates to choose one.

Those 3 basic Icicles features are independent of each other.
You can try any of them, with or without the others, at any
time.  With combinations of just those 3 features, you get
eight possible Icicles "starter kits" (none, 1, 2, 3, 12, 23,
13, 123).

Second, as to whether you can create your own "customizations
to the interface" and share them with others:

Of course you can, respecting the GNU Public License that the
code is distributed under.  That's the whole point of GNU and
the GPL: freely sharing source code in a reasonable and
freedom-respecting manner.

There are by design "a variety of ways to get started with"
Icicles.  Setting different combinations of option values
gives you different such ways ("starter kits").  Different
combinations "reflect different people's perspectives on
how" to use (or to get started with) Icicles.  If you want
to share your preferred combination with others and call
that the "Earl Icicles Starter Kit", go for it.  No problem.

Likewise, if you want to customize or enhance the Icicles
code in some way that appeals to you, and then share your
customization code, go for it (respecting the GPL).  You
are also welcome to submit enhancement requests for this
or that feature or change to be made to the Icicles code.

One reason there are so many out-of-the-box ways to
customize Icicles (e.g. options) is that different users
have requested different ways to use it.

The default behavior is, BTW, not the behavior I happen to
use, myself.  It is the behavior I think most appropriate
as the general, default behavior.  And yes, it has changed
over time.

There is nothing holy about a set of default values.  They
always represent a compromise and a judgment call, taking
lots of things into consideration.

Different people have different judgments, for different
contexts and purposes.  A different set of default values
gives you a different Icicles "starter kit".

And no, there is nothing wrong with sharing your own
preferred default values, or values that you think might
be helpful as defaults for some particular set of Icicles
users, whether starters or others.

In sum, I am open wrt concrete suggestions about Icicles
default values.  Alternatively, you are welcome to publish
your own recommended set of default values.  HTH.

RE: Looking for universal completion with simple UI

[Drew Adams]

I said:

> Second, as to whether you can create your own "customizations
> to the interface" and share them with others:
> 
> Of course you can, respecting the GNU Public License that the
> code is distributed under.  That's the whole point of GNU and
> the GPL: freely sharing source code in a reasonable and
> freedom-respecting manner.
> 
> There are by design "a variety of ways to get started with"
> Icicles.  Setting different combinations of option values
> gives you different such ways ("starter kits").  Different
> combinations "reflect different people's perspectives on
> how" to use (or to get started with) Icicles.  If you want
> to share your preferred combination with others and call
> that the "Earl Icicles Starter Kit", go for it.  No problem.
> 
> Likewise, if you want to customize or enhance the Icicles
> code in some way that appeals to you, and then share your
> customization code, go for it (respecting the GPL).  You
> are also welcome to submit enhancement requests for this
> or that feature or change to be made to the Icicles code.
...

> And no, there is nothing wrong with sharing your own
> preferred default values, or values that you think might
> be helpful as defaults for some particular set of Icicles
> users, whether starters or others.
> 
> In sum, I am open wrt concrete suggestions about Icicles
> default values.  Alternatively, you are welcome to publish
> your own recommended set of default values.  HTH.

I should be clear too that the Icicles code is copyrighted,
in addition to being published under the GPL.  I think you
are essentially asking about sharing your personal settings
of Icicles options as a sort of suggested Icicles "starter
kit" for others, which is certainly OK.

You have posted here only anonymously, Earl. If you have
concerns or questions about customizing or sharing Icicles
code, please mail me directly.  Thx.

Re: Looking for universal completion with simple UI

[dont.spam.earl]

Drew, I think I'm all set for now. I appreciate you outlining the steps for starting with a minimal configuration of icicles, then progressively using more of its functionality.

Glad to hear too that we're on the same page regarding customizations. What I have in mind, if I get around to it, would indeed be a "starter kit" in the way that we're both thinking. It would comply with both the GPL and icicles' copyright.

Thanks again for the help. I'll be in touch if I do have any other questions.

Best,
Earl




On Monday, October 20, 2014 2:48:47 PM UTC-7, Drew Adams wrote:
> I said:
> 
> > Second, as to whether you can create your own "customizations
> > to the interface" and share them with others:
> > 
> > Of course you can, respecting the GNU Public License that the
> > code is distributed under.  That's the whole point of GNU and
> > the GPL: freely sharing source code in a reasonable and
> > freedom-respecting manner.
> > 
> > There are by design "a variety of ways to get started with"
> > Icicles.  Setting different combinations of option values
> > gives you different such ways ("starter kits").  Different
> > combinations "reflect different people's perspectives on
> > how" to use (or to get started with) Icicles.  If you want
> > to share your preferred combination with others and call
> > that the "Earl Icicles Starter Kit", go for it.  No problem.
> > 
> > Likewise, if you want to customize or enhance the Icicles
> > code in some way that appeals to you, and then share your
> > customization code, go for it (respecting the GPL).  You
> > are also welcome to submit enhancement requests for this
> > or that feature or change to be made to the Icicles code.
> ...
> 
> > And no, there is nothing wrong with sharing your own
> > preferred default values, or values that you think might
> > be helpful as defaults for some particular set of Icicles
> > users, whether starters or others.
> > 
> > In sum, I am open wrt concrete suggestions about Icicles
> > default values.  Alternatively, you are welcome to publish
> > your own recommended set of default values.  HTH.
> 
> I should be clear too that the Icicles code is copyrighted,
> in addition to being published under the GPL.  I think you
> are essentially asking about sharing your personal settings
> of Icicles options as a sort of suggested Icicles "starter
> kit" for others, which is certainly OK.
> 
> You have posted here only anonymously, Earl. If you have
> concerns or questions about customizing or sharing Icicles
> code, please mail me directly.  Thx.

Re: Looking for universal completion with simple UI

[Tu, Do]

Vào 03:26:36 UTC+7 Thứ hai, ngày 06 tháng mười năm 2014, dont.sp...@gmail.com đã viết:
> Hi all,
> 
> 
> 
> I'm posting to ask about a completion model I have in mind. Before I code it up myself I'm trying to find any packages that already implement most or all of this functionality.
> 
> 
> 
> The Emacs Wiki Category page for Completion lists packages for minibuffer completion and text completion:
> 
> http://www.emacswiki.org/emacs/CategoryCompletion
> 
> 
> 
> I want a package for completion both INSIDE and OUTSIDE of the minibuffer with a universal UI:
> 
> - Minibuffer Input Completion:
> 
>   - finding files
> 
>   - switching buffers
> 
>   - apropos for functions and variables
> 
>   - and any other minibuffer history lists
> 
> - Text Completion in a Buffer:
> 
>   - code completion
> 
>   - executables/commands at a comint prompt
> 
>   - i-searching in the current buffer
> 
>   - cycling through killed text for yanking
> 
> 
> 
> Further, I want to navigate via a couple "dimensions" of context, both historical (previous inputs I've entered), and alphabetical (previous and next alphabetically, as in files in a directory).
> 
> 
> 
> The UI model and keybindings for this might be as simple as:
> 
> - show prefix candidates with TAB
> 
> - show substring candidates with S-TAB
> 
> - with candidates already shown, the second TAB/S-TAB would select the first candidate
> 
> - navigate candidates alphabetically with C-r, C-s
> 
> - navigate candidates historically with C-p, C-n
> 
> 
> 
> Do any packages implement this already?
> 
> 
> 
> Thanks,
> 
> Earl

I wrote a Helm guide here: http://tuhdo.github.io/helm-intro.html . A lot of demos are in there. 

Here is code completion using Helm: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif . The picture is in C/C++ guide: http://tuhdo.github.io/c-ide.html . Visit the page for more demos.

Re: Looking for universal completion with simple UI

[dont.spam.earl]

Eric, Tu, thanks for the pointers to Helm and the documentation!


On Tuesday, October 7, 2014 10:42:14 PM UTC-7, Tu, Do wrote:
> Vào 03:26:36 UTC+7 Thứ hai, ngày 06 tháng mười năm 2014, dont.sp...@gmail.com đã viết:
> 
> > Hi all,
> 
> > 
> 
> > 
> 
> > 
> 
> > I'm posting to ask about a completion model I have in mind. Before I code it up myself I'm trying to find any packages that already implement most or all of this functionality.
> 
> > 
> 
> > 
> 
> > 
> 
> > The Emacs Wiki Category page for Completion lists packages for minibuffer completion and text completion:
> 
> > 
> 
> > http://www.emacswiki.org/emacs/CategoryCompletion
> 
> > 
> 
> > 
> 
> > 
> 
> > I want a package for completion both INSIDE and OUTSIDE of the minibuffer with a universal UI:
> 
> > 
> 
> > - Minibuffer Input Completion:
> 
> > 
> 
> >   - finding files
> 
> > 
> 
> >   - switching buffers
> 
> > 
> 
> >   - apropos for functions and variables
> 
> > 
> 
> >   - and any other minibuffer history lists
> 
> > 
> 
> > - Text Completion in a Buffer:
> 
> > 
> 
> >   - code completion
> 
> > 
> 
> >   - executables/commands at a comint prompt
> 
> > 
> 
> >   - i-searching in the current buffer
> 
> > 
> 
> >   - cycling through killed text for yanking
> 
> > 
> 
> > 
> 
> > 
> 
> > Further, I want to navigate via a couple "dimensions" of context, both historical (previous inputs I've entered), and alphabetical (previous and next alphabetically, as in files in a directory).
> 
> > 
> 
> > 
> 
> > 
> 
> > The UI model and keybindings for this might be as simple as:
> 
> > 
> 
> > - show prefix candidates with TAB
> 
> > 
> 
> > - show substring candidates with S-TAB
> 
> > 
> 
> > - with candidates already shown, the second TAB/S-TAB would select the first candidate
> 
> > 
> 
> > - navigate candidates alphabetically with C-r, C-s
> 
> > 
> 
> > - navigate candidates historically with C-p, C-n
> 
> > 
> 
> > 
> 
> > 
> 
> > Do any packages implement this already?
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks,
> 
> > 
> 
> > Earl
> 
> 
> 
> I wrote a Helm guide here: http://tuhdo.github.io/helm-intro.html . A lot of demos are in there. 
> 
> 
> 
> Here is code completion using Helm: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif . The picture is in C/C++ guide: http://tuhdo.github.io/c-ide.html . Visit the page for more demos.