[patch] new cpo setting to make n/N search in the same direction

[Christian Brabandt]

Bram,
one of my annoyances with vim currently is, that when using n/N for
searching the direction depends on the previous search command. But I
usually forget if I initially used / or ? and then my brain gets stuck
whether I need to press n to search backwards or N. (e.g. I start a
search backwards using '?' and want to go further upwards and press
routinely 'N', but this moves back downwards again).

I find it easier to know that n searches downwards while N searches
upwards, since I usually only know whether I want to go further down or
up, so I can reliably hit n to go further down and N to go further up to
the next match.

This is what the attached patch enables, by adding the new flag 'N' to
the 'cpo' setting.

regards,
Christian
--

[Bram Moolenaar]

Well, instead of adding an option, what about:

:noremap n /<CR>
:noremap N ?<CR>


--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Hi Bram!

On Mo, 18 Feb 2013, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
> > Bram,
> > one of my annoyances with vim currently is, that when using n/N for
> > searching the direction depends on the previous search command. But I
> > usually forget if I initially used / or ? and then my brain gets stuck
> > whether I need to press n to search backwards or N. (e.g. I start a
> > search backwards using '?' and want to go further upwards and press
> > routinely 'N', but this moves back downwards again).
> >
> > I find it easier to know that n searches downwards while N searches
> > upwards, since I usually only know whether I want to go further down or
> > up, so I can reliably hit n to go further down and N to go further up to
> > the next match.
> >
> > This is what the attached patch enables, by adding the new flag 'N' to
> > the 'cpo' setting.
>
> Well, instead of adding an option, what about:
>
> :noremap n /<CR>
> :noremap N ?<CR>
>

I wouldn't call this intuitively:
http://groups.google.com/group/vim_use/msg/6ff8586688e52b7d

regards,
Christian
--
Unordnung: wo nichts am rechten Platz ist.
Ordnung: wo am rechten Platz nicht ist.

[Gary Johnson]

Won't that break any plugins that use 'n' or 'N' after a reverse
search?

I agree that the proposed behavior would be less confusing than the
current behavior, but changing it in any way that would break
existing scripts seems like a non-starter.

Regards,
Gary

[John Beckett]

Bram Moolenaar wrote:
>> This is what the attached patch enables, by adding the new
>> flag 'N' to the 'cpo' setting.
>
> Well, instead of adding an option, what about:
>
> :noremap n /<CR>
> :noremap N ?<CR>

The option would be much better!

I sometimes map n and N to add zz so the hit is in the middle
line, or for various other things, and while I suppose one could
add workarounds, I repeatedly find myself cursing the confusing
n/N behaviour after using # to search backwards. I have used it
a thousand times, and I still find myself going the wrong way,
and that breaks my train of thought in the middle of a complex
piece of code. Also, when I do press the right key, it takes
extra brain power ("now let's see, is it n or N this time?"),
which again is distracting.

Another irritation about the unexpected n/N behaviour is that it
is impossible to easily restore the screen to how it was if the
unexpected search scrolls the window. I can press Ctrl-O, or
search the right direction, but I can't restore the window to
how I had carefully arranged it (so the piece of code under
consideration is visible).

I don't bother with many customisations, but this one would be
permanently on for me.

John

[John Beckett]

Gary Johnson wrote:
> Won't that break any plugins that use 'n' or 'N' after a
> reverse search?
>
> I agree that the proposed behavior would be less confusing
> than the current behavior, but changing it in any way that
> would break existing scripts seems like a non-starter.

There are times when moving forward requires breaks from the
past. While various scripts might fail, the people who choose
to switch on this option can deal with that.

Vim should not default to setting a new option that would break
scripts, but people can choose to turn it on.

John

[Michael Henry]

> I sometimes map n and N to add zz so the hit is in the middle
> line, or for various other things, and while I suppose one could
> add workarounds, I repeatedly find myself cursing the confusing
> n/N behaviour after using # to search backwards.

I've always been confused by the behavior of "n" and "N" after
backward searches. The only work-around my brain can handle is
to simply avoid backward searches entirely; instead, I search
forward and press "N".

Michael Henry

[John Beckett]

Michael Henry wrote:
> I've always been confused by the behavior of "n" and "N"
> after backward searches. The only work-around my brain can
> handle is to simply avoid backward searches entirely;
> instead, I search forward and press "N".

Agreed. That's usually how I resolve the problem as well.

However, sometimes I take the trouble to scroll everything to
just how it is needed (so some critical portion of code is
visible). Pressing * to search forwards, and then N followed by
another N to go backwards might scroll the window, and that
would be a great distraction. Worse is when I stop to think
"if I press * will the window scroll?", because by the time
I've pondered that, and whether some tweaks to my setup might
overcome my difficulty, I have forgotten what I needed to do
in the code I was looking at.

John

[Michael Henry]

On 02/18/2013 08:37 PM, John Beckett wrote:
> However, sometimes I take the trouble to scroll everything to
> just how it is needed (so some critical portion of code is
> visible). Pressing * to search forwards, and then N followed by
> another N to go backwards might scroll the window, and that
> would be a great distraction.

I get around that problem by mapping ``*`` to avoid moving at
all; instead, it grabs the word under the cursor and sets the
current search term from that. Since I have 'hlsearch' set, all
of the matches visible in my window become highlighted without
the disruption of scrolling the window. The price I pay for
this is the need to press ``n`` (or ``N``) immediately if I want
to find the next (or previous) match. I find this a good
trade-off, but your mileage may vary.

Michael Henry

[Bram Moolenaar]

Christian Brabandt wrote:

> > > Bram,
> > > one of my annoyances with vim currently is, that when using n/N for
> > > searching the direction depends on the previous search command. But I
> > > usually forget if I initially used / or ? and then my brain gets stuck
> > > whether I need to press n to search backwards or N. (e.g. I start a
> > > search backwards using '?' and want to go further upwards and press
> > > routinely 'N', but this moves back downwards again).
> > >
> > > I find it easier to know that n searches downwards while N searches
> > > upwards, since I usually only know whether I want to go further down or
> > > up, so I can reliably hit n to go further down and N to go further up to
> > > the next match.
> > >
> > > This is what the attached patch enables, by adding the new flag 'N' to
> > > the 'cpo' setting.
> >
> > Well, instead of adding an option, what about:
> >
> > :noremap n /<CR>
> > :noremap N ?<CR>
> >
>
> I wouldn't call this intuitively:
> http://groups.google.com/group/vim_use/msg/6ff8586688e52b7d

It seems the main objection is that the search history is affected.
A generic solution to that would be a command modifier that does not
store the pattern in history.

We could also avoid storing an empty string in search history, even
without a modifier. Searching for an empty string is useless.

Actually, now that I try it I don't see the empty string being stored.
Tim apparently used // instead of /. I don't see why.

--
DENNIS: Oh, very nice. King, eh! I expect you've got a palace and fine
clothes and courtiers and plenty of food. And how d'you get that? By
exploiting the workers! By hanging on to outdated imperialist dogma
which perpetuates the social and economic differences in our society!

[ZyX]

> I wouldn't call this intuitively:
> http://groups.google.com/group/vim_use/msg/6ff8586688e52b7d

I would not call these attempts smart.

noremap <expr> n 'Nn'[v:searchforward]
noremap <expr> N 'nN'[v:searchforward]