Re: Mapping erases search count message

Gary Johnson wrote:

> On 2019-08-29, Christian Brabandt wrote:
> > On Do, 29 Aug 2019, Christian Brabandt wrote:
> >
> > >
> > > On Di, 27 Aug 2019, Gary Johnson wrote:
> > >
> > > > On 2019-08-28, Christian Brabandt wrote:
> > > > > On Di, 27 Aug 2019, Gary Johnson wrote:
> > > > >
> > > > > > I just tried exposing the search count message by removing 'S' from
> > > > > > 'shortmess', but I couldn't see it. I discovered that it is hidden,
> > > > > > erased and/or not updated by a couple of my mappings.
> > > > > >
> > > > > > nnoremap <silent> n nzv:call AdjCursor()<CR>
> > > > > > nnoremap <silent> N Nzv:call AdjCursor()<CR>
> > > > > >
> > > > > > Here is a simple experiment that demonstrates the problem. Create
> > > > > > a file, test.vim, that contains the following.
> > > > > >
> > > > > > set shortmess-=S
> > > > > > nnoremap <silent> n n
> > > > > > help map.txt
> > > > > >
> > > > > > Open a standard-sized, 80x24 terminal, and in it run
> > > > > >
> > > > > > $ vim -N -u NONE -i NONE -S test.vim
> > > > > >
> > > > > > Then search for "command":
> > > > > >
> > > > > > /command
> > > > > >
> > > > > > After hitting Enter, the cursor will be at the start of "commands"
> > > > > > on line 7 and the command line will contain this:
> > > > > >
> > > > > > /command [1/>99]
> > > > > >
> > > > > > After hitting 'n', the cursor advances to line 13 and the command
> > > > > > line stays the same, even showing "[1/>99]" when it should be
> > > > > > showing "[2/>99]".
> > > > > >
> > > > > > Another 'n' advances the cursor to line 17, the screen scrolls
> > > > > > up so that that line is at the bottom of the window, and the command
> > > > > > line is empty--no search count message at all.
> > > > > >
> > > > > > I would think that <silent> would prevent the mapping from
> > > > > > disturbing the command line, in which case this is a bug.
> > > > > >
> > > > > > If it's not a bug, then is there some way of defining a mapping that
> > > > > > does not interfere with the search count message, or some way of
> > > > > > restoring that message at the end of a mapping?
> > > > >
> > > > > Is that with patch 8.1.1288 included?
> > > >
> > > > Sorry, I forgot to include the version information. Yes, I used the
> > > > latest version, 8.1.1933.
> > >
> > > Hm, I need to investigate.
> >
> > I see what is happening. A mapping with the `<silent>` flag will set the
> > internal variable cmd_silent to prevent it from being output the command
> > line. So what your mapping does is it acts like 'n' without outputting
> > anything on the command line.
> >
> > But this is not what you want. You want the default behaviour of n,
> > which does output the command to search + the new search index feature.
> >
> > (See the difference on the commandline between a plain `n` and a n
> > mapped with `nnoremap <silent> n n`).
> >
> > So the obvious fix would be to remove the `<silent>` command. While this
> > fixes your minimal test case, it most likely is no fix for your actual
> > issue, that calling the AdjCursor() function will be output in the
> > command line in addition (possibly overwriting the command line).
> >
> > What might work (depending on the complexity of your AdjCursor()
> > function) is to use an expression mapping that simply returns 'n' after
> > having done whatever action it needs to be doing. However, this might be
> > a bit difficult since you want this to happen after the cursor has been
> > placed.
> >
> > Another alternative might be a mapping like this:
> >
> > nmap n nzv
> > nnoremap <silent> zv zv:call AdjCursor()<cr>
>
> Thanks for looking further into this, Christian.
>
> I don't understand how that first mapping in your alternative
> mappings works. I thought that using nmap (not nnoremap) to map
> n to a rhs including n would cause an infinite recursion, but it
> doesn't.
>
> Those mappings solve part of the problem. That is, if AdjCursor()
> is an empty function, they work fine--the search count message is
> always visible. But if AdjCursor() is the actual function (which
> scrolls the window when needed to keep the cursor at least two lines
> from the top and bottom), then whenever the window is scrolled, the
> message disappears.
>
> In fact, removing all the mappings and just executing Ctrl-E or
> Ctrl-Y to scroll the window after a search erases the search count
> message. I think that's a bug. I can see no reason why scrolling
> should erase that message unless scrolling moves the cursor.
>
> Further, certain motion commands such as j, k and gg _don't_ erase
> the search count message, even though it would make sense for them
> to do so. It's weird to jump from the bottom of a buffer to the top
> with gg and still see the last search count message in the command
> line.
>
> The purpose of AdjCursor () is to scroll the window after a search
> moves the cursor near the top or bottom of the window so as to
> provide at least two lines of context around the cursor. (It should
> really be named AdjWindow().) It behaves like scrolloff=2, but only
> after certain commands. I don't want 'scrolloff' on all the time.
>
> That gave me an idea, a different solution to the problem:
> temporarily enable 'scrolloff' instead of scrolling the window.
> Here is what I just came up with and it seems to work well.
>
> nmap <silent> n :call ScrolloffCmd('n')<cr>
> nmap <silent> N :call ScrolloffCmd('N')<cr>
> function! ScrolloffCmd(cmd)
> set scrolloff=2
> try
> exe 'normal!' a:cmd
> catch
> echohl ErrorMsg
> echomsg matchstr(v:exception, ':\zs.*')
> echohl NONE
> endtry
> set scrolloff=0
> endfunction

Looking through older problems...

I tried the example with remapping "n", but it works OK for me.
Was this problem fixed already? Or is only that example fixed and there
a remaining problem?

--
FIXME and XXX are two common keywords used to mark broken or incomplete code
not only since XXX as a sex reference would grab everybody's attention but
simply due to the fact that Vim would highlight these words.
-- Hendrik Scholz

/// Bram Moolenaar -- Bram@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 ///

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/201911232215.xANMFexv031914%40masaka.moolenaar.net.