On 2019-11-23, Bram Moolenaar wrote: > 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?
There was a patch that fixed part of the problem, and I rewrote my function to avoid another part of the problem. It's been working fine since early September. I don't think there is any more that you need to do. Thank you and Christian again. Regards, Gary -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20191124074541.GA31400%40phoenix.