Re: [Nano-devel] search history

[Ken Tyler]

On Sun, 20 Oct 2002, Chris Allegretta wrote:
> On Mon, Oct 21, 2002 at 05:20:34AM +1000, Ken Tyler wrote:
> > On Sat, 19 Oct 2002, David Benbennick wrote:
> > > On Fri, Oct 18, 2002 at 08:41:53AM +1000, Ken Tyler wrote:

> > > > Doesn't affect pico mode ...
> > 
> > > Why not have the same feature in Pico mode?  I use Pico mode by default, 
> > > and only turn it off when I need to edit the last search, or replace by 
> > > the empty string.
> > 
> > I was under the impression that pico mode should emulate Pico exactly.
> 
> It should, but since this mode could be compatible and yet be a superset of 
> the
> functionality offered by Pico without *breaking* compatibility (currently
> up/down in Pico's search mode does nothing), it could be in both modes. 

Making search/replace history available in pico mode is only a matter of
removing a few ISSET(PICO_MODE)s and a possible simplification in one
other place.
 
> Honestly I'd rather see the current non-pico behavior go away; yes its
> consistent across functions but people are used to the way Pico does previous
> search strings.  I'd rather the new behavior become the default, drop the ^\
> shortcut from the menu and drop Pico compatibilty mode entirely (as we'd 
> pretty much be pico compatible).  

Waht is the 'new' behavior ?

Leave it as is, i like having ^\ to go straight to "search for replace".

I suppose really I would prefer ^R in search to become ^\ for consistancy
and leave it as is. Now I've done a bit of a job on ^W <numeric> ^T (4
lines) the ^T should become ^-.

> Serious question (now that the list seems to be back up): Who actually likes 
> the
> default previous search/replace string behavior?

See above for control keys, but nano search/replace default string
offerings (preserved in the history) patch are sensible, but easily
changed.

A bit of compromise regarding pico functionality and nano could simpify
the internal string girations in the code though.  

> P.S.  Ken, no one can committ the patch until you post it somewhere ;-)  As 
> this 
> code was supposed to be in already, it can probably be let in for 1.2.

I sent David Benbennick the patch this morning, maybe he would be kind
enough to commit it if it's OK.

Ken.