Re: [Nano-devel] [PATCH] Implement incremental search

[Brand Huntsman]

On Wed, 14 Feb 2018 12:02:58 +0100
Benno Schulenberg <address@hidden> wrote:

> I would say: all of those, except removing the highlight.  I would
> want to keep the highlight so that I can see what *was* found, and
> can see what I would have to type if I want to see more of those
> occurrences, and can see where the cursor will land if I decide to
> hit <Enter> anyway.

I installed the patch, found a word and continued typing garbage. I don't look 
at the prompt when searching and when it started beeping I thought it was 
rejecting my keystrokes because the highlight remained unchanged. A color 
change in the prompt might have gotten my attention sooner, but that highlight 
was my primary focus. I knew the highlight wouldn't go away on a non-match and 
it still confused me for a second or two, before I remembered that. How will 
most users react to this without that knowledge?

What _was_ found is no longer relevant information, and in most cases probably 
has nothing to do with what you are searching for. Not removing the highlight 
should be hidden behind a _non_default_ option, I would not enable the feature 
if the highlight remained, as it is the primary indicator of a match or no 
match.

And the cursor should return to its origin if no match is found and enter is 
pressed. Paste text that ends with a linefeed, do you want cursor to jump to 
some place that matched the first character in your text? Ya, neither do I. 
Want the cursor to go to last match, press backspace until the match is 
highlighted again and then press enter, simple and not confusing.

I don't see this as a stand-alone feature, but as an enhancement to normal 
search, maybe typing fewer characters to get somewhere. To do that the feature 
must act as a normal search would, and a normal search doesn't move the cursor 
if nothing is found.

Open a file and triple-click the last non-blank line in the file to select it. 
Return to top of file, open incremental search and paste. The prompt closes, 
leaving cursor at top of file. Do the same with normal search and it goes to 
the last line. Paste to incremental search without the linefeed, press enter 
and it works. Is this a bug or some more confusing behavior?


> > If color is enabled and terminal supports color, it could default
> > to "bold,black,red",  
> 
> Black on red has low contrast on my terminal.  I would choose
> "bold,white,red".

Oops, I forgot that "bold,black" doesn't just bold but also brightens the 
black. "A_BOLD|A_REVERSE red,black" is what I meant, and also why nano needs a 
reverse attribute to do "bold,reverse,red,black" in nanorc. That applies the 
brightness from bold to the red and then bolds the black foreground without 
brightening it.

echo -e "\e[1;7;31;40m test \e[0m"


> (Pasting with the keyboard (^U) does not cause a series of searches
> because it is a single keystroke, but pasting with the mouse would
> cause such a series -- at least, until bracketed paste mode is
> implemented.)

Incremental search needs to start a 250ms timer on a keystroke, unless a timer 
is already active from previous keystroke. After 250ms the timer will fire and 
a search is performed. Resetting a running timer on every keystroke is 
optional. It would allow a fast typer to complete a word before searching, but 
just getting more than one keystroke per search is probably good enough.

Bracketed paste mode is a bandaid that wouldn't be needed if a timer was used.