Re: Mapping erases search count message

[Gary Johnson]

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  n nzv:call AdjCursor()
> > > > > > > nnoremap  N Nzv:call AdjCursor()
> > > > > > > 
> > > > > > > Here is a simple experiment that demonstrates the problem.  Create
> > > > > > > a file, test.vim, that contains the following.
> > > > > > > 
> > > > > > > set shortmess-=S
> > > > > > > nnoremap  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  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 `` 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  n n`).
> > > 
> > > So the obvious fix would be to remove the `` 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  zv zv:call AdjCursor()
> > 
> > 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

Re: Mapping erases search count message

[Bram Moolenaar]

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  n nzv:call AdjCursor()
> > > > > > nnoremap  N Nzv:call AdjCursor()
> > > > > > 
> > > > > > Here is a simple experiment that demonstrates the problem.  Create
> > > > > > a file, test.vim, that contains the following.
> > > > > > 
> > > > > > set shortmess-=S
> > > > > > nnoremap  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  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 `` 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  n n`).
> > 
> > So the obvious fix would be to remove the `` 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  zv zv:call AdjCursor()
> 
> 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 li

Re: Mapping erases search count message

[Gary Johnson]

On 2019-09-04, Bram Moolenaar wrote:
> Christian wrote:
> 
> > On Mi, 04 Sep 2019, Bram Moolenaar wrote:
> > 
> > > Hmm, since nobody runs the tests manually that doesn't help much.
> > > How about using a screendump?  That makes these things a lot easier to
> > > write.
> > 
> > Okay, how about the attached patch then? That fails with v8.1.1965 and
> > should work with v8.1.1970
> 
> Yes, this works, thanks!

This is very nice!  Thank you both.  I just updated to 8.1.1987.
I had made some changes to my search mappings that improved the
behavior of the search count message but it still wasn't right in
all cases.  Now the message behaves as I expect it to in all the
cases I've tested.

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/20190905011459.GA11230%40phoenix.

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> On Mi, 04 Sep 2019, Bram Moolenaar wrote:
> 
> > Hmm, since nobody runs the tests manually that doesn't help much.
> > How about using a screendump?  That makes these things a lot easier to
> > write.
> 
> Okay, how about the attached patch then? That fails with v8.1.1965 and
> should work with v8.1.1970

Yes, this works, thanks!

-- 
hundred-and-one symptoms of being an internet addict:
178. You look for an icon to double-click to open your bedroom window.

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201909041433.x84EX3AW000703%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

On Mi, 04 Sep 2019, Christian Brabandt wrote:

> Okay, how about the attached patch then? That fails with v8.1.1965 and 
> should work with v8.1.1970

Small update:

[...]
> +  call delete('XscriptMatchCommon')

that should of course be 

call delete('Xsearchstat')


Best,
Christian
-- 
Ein schönes, herrliches Weib, das unvermählt bleibt, ist eine stille
und doch laute Anklage gegen alle Männer.
-- Bogumil Goltz

-- 
-- 
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/20190904120539.GR25942%40256bit.org.
From dd020996046fa8f64ce9ccec2f5b6f1573641564 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Wed, 4 Sep 2019 13:54:09 +0200
Subject: [PATCH] Add screendump test

---
 src/testdir/dumps/Test_searchstat_1.dump | 10 +++
 src/testdir/dumps/Test_searchstat_2.dump | 10 +++
 src/testdir/test_search_stat.vim | 35 
 3 files changed, 50 insertions(+), 5 deletions(-)
 create mode 100644 src/testdir/dumps/Test_searchstat_1.dump
 create mode 100644 src/testdir/dumps/Test_searchstat_2.dump

diff --git a/src/testdir/dumps/Test_searchstat_1.dump b/src/testdir/dumps/Test_searchstat_1.dump
new file mode 100644
index 0..52b13f2dc
--- /dev/null
+++ b/src/testdir/dumps/Test_searchstat_1.dump
@@ -0,0 +1,10 @@
+|f+0&#ff0|o@1|b|a|r| @68
+>f|i|n|d| |t|h|i|s| @65
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|f|o@1|b|a|r| @68
+|f|o@1|b|a|r| @68
+|f|o@1| @71
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|/|f|i|n|d| |t|h|i|s| @29|[|1|/|2|]| @11|2|,|1| @10|T|o|p| 
diff --git a/src/testdir/dumps/Test_searchstat_2.dump b/src/testdir/dumps/Test_searchstat_2.dump
new file mode 100644
index 0..a6ced4fd0
--- /dev/null
+++ b/src/testdir/dumps/Test_searchstat_2.dump
@@ -0,0 +1,10 @@
+|f+0&#ff0|o@1|b|a|r| @68
+>f|i|n|d| |t|h|i|s| @65
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|f|o@1|b|a|r| @68
+|f|o@1|b|a|r| @68
+|f|o@1| @71
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+@40|[|1|/|2|]| @11|2|,|1| @10|T|o|p| 
diff --git a/src/testdir/test_search_stat.vim b/src/testdir/test_search_stat.vim
index d5d50ff1d..c49bb8fc4 100644
--- a/src/testdir/test_search_stat.vim
+++ b/src/testdir/test_search_stat.vim
@@ -1,9 +1,7 @@
 " Tests for search_stats, when "S" is not in 'shortmess'
-"
-" This test is fragile, it might not work interactively, but it works when run
-" as test!
 
-source shared.vim
+source check.vim
+source screendump.vim
 
 func! Test_search_stat()
   new
@@ -181,7 +179,34 @@ func! Test_search_stat()
 
   " Clean up
   set shortmess+=S
-
   " close the window
   bwipe!
 endfunc
+
+func! Test_search_stat_screendump()
+  CheckScreendump
+
+  let lines =<< trim END
+set shortmess-=S
+" Append 50 lines with text to search for, "foobar" appears 20 times
+call append(0, repeat(['foobar', 'foo', 'fobar', 'foba', 'foobar'], 20))
+call setline(2, 'find this')
+call setline(70, 'find this')
+nnoremap n n
+let @/ = 'find this'
+call cursor(1,1)
+norm n
+  END
+  call writefile(lines, 'Xsearchstat')
+  let buf = RunVimInTerminal('-S Xsearchstat', #{rows: 10})
+  call term_wait(buf)
+  call VerifyScreenDump(buf, 'Test_searchstat_1', {})
+
+  call term_sendkeys(buf, ":nnoremap  n n\")
+  call term_sendkeys(buf, "gg0n")
+  call term_wait(buf)
+  call VerifyScreenDump(buf, 'Test_searchstat_2', {})
+
+  call StopVimInTerminal(buf)
+  call delete('Xsearchstat')
+endfunc
-- 
2.20.1

Re: Mapping erases search count message

[Christian Brabandt]

On Mi, 04 Sep 2019, Bram Moolenaar wrote:

> Hmm, since nobody runs the tests manually that doesn't help much.
> How about using a screendump?  That makes these things a lot easier to
> write.

Okay, how about the attached patch then? That fails with v8.1.1965 and 
should work with v8.1.1970

Best,
Christian
-- 
Sargdeckel fällt - die Witwe kichert, der Bauer war wohl gut versichert.

-- 
-- 
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/20190904120126.GQ25942%40256bit.org.
From b6f44bc8cef68df3baf291ed6957eb3a61b50412 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Wed, 4 Sep 2019 13:54:09 +0200
Subject: [PATCH] Add screendump test

---
 src/testdir/dumps/Test_searchstat_1.dump | 10 +++
 src/testdir/dumps/Test_searchstat_2.dump | 10 +++
 src/testdir/test_search_stat.vim | 35 
 3 files changed, 50 insertions(+), 5 deletions(-)
 create mode 100644 src/testdir/dumps/Test_searchstat_1.dump
 create mode 100644 src/testdir/dumps/Test_searchstat_2.dump

diff --git a/src/testdir/dumps/Test_searchstat_1.dump b/src/testdir/dumps/Test_searchstat_1.dump
new file mode 100644
index 0..52b13f2dc
--- /dev/null
+++ b/src/testdir/dumps/Test_searchstat_1.dump
@@ -0,0 +1,10 @@
+|f+0&#ff0|o@1|b|a|r| @68
+>f|i|n|d| |t|h|i|s| @65
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|f|o@1|b|a|r| @68
+|f|o@1|b|a|r| @68
+|f|o@1| @71
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|/|f|i|n|d| |t|h|i|s| @29|[|1|/|2|]| @11|2|,|1| @10|T|o|p| 
diff --git a/src/testdir/dumps/Test_searchstat_2.dump b/src/testdir/dumps/Test_searchstat_2.dump
new file mode 100644
index 0..a6ced4fd0
--- /dev/null
+++ b/src/testdir/dumps/Test_searchstat_2.dump
@@ -0,0 +1,10 @@
+|f+0&#ff0|o@1|b|a|r| @68
+>f|i|n|d| |t|h|i|s| @65
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+|f|o@1|b|a|r| @68
+|f|o@1|b|a|r| @68
+|f|o@1| @71
+|f|o@4|b|a|r| @65
+|f|o|b|a| @70
+@40|[|1|/|2|]| @11|2|,|1| @10|T|o|p| 
diff --git a/src/testdir/test_search_stat.vim b/src/testdir/test_search_stat.vim
index d5d50ff1d..9290c2f87 100644
--- a/src/testdir/test_search_stat.vim
+++ b/src/testdir/test_search_stat.vim
@@ -1,9 +1,7 @@
 " Tests for search_stats, when "S" is not in 'shortmess'
-"
-" This test is fragile, it might not work interactively, but it works when run
-" as test!
 
-source shared.vim
+source check.vim
+source screendump.vim
 
 func! Test_search_stat()
   new
@@ -181,7 +179,34 @@ func! Test_search_stat()
 
   " Clean up
   set shortmess+=S
-
   " close the window
   bwipe!
 endfunc
+
+func! Test_search_stat_screendump()
+  CheckScreendump
+
+  let lines =<< trim END
+set shortmess-=S
+" Append 50 lines with text to search for, "foobar" appears 20 times
+call append(0, repeat(['foobar', 'foo', 'fobar', 'foba', 'foobar'], 20))
+call setline(2, 'find this')
+call setline(70, 'find this')
+nnoremap n n
+let @/ = 'find this'
+call cursor(1,1)
+norm n
+  END
+  call writefile(lines, 'Xsearchstat')
+  let buf = RunVimInTerminal('-S Xsearchstat', #{rows: 10})
+  call term_wait(buf)
+  call VerifyScreenDump(buf, 'Test_searchstat_1', {})
+
+  call term_sendkeys(buf, ":nnoremap  n n\")
+  call term_sendkeys(buf, "gg0n")
+  call term_wait(buf)
+  call VerifyScreenDump(buf, 'Test_searchstat_2', {})
+
+  call StopVimInTerminal(buf)
+  call delete('XscriptMatchCommon')
+endfunc
-- 
2.20.1

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> > > > > On Fr, 30 Aug 2019, Bram Moolenaar wrote:
> > > > > 
> > > > > > Thanks.  Yes, I think we should do this.  But the allocation should
> > > > > > probably be done differently, it looks like with cmd_silent set it 
> > > > > > still
> > > > > > computes the size of the command.  This will require some more "if"
> > > > > > statements, but makes the size computation more accurate.
> > > > > 
> > > > > Well, yeah I thought this wouldn't hurt.
> > > > > 
> > > > > So how about the attached patch then? It will simply use all 
> > > > > available 
> > > > > space in the command line. Not sure this is correct however.
> > > > 
> > > > It's tricky with all the conditions.  But it looks OK.  All tests pass.
> > > > Let's include this and check that nothing goes wrong.  Can we cover this
> > > > with a test?
> > > 
> > > Apologizes, the last patch was wrong and caused a strtrunc message 
> > > ('...')  
> > > 
> > > Perhaps we don't even need the added condition `|| cmd_silent` at all?
> > > 
> > > Here is a fix including a test.
> > 
> > Thanks.  The test doesn't fail without the fix though.
> 
> Yeah, I did not update the test, I tried, but the message is not 
> truncated when running the test. I think this happens because the output 
> of `execute()` is actually scrolled. Not sure.
> 
> This patch should do it, but only works when run interactively.
> 
> diff --git a/src/testdir/test_search_stat.vim 
> b/src/testdir/test_search_stat.vim
> index f23952915..33c3858bc 100644
> --- a/src/testdir/test_search_stat.vim
> +++ b/src/testdir/test_search_stat.vim
> @@ -176,7 +176,9 @@ func! Test_search_stat()
>let g:b = split(g:a, "\n")[-1]
>let stat = '\[1/2\]'
>call assert_notmatch(pat .. stat, g:b)
> -  call assert_match(stat, g:b)
> +  " Test that the message is not truncated
> +  " it would insert '...' into the output.
> +  call assert_match('^\s\+' .. stat, g:b)
>unmap n
> 
>" Clean up

Hmm, since nobody runs the tests manually that doesn't help much.
How about using a screendump?  That makes these things a lot easier to
write.

-- 
I'm so disorganized my keyboard isn't even in alphabetical order!

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201909041121.x84BLsTM024711%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

On Di, 03 Sep 2019, Bram Moolenaar wrote:

> 
> Christian wrote:
> 
> > > > On Fr, 30 Aug 2019, Bram Moolenaar wrote:
> > > > 
> > > > > Thanks.  Yes, I think we should do this.  But the allocation should
> > > > > probably be done differently, it looks like with cmd_silent set it 
> > > > > still
> > > > > computes the size of the command.  This will require some more "if"
> > > > > statements, but makes the size computation more accurate.
> > > > 
> > > > Well, yeah I thought this wouldn't hurt.
> > > > 
> > > > So how about the attached patch then? It will simply use all available 
> > > > space in the command line. Not sure this is correct however.
> > > 
> > > It's tricky with all the conditions.  But it looks OK.  All tests pass.
> > > Let's include this and check that nothing goes wrong.  Can we cover this
> > > with a test?
> > 
> > Apologizes, the last patch was wrong and caused a strtrunc message 
> > ('...')  
> > 
> > Perhaps we don't even need the added condition `|| cmd_silent` at all?
> > 
> > Here is a fix including a test.
> 
> Thanks.  The test doesn't fail without the fix though.

Yeah, I did not update the test, I tried, but the message is not 
truncated when running the test. I think this happens because the output 
of `execute()` is actually scrolled. Not sure.

This patch should do it, but only works when run interactively.

diff --git a/src/testdir/test_search_stat.vim b/src/testdir/test_search_stat.vim
index f23952915..33c3858bc 100644
--- a/src/testdir/test_search_stat.vim
+++ b/src/testdir/test_search_stat.vim
@@ -176,7 +176,9 @@ func! Test_search_stat()
   let g:b = split(g:a, "\n")[-1]
   let stat = '\[1/2\]'
   call assert_notmatch(pat .. stat, g:b)
-  call assert_match(stat, g:b)
+  " Test that the message is not truncated
+  " it would insert '...' into the output.
+  call assert_match('^\s\+' .. stat, g:b)
   unmap n

   " Clean up


Mit freundlichen Grüßen
Christian
-- 
Das Werk sollte immer ein wenig schlauer sein als der Autor.
-- Vaclav Havel

-- 
-- 
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/20190904062502.GO25942%40256bit.org.

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> > > On Fr, 30 Aug 2019, Bram Moolenaar wrote:
> > > 
> > > > Thanks.  Yes, I think we should do this.  But the allocation should
> > > > probably be done differently, it looks like with cmd_silent set it still
> > > > computes the size of the command.  This will require some more "if"
> > > > statements, but makes the size computation more accurate.
> > > 
> > > Well, yeah I thought this wouldn't hurt.
> > > 
> > > So how about the attached patch then? It will simply use all available 
> > > space in the command line. Not sure this is correct however.
> > 
> > It's tricky with all the conditions.  But it looks OK.  All tests pass.
> > Let's include this and check that nothing goes wrong.  Can we cover this
> > with a test?
> 
> Apologizes, the last patch was wrong and caused a strtrunc message 
> ('...')  
> 
> Perhaps we don't even need the added condition `|| cmd_silent` at all?
> 
> Here is a fix including a test.

Thanks.  The test doesn't fail without the fix though.

-- 
hundred-and-one symptoms of being an internet addict:
172. You join listservers just for the extra e-mail.

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201909032024.x83KO53f022044%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

On Mo, 02 Sep 2019, Bram Moolenaar wrote:

> 
> Christian wrote:
> 
> > On Fr, 30 Aug 2019, Bram Moolenaar wrote:
> > 
> > > Thanks.  Yes, I think we should do this.  But the allocation should
> > > probably be done differently, it looks like with cmd_silent set it still
> > > computes the size of the command.  This will require some more "if"
> > > statements, but makes the size computation more accurate.
> > 
> > Well, yeah I thought this wouldn't hurt.
> > 
> > So how about the attached patch then? It will simply use all available 
> > space in the command line. Not sure this is correct however.
> 
> It's tricky with all the conditions.  But it looks OK.  All tests pass.
> Let's include this and check that nothing goes wrong.  Can we cover this
> with a test?

Apologizes, the last patch was wrong and caused a strtrunc message 
('...')  

Perhaps we don't even need the added condition `|| cmd_silent` at all?

Here is a fix including a test.

diff --git a/src/search.c b/src/search.c
index 758c4ef1a..ee66052a9 100644
--- a/src/search.c
+++ b/src/search.c
@@ -1391,7 +1391,7 @@ do_search(
// search stat.  Use all the space available, so that the
// search state is right aligned.  If there is not enough space
// msg_strtrunc() will shorten in the middle.
-   if (msg_scrolled != 0 || cmd_silent)
+   if (msg_scrolled != 0 && !cmd_silent)
// Use all the columns.
len = (int)(Rows - msg_row) * Columns - 1;
else
diff --git a/src/testdir/test_search_stat.vim b/src/testdir/test_search_stat.vim
index cf36f3214..f23952915 100644
--- a/src/testdir/test_search_stat.vim
+++ b/src/testdir/test_search_stat.vim
@@ -160,7 +160,27 @@ func! Test_search_stat()
   let stat = '\[1/2\]'
   call assert_notmatch(pat .. stat, g:a)

-  " close the window
+  " normal, n comes from a silent mapping
+  " First test a normal mapping, then a silent mapping
+  call cursor(1,1)
+  nnoremap n n
+  let @/ = 'find this'
+  let pat = '/find this\s\+'
+  let g:a = execute(':unsilent :norm n')
+  let g:b = split(g:a, "\n")[-1]
+  let stat = '\[1/2\]'
+  call assert_match(pat .. stat, g:b)
+  nnoremap  n n
+  call cursor(1,1)
+  let g:a = execute(':unsilent :norm n')
+  let g:b = split(g:a, "\n")[-1]
+  let stat = '\[1/2\]'
+  call assert_notmatch(pat .. stat, g:b)
+  call assert_match(stat, g:b)
+  unmap n
+
+  " Clean up
   set shortmess+=S
+  " close the window
   bwipe!
 endfunc


Best,
Christian
-- 
Sitzt eine Spinne auf dem Klo, wird man des Lebens nicht mehr froh.

-- 
-- 
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/20190903073725.GN25942%40256bit.org.

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> On Fr, 30 Aug 2019, Bram Moolenaar wrote:
> 
> > Thanks.  Yes, I think we should do this.  But the allocation should
> > probably be done differently, it looks like with cmd_silent set it still
> > computes the size of the command.  This will require some more "if"
> > statements, but makes the size computation more accurate.
> 
> Well, yeah I thought this wouldn't hurt.
> 
> So how about the attached patch then? It will simply use all available 
> space in the command line. Not sure this is correct however.

It's tricky with all the conditions.  But it looks OK.  All tests pass.
Let's include this and check that nothing goes wrong.  Can we cover this
with a test?

-- 
"Hit any key to continue" is very confusing when you have two keyboards.

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201909021945.x82JjHVh019218%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

On Fr, 30 Aug 2019, Bram Moolenaar wrote:

> Thanks.  Yes, I think we should do this.  But the allocation should
> probably be done differently, it looks like with cmd_silent set it still
> computes the size of the command.  This will require some more "if"
> statements, but makes the size computation more accurate.

Well, yeah I thought this wouldn't hurt.

So how about the attached patch then? It will simply use all available 
space in the command line. Not sure this is correct however.

Best,
Christian
-- 
Wie man sein Kind nicht nennen sollte: 
  Carmen Bert 

-- 
-- 
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/20190902074836.GM25942%40256bit.org.
diff --git a/src/search.c b/src/search.c
index 46273e11e..21458fae3 100644
--- a/src/search.c
+++ b/src/search.c
@@ -1354,8 +1354,9 @@ do_search(
 	pat = p;			/* put pat after search command */
 	}
 
-	if ((options & SEARCH_ECHO) && messaging()
-	&& !cmd_silent && msg_silent == 0)
+	if ((options & SEARCH_ECHO) && messaging() &&
+		!msg_silent &&
+		(!cmd_silent || !shortmess(SHM_SEARCHCOUNT)))
 	{
 	char_u	*trunc;
 	char_u	off_buf[40];
@@ -1365,7 +1366,8 @@ do_search(
 	msg_start();
 
 	// Get the offset, so we know how long it is.
-	if (spats[0].off.line || spats[0].off.end || spats[0].off.off)
+	if (!cmd_silent &&
+		(spats[0].off.line || spats[0].off.end || spats[0].off.off))
 	{
 		p = off_buf;
 		*p++ = dirc;
@@ -1386,13 +1388,13 @@ do_search(
 	else
 		p = searchstr;
 
-	if (!shortmess(SHM_SEARCHCOUNT))
+	if (!shortmess(SHM_SEARCHCOUNT) || cmd_silent)
 	{
 		// Reserve enough space for the search pattern + offset +
 		// search stat.  Use all the space available, so that the
 		// search state is right aligned.  If there is not enough space
 		// msg_strtrunc() will shorten in the middle.
-		if (msg_scrolled != 0)
+		if (msg_scrolled != 0 || cmd_silent)
 		// Use all the columns.
 		len = (int)(Rows - msg_row) * Columns - 1;
 		else
@@ -1409,62 +1411,67 @@ do_search(
 	if (msgbuf != NULL)
 	{
 		vim_memset(msgbuf, ' ', len);
-		msgbuf[0] = dirc;
 		msgbuf[len - 1] = NUL;
-
-		if (enc_utf8 && utf_iscomposing(utf_ptr2char(p)))
-		{
-		// Use a space to draw the composing char on.
-		msgbuf[1] = ' ';
-		mch_memmove(msgbuf + 2, p, STRLEN(p));
-		}
-		else
-		mch_memmove(msgbuf + 1, p, STRLEN(p));
-		if (off_len > 0)
-		mch_memmove(msgbuf + STRLEN(p) + 1, off_buf, off_len);
-
-		trunc = msg_strtrunc(msgbuf, TRUE);
-		if (trunc != NULL)
+		// do not fill the msgbuf buffer, if cmd_silent is set, leave it
+		// empty for the search_stat feature.
+		if (!cmd_silent)
 		{
-		vim_free(msgbuf);
-		msgbuf = trunc;
-		}
+		msgbuf[0] = dirc;
 
-#ifdef FEAT_RIGHTLEFT
-		// The search pattern could be shown on the right in rightleft
-		// mode, but the 'ruler' and 'showcmd' area use it too, thus
-		// it would be blanked out again very soon.  Show it on the
-		// left, but do reverse the text.
-		if (curwin->w_p_rl && *curwin->w_p_rlc == 's')
-		{
-		char_u *r;
-		size_t pat_len;
+		if (enc_utf8 && utf_iscomposing(utf_ptr2char(p)))
+		{
+			// Use a space to draw the composing char on.
+			msgbuf[1] = ' ';
+			mch_memmove(msgbuf + 2, p, STRLEN(p));
+		}
+		else
+			mch_memmove(msgbuf + 1, p, STRLEN(p));
+		if (off_len > 0)
+			mch_memmove(msgbuf + STRLEN(p) + 1, off_buf, off_len);
 
-		r = reverse_text(msgbuf);
-		if (r != NULL)
+		trunc = msg_strtrunc(msgbuf, TRUE);
+		if (trunc != NULL)
 		{
 			vim_free(msgbuf);
-			msgbuf = r;
-			// move reversed text to beginning of buffer
-			while (*r != NUL && *r == ' ')
-			r++;
-			pat_len = msgbuf + STRLEN(msgbuf) - r;
-			mch_memmove(msgbuf, r, pat_len);
-			// overwrite old text
-			if ((size_t)(r - msgbuf) >= pat_len)
-			vim_memset(r, ' ', pat_len);
-			else
-			vim_memset(msgbuf + pat_len, ' ', r - msgbuf);
+			msgbuf = trunc;
 		}
+
+#ifdef FEAT_RIGHTLEFT
+		// The search pattern could be shown on the right in rightleft
+		// mode, but the 'ruler' and 'showcmd' area use it too, thus
+		// it would be blanked out again very soon.  Show it on the
+		// left, but do reverse the text.
+		if (curwin->w_p_rl && *curwin->w_p_rlc == 's')
+		{
+			char_u *r;
+			size_t pat_len;
+
+			r = reverse_text(msgbuf);
+			if (r != NULL)
+			{
+			vim_free(msgbuf);
+			msgbuf = r;
+			// move reversed text to beginning of buffer
+			while (*r != NUL && *r == ' ')
+r++;
+			pat_

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> On Do, 29 Aug 2019, Gary Johnson wrote:
> 
> > 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.
> 
> Hm, yeah I can reproduce it. I am not sure yet, what causes the extra 
> redraw of the command line.

It's probably just the scrolling.  And it's probably tricky to keep the
counts when moving around in the file.  I don't mind too much, so long
as it shows right after the search navigation.

-- 
"The sun oozed over the horizon, shoved aside darkness, crept along the
greensward, and, with sickly fingers, pushed through the castle window,
revealing the pillaged princess, hand at throat, crown asunder, gaping
in frenzied horror at the sated, sodden amphibian lying beside her,
disbelieving the magnitude of the frog's deception, screaming madly,
"You lied!"
- Winner of the Bulwer-Lytton contest (San Jose State University),
  wherein one writes only the first line of a bad novel

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201908301112.x7UBCrfx004773%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Bram Moolenaar]

Christian wrote:

> On Do, 29 Aug 2019, Bram Moolenaar wrote:
> 
> > The  argument means that the command won't be echoed.  But it
> > does not suppress the output of the command like the ":silent" modifier
> > does.
> 
> Yeah, but it felt natural to me, to only show the search index feature, 
> if the command is echoed. I actually played with a simple patch 
> yesterday, but then thought that  works as expected.
> 
> > How about removing the check for cmd_silent in search.c, where
> > search_stat() is called?
> 
> It's a bit more convoluted, since msgbuf needs to be properly allocated 
> and initialized.
> 
> The attached patch does it. Let me know if you think that is okay. I can 
> write a test then.

Thanks.  Yes, I think we should do this.  But the allocation should
probably be done differently, it looks like with cmd_silent set it still
computes the size of the command.  This will require some more "if"
statements, but makes the size computation more accurate.

-- 
Birthdays are healthy.  The more you have them, the longer you live.

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201908301112.x7UBCrnm004785%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

On Do, 29 Aug 2019, 'Andy Wokula' via vim_use wrote:

> > nmap n nzv
> > nnoremap  zv zv:call AdjCursor()
> 
> :nmap  n  n(adj-cursor)
> :nnoremap   (adj-cursor)  zv:call AdjCursor()
> 
> 
> " first command can be written as:
> :nmap 

Re: Mapping erases search count message

[Christian Brabandt]

On Do, 29 Aug 2019, Gary Johnson wrote:

> 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.

Hm, yeah I can reproduce it. I am not sure yet, what causes the extra 
redraw of the command line.

Best,
Christian
-- 
Wußten Sie schon...
... daß ein Knall schneller als der Schall sein kann?

-- 
-- 
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/20190830062136.GK25942%40256bit.org.

Re: Mapping erases search count message

[Christian Brabandt]

On Do, 29 Aug 2019, Bram Moolenaar wrote:

> The  argument means that the command won't be echoed.  But it
> does not suppress the output of the command like the ":silent" modifier
> does.

Yeah, but it felt natural to me, to only show the search index feature, 
if the command is echoed. I actually played with a simple patch 
yesterday, but then thought that  works as expected.

> How about removing the check for cmd_silent in search.c, where
> search_stat() is called?

It's a bit more convoluted, since msgbuf needs to be properly allocated 
and initialized.

The attached patch does it. Let me know if you think that is okay. I can 
write a test then.

Mit freundlichen Grüßen
Christian
-- 
Fragt der Arzt:
"Rauchen Sie?"
"Nein."
"Trinken Sie?"
"Nein."
Darauf der Arzt:
"Grinsen Sie nicht so blöd, ich find schon noch was!"

-- 
-- 
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/20190830061958.GJ25942%40256bit.org.
From 6e56a15734d34a449235145265d5bff26466db93 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Fri, 30 Aug 2019 08:17:07 +0200
Subject: [PATCH] Show the search_index feature also for silent mappings

---
 src/search.c | 106 ++-
 1 file changed, 55 insertions(+), 51 deletions(-)

diff --git a/src/search.c b/src/search.c
index 46273e11e..568b27ecc 100644
--- a/src/search.c
+++ b/src/search.c
@@ -1354,8 +1354,7 @@ do_search(
 	pat = p;			/* put pat after search command */
 	}
 
-	if ((options & SEARCH_ECHO) && messaging()
-	&& !cmd_silent && msg_silent == 0)
+	if ((options & SEARCH_ECHO) && messaging() && !msg_silent)
 	{
 	char_u	*trunc;
 	char_u	off_buf[40];
@@ -1409,62 +1408,67 @@ do_search(
 	if (msgbuf != NULL)
 	{
 		vim_memset(msgbuf, ' ', len);
-		msgbuf[0] = dirc;
 		msgbuf[len - 1] = NUL;
-
-		if (enc_utf8 && utf_iscomposing(utf_ptr2char(p)))
-		{
-		// Use a space to draw the composing char on.
-		msgbuf[1] = ' ';
-		mch_memmove(msgbuf + 2, p, STRLEN(p));
-		}
-		else
-		mch_memmove(msgbuf + 1, p, STRLEN(p));
-		if (off_len > 0)
-		mch_memmove(msgbuf + STRLEN(p) + 1, off_buf, off_len);
-
-		trunc = msg_strtrunc(msgbuf, TRUE);
-		if (trunc != NULL)
+		// do not fill the msgbuf buffer, if cmd_silent is set, leave it
+		// empty for the search_stat feature.
+		if (!cmd_silent)
 		{
-		vim_free(msgbuf);
-		msgbuf = trunc;
-		}
+		msgbuf[0] = dirc;
 
-#ifdef FEAT_RIGHTLEFT
-		// The search pattern could be shown on the right in rightleft
-		// mode, but the 'ruler' and 'showcmd' area use it too, thus
-		// it would be blanked out again very soon.  Show it on the
-		// left, but do reverse the text.
-		if (curwin->w_p_rl && *curwin->w_p_rlc == 's')
-		{
-		char_u *r;
-		size_t pat_len;
+		if (enc_utf8 && utf_iscomposing(utf_ptr2char(p)))
+		{
+			// Use a space to draw the composing char on.
+			msgbuf[1] = ' ';
+			mch_memmove(msgbuf + 2, p, STRLEN(p));
+		}
+		else
+			mch_memmove(msgbuf + 1, p, STRLEN(p));
+		if (off_len > 0)
+			mch_memmove(msgbuf + STRLEN(p) + 1, off_buf, off_len);
 
-		r = reverse_text(msgbuf);
-		if (r != NULL)
+		trunc = msg_strtrunc(msgbuf, TRUE);
+		if (trunc != NULL)
 		{
 			vim_free(msgbuf);
-			msgbuf = r;
-			// move reversed text to beginning of buffer
-			while (*r != NUL && *r == ' ')
-			r++;
-			pat_len = msgbuf + STRLEN(msgbuf) - r;
-			mch_memmove(msgbuf, r, pat_len);
-			// overwrite old text
-			if ((size_t)(r - msgbuf) >= pat_len)
-			vim_memset(r, ' ', pat_len);
-			else
-			vim_memset(msgbuf + pat_len, ' ', r - msgbuf);
+			msgbuf = trunc;
 		}
-		}
-#endif
-		msg_outtrans(msgbuf);
-		msg_clr_eos();
-		msg_check();
 
-		gotocmdline(FALSE);
-		out_flush();
-		msg_nowait = TRUE;	// don't wait for this message
+#ifdef FEAT_RIGHTLEFT
+		// The search pattern could be shown on the right in rightleft
+		// mode, but the 'ruler' and 'showcmd' area use it too, thus
+		// it would be blanked out again very soon.  Show it on the
+		// left, but do reverse the text.
+		if (curwin->w_p_rl && *curwin->w_p_rlc == 's')
+		{
+			char_u *r;
+			size_t pat_len;
+
+			r = reverse_text(msgbuf);
+			if (r != NULL)
+			{
+			vim_free(msgbuf);
+			msgbuf = r;
+			// move reversed text to beginning of buffer
+			while (*r != NUL && *r == ' ')
+r++;
+			pat_len = msgbuf + STRLEN(msgbuf) - r;
+			mch_memmove(msgbuf, r, pat_len);
+			// overwrite old text
+			if ((size_t)(r - msgbuf) >= pat_len)
+

Re: Mapping erases search count message

[Gary Johnson]

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  n nzv:call AdjCursor()
> > > > > nnoremap  N Nzv:call AdjCursor()
> > > > > 
> > > > > Here is a simple experiment that demonstrates the problem.  Create
> > > > > a file, test.vim, that contains the following.
> > > > > 
> > > > > set shortmess-=S
> > > > > nnoremap  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  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 `` 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  n n`).
> 
> So the obvious fix would be to remove the `` 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  zv zv:call AdjCursor()

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:
tempora

Re: Mapping erases search count message

['Andy Wokula' via vim_use]

Am 29.08.2019 um 17:36 schrieb Christian Brabandt:


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  n nzv:call AdjCursor()
 nnoremap  N Nzv:call AdjCursor()

Here is a simple experiment that demonstrates the problem.  Create
a file, test.vim, that contains the following.

 set shortmess-=S
 nnoremap  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  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 `` 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  n n`).

So the obvious fix would be to remove the `` 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:


This is what 

Re: Mapping erases search count message

[Bram Moolenaar]

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  n nzv:call AdjCursor()
> > > > > nnoremap  N Nzv:call AdjCursor()
> > > > > 
> > > > > Here is a simple experiment that demonstrates the problem.  Create
> > > > > a file, test.vim, that contains the following.
> > > > > 
> > > > > set shortmess-=S
> > > > > nnoremap  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  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 `` 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  n n`).
> 
> So the obvious fix would be to remove the `` 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  zv zv:call AdjCursor()

The  argument means that the command won't be echoed.  But it
does not suppress the output of the command like the ":silent" modifier
does.

How about removing the check for cmd_silent in search.c, where
search_stat() is called?

-- 
hundred-and-one symptoms of being an internet addict:
131. You challenge authority and society by portnuking people

 /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_use/201908291859.x7TIx2gh026578%40masaka.moolenaar.net.

Re: Mapping erases search count message

[Christian Brabandt]

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  n nzv:call AdjCursor()
> > > > nnoremap  N Nzv:call AdjCursor()
> > > > 
> > > > Here is a simple experiment that demonstrates the problem.  Create
> > > > a file, test.vim, that contains the following.
> > > > 
> > > > set shortmess-=S
> > > > nnoremap  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  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 `` 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  n n`).

So the obvious fix would be to remove the `` 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  zv zv:call AdjCursor()

Best,
Christian
-- 
Man darf nicht das Gras wachsen hören, sonst wird man taub.
-- Gerhard Hauptmann

-- 
-- 
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/20190829153613.GI25942%40256bit.org.

Re: Mapping erases search count message

[Christian Brabandt]

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  n nzv:call AdjCursor()
> > > nnoremap  N Nzv:call AdjCursor()
> > > 
> > > Here is a simple experiment that demonstrates the problem.  Create
> > > a file, test.vim, that contains the following.
> > > 
> > > set shortmess-=S
> > > nnoremap  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  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.

Best,
Christian
-- 
Was die Gesellschaft öffentliche Meinung nennt, heißt beim einzelnen
Menschen Vorurteil.
-- Karl Heinrich Waggerl

-- 
-- 
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/20190829092521.GF25942%40256bit.org.

Re: Mapping erases search count message

[Tony Mechelynck]

On Wed, Aug 28, 2019 at 8:12 AM Gary Johnson  wrote:
> Yes, if you were to use those first two mappings without the
> AdjCursor() function defined, I would expect them to fail as you
> describe.  You can avoid that by defining AdjCursor() as an empty
> function.  Alternatively, you can use the mapping that I intended
> for you to use to demonstrate the problem, the one defined in
> test.vim.
>
> Regards,
> Gary

Ah, sorry. Well, with ":noremap  n n" the count is indeed not
echoed, but with ":noremap n n" instead, it is. I suppose that the
 switch avoids output from the normal-mode {rhs} and that what
the help says about the need for an additional ":silent" in the {rhs}
applies to an ex-command, which is not what we have here.

Best regards,
Tony.

-- 
-- 
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/CAJkCKXsAz5Tz3mPomDJfX3%3DpAsgQ8Y%3Dr3wEH1GRp6Ygvh0tjCA%40mail.gmail.com.

Re: Mapping erases search count message

[Gary Johnson]

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  n nzv:call AdjCursor()
> > nnoremap  N Nzv:call AdjCursor()
> > 
> > Here is a simple experiment that demonstrates the problem.  Create
> > a file, test.vim, that contains the following.
> > 
> > set shortmess-=S
> > nnoremap  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  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.

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/20190828061843.GA27112%40phoenix.

Re: Mapping erases search count message

[Gary Johnson]

On 2019-08-28, Tony Mechelynck wrote:
> On Wed, Aug 28, 2019 at 7:31 AM 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  n nzv:call AdjCursor()
> > nnoremap  N Nzv:call AdjCursor()
> >
> > Here is a simple experiment that demonstrates the problem.  Create
> > a file, test.vim, that contains the following.
> >
> > set shortmess-=S
> > nnoremap  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  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?
> >
> > Regards,
> > Gary
> 
> I can't reproduce the problem.
> 
> What I get by hitting n after applying your mappings is:
> 
> E117: Unknown function: AdjCursor
> 
> With no mappings, the count is of course corectly shown.

Yes, if you were to use those first two mappings without the
AdjCursor() function defined, I would expect them to fail as you
describe.  You can avoid that by defining AdjCursor() as an empty
function.  Alternatively, you can use the mapping that I intended
for you to use to demonstrate the problem, the one defined in
test.vim.

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/20190828061339.GA26834%40phoenix.

Re: Mapping erases search count message

[Christian Brabandt]

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  n nzv:call AdjCursor()
> nnoremap  N Nzv:call AdjCursor()
> 
> Here is a simple experiment that demonstrates the problem.  Create
> a file, test.vim, that contains the following.
> 
> set shortmess-=S
> nnoremap  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  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?

Best,
Christian
-- 
Wer nicht mit der Zeit geht, geht mit der Zeit!

-- 
-- 
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/20190828060810.GA25942%40256bit.org.

Re: Mapping erases search count message

[Tony Mechelynck]

On Wed, Aug 28, 2019 at 7:31 AM 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  n nzv:call AdjCursor()
> nnoremap  N Nzv:call AdjCursor()
>
> Here is a simple experiment that demonstrates the problem.  Create
> a file, test.vim, that contains the following.
>
> set shortmess-=S
> nnoremap  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  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?
>
> Regards,
> Gary

I can't reproduce the problem.

What I get by hitting n after applying your mappings is:

E117: Unknown function: AdjCursor

With no mappings, the count is of course corectly shown.


Best regards,
Tony.

-- 
-- 
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/CAJkCKXvKtBMUP%2B7v%3D5yM8P4r%2BtMahhr%2B2nZmKqDVR7xVoVcUZg%40mail.gmail.com.