Fast completion with visible cue?

Fast completion with visible cue?

[Simon Josefsson]

Is the following possible with some ad-on package?  If so, would it
make sense to enable the ad-on by default?  If not, what do people
think about adding this feature?

I'm really sorry for the complicated explanation, there is probably a
really simple term for this idea, and I suspect it is already
implemented.  But if so, I'd like to vote for having it on by default.
Many GNOME and GTK programs have similar user experience.

1. CWD is ~.  You wish to open a file
   ~/projects/src/foo/doc/drafts/template/help.txt, so you might press
   C-x C-f ~/proj TAB sr TAB f TAB doc TAB dr TAB tem TAB he TAB RET

2. You edit the file for a while, then close it with C-x C-k.

3. Hours pass and you edit lots of other files, however, consider for
   sake of example that all the files you edit are in ~/play/.

4. You wish to edit the first file again.  You type
   C-x C-f ~/pro

Now, wouldn't it be Really Nice if the minibuffer prompt would
contain:

Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt

where CURSOR isn't shown verbatim, but indicate where the cursor is,
and the latter part of the string is displayed in a light gray color
but the earlier part of the string is in black.

You could continue typing and TAB complete like the normal prompt, but
would be able to open the "suggested" filename (shown in light gray)
by simply pressing RET.  To really open a file called "~/pro" you
could press SPC DEL or similar.

Re: Fast completion with visible cue?

[David Kastrup]

Simon Josefsson <jas@extundo.com> writes:

> Is the following possible with some ad-on package?  If so, would it
> make sense to enable the ad-on by default?  If not, what do people
> think about adding this feature?

[...]

> Now, wouldn't it be Really Nice if the minibuffer prompt would
> contain:
> 
> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt

You know C-TAB?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Fast completion with visible cue?

[Simon Josefsson]

David Kastrup <dak@gnu.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Is the following possible with some ad-on package?  If so, would it
>> make sense to enable the ad-on by default?  If not, what do people
>> think about adding this feature?
>
> [...]
>
>> Now, wouldn't it be Really Nice if the minibuffer prompt would
>> contain:
>> 
>> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt
>
> You know C-TAB?

No, but it doesn't appear to be exactly what I want, or I'm not using
it properly.  The feature I'm thinking of shouldn't need to be
initialized on certain directories, which seems to be required for
`filecache' (C-TAB).

I found `icomplete-mode' which does something quite similar for M-x to
what I want for C-x C-f. If only icomplete-mode could match against
the find-file history ring.  The user interface is too complicated to
be on by default, though, but if it were simplified (and could match
in the find-file history ring), it is approaching what I originally
wanted.

Andreas Schwab <schwab@suse.de> writes:

> What about previous-complete-history-element?

How do I use it?

Re: Fast completion with visible cue?

[Dhruva Krishnamurthy]

On Fri, 27 Aug 2004 01:13:02 +0200, "Simon Josefsson" <jas@extundo.com>
said:
> 
> > Simon Josefsson <jas@extundo.com> writes:
> >
> >> Is the following possible with some ad-on package?  If so, would it
> >> make sense to enable the ad-on by default?  If not, what do people
> >> think about adding this feature?

How about "recentf-mode". It even remembers across sessions. Just enable
the mode, all files you visit (even drag-n-drop) gets stored. With
CTRL-o, it opens a buffer with the list of files opened and can be
selected from mouse. With C-x-f (find-file), using the up/down arrow
keys, you can scroll through the files recently opened.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Fast completion with visible cue?

[Andreas Schwab]

Simon Josefsson <jas@extundo.com> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> What about previous-complete-history-element?
>
> How do I use it?

I've bound it to M-R in all minibuffer maps.

Andreas.

PS: IMHO there should be a map that is the parent of all minibuffer maps.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Fast completion with visible cue?

[Stefan Monnier]

> PS: IMHO there should be a map that is the parent of all minibuffer maps.

It's called `minibuffer-local-map' (can't remember if I changed it early
enough for Emacs-21, but it's definitely in CVS).


        Stefan "who has M-p and M-n bound to a variant of
                previous-complete-history-element which behaves like
                previous-history-element if there's no matching
                previous-complete-history-element or if you haven't
                typed anything yet"

Re: Fast completion with visible cue?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> PS: IMHO there should be a map that is the parent of all minibuffer maps.
>
> It's called `minibuffer-local-map' (can't remember if I changed it early
> enough for Emacs-21, but it's definitely in CVS).

Thanks, I didn't notice (that change is already 2½ years old, but not in
21.3).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Fast completion with visible cue?

[Andreas Schwab]

Simon Josefsson <jas@extundo.com> writes:

> Now, wouldn't it be Really Nice if the minibuffer prompt would
> contain:
>
> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt
>
> where CURSOR isn't shown verbatim, but indicate where the cursor is,
> and the latter part of the string is displayed in a light gray color
> but the earlier part of the string is in black.

What about previous-complete-history-element?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Fast completion with visible cue?

[Miles Bader]

On Fri, Aug 27, 2004 at 01:06:22AM +0200, Andreas Schwab wrote:
> > Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt
> >
> > where CURSOR isn't shown verbatim, but indicate where the cursor is,
> > and the latter part of the string is displayed in a light gray color
> > but the earlier part of the string is in black.
> 
> What about previous-complete-history-element?

Yup; I've got that bound to "M-[" in the minibuffer, and it rocks.

For cases where you want to recall something "by (non-prefix) name" just
using minibuffer history search (M-r) is also very useful.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Fast completion with visible cue?

[Juri Linkov]

Miles Bader <miles@gnu.org> writes:
> For cases where you want to recall something "by (non-prefix) name" just
> using minibuffer history search (M-r) is also very useful.

Using M-r and M-s for minibuffer history search is not too convenient:
switching keys `M-r RET M-r RET M-r RET ...' is not as fast as using
only one key to repeat the search for the same string.

What I'm thinking about as a better alternative is using isearch
for minibuffer history search.  By redefining `isearch-search-fun-function'
and `isearch-wrap-function' and using C-M-s and C-M-r to search the
minibuffer history this is quite easy to implement.

But there are some problems:

1. isearch used to search text in the minibuffer overwrites the minibuffer
   contents with its own text "I-search: ...".  This problem could be
   solved by not displaying this message when the minibuffer is active,
   because isearch has other visible indication for the search string
   which is displayed in the (mini-)buffer in the `isearch' face.
   What is needed to be displayed in the isearch minibuffer are
   isearch messages about the failed isearch (perhaps, 1 sec is a
   sufficient delay for displaying it), and the value of an incomplete
   regexp (to help the user to finish writing it).  So instead of the
   current code in the `isearch-message' function:

    (if c-q-hack
	m
      (let ((message-log-max nil))
	(message "%s" m)))

   to use the following conditions:

    (if (or (and (minibuffer-window-active-p (selected-window))
                 isearch-success
                 (not isearch-invalid-regexp))
            c-q-hack)
        m
      (let ((message-log-max nil))
        (message "%s" m)
        (when (and (minibuffer-window-active-p (selected-window))
                   (not isearch-invalid-regexp))
          (sit-for 1)
          (message ""))))

2. Another question is what function to use as `isearch-search-fun-function'
   to search the minibuffer history.  Most natural candidates are
   `next-matching-history-element' and `previous-matching-history-element',
   but they can't be used without changes.  I see three possibilities:

   1. to improve them to allow finding multiple occurrences of the
   search string in the same minibuffer history item before going
   to the next history item (currently, M-n and M-p search only for
   the first occurrence of the search string within one history item,
   but isearch should visit all occurences), and some other changes
   not affecting the current behavior of M-n and M-p, but needed for
   isearch.

   2. to implement new functions similar to `previous-matching-history-element'
   suitable for using in isearch.

   3. to set `isearch-wrap-function' to a function calling either
   `next-history-element' or `previous-history-element'.  This is the most
   easiest solution, but this is not quite right, since it requires an
   additional keystroke C-s before wrapping, and moreover, wrapping
   should mean going to the first item of the minibuffer history ring,
   instead of going to the next history element.

I'm most inclined to the second solution (implementing new functions).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Fast completion with visible cue?

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > Miles Bader <miles@gnu.org> writes:
>> For cases where you want to recall something "by (non-prefix) name" just
>> using minibuffer history search (M-r) is also very useful.
>
  > Using M-r and M-s for minibuffer history search is not too convenient:
  > switching keys `M-r RET M-r RET M-r RET ...' is not as fast as using
  > only one key to repeat the search for the same string.

IMHO the way readline (and implicitly bash) implement incremental
history search (bound to C-r/C-s) is great from a UI point of
view. And that UI has been in use for a long time. 
It would be great to have something similar in emacs. 

[I am not quite sure how similar is your proposal to readline, if
it is, it would be nice to have].

Re: Fast completion with visible cue?

[Juri Linkov]

Dan Nicolaescu <dann@godzilla.ics.uci.edu> writes:
> Juri Linkov <juri@jurta.org> writes:
>   > Using M-r and M-s for minibuffer history search is not too convenient:
>   > switching keys `M-r RET M-r RET M-r RET ...' is not as fast as using
>   > only one key to repeat the search for the same string.
>
> IMHO the way readline (and implicitly bash) implement incremental
> history search (bound to C-r/C-s) is great from a UI point of
> view. And that UI has been in use for a long time. 
> It would be great to have something similar in emacs. 
>
> [I am not quite sure how similar is your proposal to readline, if
> it is, it would be nice to have].

What I described is very similar to how shell history search works.
Actually, I use it all the time and like to implement a similar feature
in Emacs.  I am not yet quite sure about keybindings, but perhaps
both pairs C-r/C-s and C-M-r/ C-M-s are ok.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Fast completion with visible cue?

[Jan D.]

> Is the following possible with some ad-on package?  If so, would it
> make sense to enable the ad-on by default?  If not, what do people
> think about adding this feature?
>

...

> Now, wouldn't it be Really Nice if the minibuffer prompt would
> contain:
>
> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt
>
> where CURSOR isn't shown verbatim, but indicate where the cursor is,
> and the latter part of the string is displayed in a light gray color
> but the earlier part of the string is in black.
>
> You could continue typing and TAB complete like the normal prompt, but
> would be able to open the "suggested" filename (shown in light gray)
> by simply pressing RET.  To really open a file called "~/pro" you
> could press SPC DEL or similar.

Care must be taken when implementing this feature.  For example, there
should be some delay before showing the suggested part.  In Safari
(the browser on Mac OSX) I find myself often type in a complete path
and then hit RETURN, just to end up with a longer part that I visited
previously.  In your example I would type

Find File: ~/projects/src/foo/doc/drafts/[RETURN]

only to find that help.txt is opened again.  The suggested part is added
in the same millisecond as I hit return.  This behaviour is very 
annoying.

	Jan D.

Re: Fast completion with visible cue?

[Simon Josefsson]

"Jan D." <jan.h.d@swipnet.se> writes:

>> Is the following possible with some ad-on package?  If so, would it
>> make sense to enable the ad-on by default?  If not, what do people
>> think about adding this feature?
>>
>
> ...
>
>> Now, wouldn't it be Really Nice if the minibuffer prompt would
>> contain:
>>
>> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt
>>
>> where CURSOR isn't shown verbatim, but indicate where the cursor is,
>> and the latter part of the string is displayed in a light gray color
>> but the earlier part of the string is in black.
>>
>> You could continue typing and TAB complete like the normal prompt, but
>> would be able to open the "suggested" filename (shown in light gray)
>> by simply pressing RET.  To really open a file called "~/pro" you
>> could press SPC DEL or similar.
>
> Care must be taken when implementing this feature.  For example, there
> should be some delay before showing the suggested part.  In Safari
> (the browser on Mac OSX) I find myself often type in a complete path
> and then hit RETURN, just to end up with a longer part that I visited
> previously.  In your example I would type
>
> Find File: ~/projects/src/foo/doc/drafts/[RETURN]
>
> only to find that help.txt is opened again.  The suggested part is added
> in the same millisecond as I hit return.  This behaviour is very 
> annoying.

I've seen it too, and I agree.  I wonder what a good default delay
would be. 100ms?

OTOH, perhaps it is better to display the cue instantly, but to only
use it as the user entry, if it had been shown to the user for 100ms.
So the user can hit RET even when the hint is shown, as long as she
doesn't wait 100ms or more.

Mozilla's URL input uses a pull down input field, so the user would
type ~/pro, and see a pull down input field with matching file names
from the history ring, and can use TAB RET to select the first one.
This is very addictive.  Of course, Emacs couldn't use TAB since it is
already used for old style file name completion.  M-TAB?

Perhaps this latter idea is less disruptive to how things used to
work.  The only difference would be that the minibuffer is enlarged a
few lines to show matching file names from the history ring, and that
M-TAB would allow the user to cycle through those entries, and place
the content of those entries in the first 'Find File: ' line.

Thanks.

Re: Fast completion with visible cue?

[Kim F. Storm]

Simon Josefsson <jas@extundo.com> writes:

> Is the following possible with some ad-on package?  If so, would it
> make sense to enable the ad-on by default?  If not, what do people
> think about adding this feature?
> 
> I'm really sorry for the complicated explanation, there is probably a
> really simple term for this idea, and I suspect it is already
> implemented.  But if so, I'd like to vote for having it on by default.
> Many GNOME and GTK programs have similar user experience.
> 
> 1. CWD is ~.  You wish to open a file
>    ~/projects/src/foo/doc/drafts/template/help.txt, so you might press
>    C-x C-f ~/proj TAB sr TAB f TAB doc TAB dr TAB tem TAB he TAB RET
> 
> 2. You edit the file for a while, then close it with C-x C-k.
> 
> 3. Hours pass and you edit lots of other files, however, consider for
>    sake of example that all the files you edit are in ~/play/.
> 
> 4. You wish to edit the first file again.  You type
>    C-x C-f ~/pro

Try ido-mode.

With that, you have several options here:

1) Since ido remembers the directories you have been editing, it
puts the most recent directory as the first choice for completion:

  C-x C-f ~/pro RET RET RET RET ... RET

2) Since ido remembers the files you work on, this may also work:

  C-x C-f help.txt M-s RET


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Fast completion with visible cue?

[Simon Josefsson]

storm@cua.dk (Kim F. Storm) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Is the following possible with some ad-on package?  If so, would it
>> make sense to enable the ad-on by default?  If not, what do people
>> think about adding this feature?
>> 
>> I'm really sorry for the complicated explanation, there is probably a
>> really simple term for this idea, and I suspect it is already
>> implemented.  But if so, I'd like to vote for having it on by default.
>> Many GNOME and GTK programs have similar user experience.
>> 
>> 1. CWD is ~.  You wish to open a file
>>    ~/projects/src/foo/doc/drafts/template/help.txt, so you might press
>>    C-x C-f ~/proj TAB sr TAB f TAB doc TAB dr TAB tem TAB he TAB RET
>> 
>> 2. You edit the file for a while, then close it with C-x C-k.
>> 
>> 3. Hours pass and you edit lots of other files, however, consider for
>>    sake of example that all the files you edit are in ~/play/.
>> 
>> 4. You wish to edit the first file again.  You type
>>    C-x C-f ~/pro
>
> Try ido-mode.

Thanks!  This seem to be icomplete-mode, but for C-x C-f.

However, I see two major problems:

* It changes how file completion work.  When I type ~/sr and press TAB
  it scroll in the file *Ido Completion* buffer while displaying 'Find
  file: ~/sr{SRC/ | CVSROOT | .cvsrc | .newsrc | .newsrc.eld }' in the
  minibuffer.  It doesn't complete the input to ~/src/, which is the
  only matching entry.

* While the 'Find file: ~/{file | foo | bar | ... }' display,
  occupying up two three lines of the minibuffer by default, may be
  useful for experts, I think normal users will become afraid when
  they see it.  My original idea would only display one suggested
  filename, which seems friendlier.

> With that, you have several options here:
>
> 1) Since ido remembers the directories you have been editing, it
> puts the most recent directory as the first choice for completion:
>
>   C-x C-f ~/pro RET RET RET RET ... RET

Yes, I understand now how it wants me to use it.  But I think this is
a too big user interface change to be on by defaul.t

> 2) Since ido remembers the files you work on, this may also work:
>
>   C-x C-f help.txt M-s RET

It worked sometimes, but seemed a bit fragile.

Re: Fast completion with visible cue?

[Kim F. Storm]

Simon Josefsson <jas@extundo.com> writes:

> > Try ido-mode.
> 
> Thanks!  This seem to be icomplete-mode, but for C-x C-f.
> 
> However, I see two major problems:
> 
> * It changes how file completion work.  When I type ~/sr and press TAB
>   it scroll in the file *Ido Completion* buffer while displaying 'Find
>   file: ~/sr{SRC/ | CVSROOT | .cvsrc | .newsrc | .newsrc.eld }' in the
>   minibuffer.  It doesn't complete the input to ~/src/, which is the
>   only matching entry.

You accept the current (first) choice with RET, not TAB.

Actually, "sr" occurs as a substring in all of the listed entries,
so there are more than one "matching entry".

You can customize ido-enable-prefix to only match on the first part of
file names.  Personally I find this too inflexible, once you get used
to the default non-prefix mode.

You can also customize ido-enable-flex-matching to get even more
flexible matching, e.g. to select help.txt, you can enter e.g. htx

> 
> * While the 'Find file: ~/{file | foo | bar | ... }' display,
>   occupying up two three lines of the minibuffer by default, may be
>   useful for experts, I think normal users will become afraid when
>   they see it.  My original idea would only display one suggested
>   filename, which seems friendlier.

Customize ido-max-window-height to 1.

> 
> > With that, you have several options here:
> >
> > 1) Since ido remembers the directories you have been editing, it
> > puts the most recent directory as the first choice for completion:
> >
> >   C-x C-f ~/pro RET RET RET RET ... RET
> 
> Yes, I understand now how it wants me to use it.  But I think this is
> a too big user interface change to be on by defaul.t

I have it as the default (with flex matching), and it makes C-x C-f
MUCH MUCH MUCH faster once you get used to it.

> 
> > 2) Since ido remembers the files you work on, this may also work:
> >
> >   C-x C-f help.txt M-s RET
> 
> It worked sometimes, but seemed a bit fragile.

True, but it works most of the time...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk