Re: [Nano-devel] RFC: limiting the amount of position history

[Mike Frysinger]

On 14 Jan 2016 13:54, Benno Schulenberg wrote:
> On Wed, Jan 13, 2016, at 21:47, Mike Frysinger wrote:
> > On 13 Jan 2016 21:23, Benno Schulenberg wrote:
> > > when wanting to search for something in nano, one can
> > > type the first few characters of a previous search string
> > > and then Tab will cycle through the ones that start with
> > > those characters.
> > 
> > yes, i was thinking of search history.  we can't rebind behavior there
> > afaict.
> 
> No, even if you try to unbind Tab, Tab will always cycle
> through the matching previous search strings.
> 
> >  imo, ideally we'd just load the existing readline inputrc files.
> 
> That would require a major rewrite.
> 
> > > But when trying to open a file, Tab will just try to
> > > complete the first few characters to a filename in the
> > > current directory, and if there are multiple candidates
> > > it will beep and a second Tab will bring up a list...
> > 
> > would be nice if there were history here
> 
> Yes.  But how to combine that with Tab completion of names
> in the current dir?  It's of course nice to be able to do
> ^P ^P..., but if you can't Tab through the file history,
> the usefulness of it is much reduced.

i don't use tab to search.  i use ctrl+r, or i type out partial strings
and then use page up/page down to do leading matches, or i use the arrow
keys.  tab is purely for completion.  using it to cycle matches i find
weird.

> > > Weird, specialized functionality.
> > 
> > how so ?
> 
> Well, I was going to say: Tab on the command line never beeps.
> But that is because I have 'set show-all-if-ambiguous on' in my
> inputrc -- by default Tab does beep when it can't unambiguously
> complete the current string.

i like "set show-all-if-unmodified on" and "set skip-completed-text on" myself.
but i think this is an area where everyone has their own minor preferences and
why respecting inputrc is a good idea.

> But still, if one runs src/nano and types for example:
> ^R c <Tab>, it beeps and completes the string to "config",
> another <Tab> beeps again without doing anything, and
> a third <Tab> will take over the entire edit window with
> a list of all the config* files.  First, the list is very
> far away from where the cursor is.  Second, one cannot do
> anything with this list, except look at it and decide which
> other char to type.  Third, if I wanted a list, I would have
> typed ^T.  Fourth, if I type another character, say "u", and
> hit <Tab>, it will extend the string to "configure" and beep
> again and show the normal edit window again, another <Tab>
> will beep again and do nothing, and another <Tab> will bring
> up a list again...  Tiring.

the current completion/display behavior is annoying.  i've gotten in
the habit of not relying on it.

> Just cycling through the matches would be quicker, less noisy,
> and less visually distracting.  And it would match the behaviour
> for search, so it would be more consistent (within nano).

i dislike search behavior too ;)
-mike

signature.asc
Description: Digital signature