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
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]
--
--
You received this message from the vim_dev maillist.
Do not top-post!
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
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
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
On 2013-02-18, 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
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
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
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
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.
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
11 matches
Mail list logo
