On Sat, Aug 31, 2019 at 10:02:53AM -0400, Salman Halim wrote:
>If I search for "abcd" with incremental search enabled, the search
>characters get highlighted as I type them, which is obviously why I have
>incremental search enabled. However, when I look through my search history,
>I'm pretty sure I used to only see the one search entry for "abcd". These
>days, I see four: a, ab, abc and abcd. What happened?
Perhaps a plugin or other setting is interfering. Try with "vim -Nu NONE".
--
--
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/20190831160653.GA9445%40rainslide.net.
Saturday, August 31, 2019
Re: 回复：auto indent
On Tue, Aug 27, 2019 at 11:11:56AM +0200, Tony Mechelynck wrote:
>What you can do is ":set paste" just before pasting and ":set nopaste"
>afterwards. Or use a 'pastetoggle' as explained in the help.
Another option is to make use of bracketed paste, if possible: https://cirw.in/blog/bracketed-paste
--
--
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/20190831155533.GA8816%40rainslide.net.
>What you can do is ":set paste" just before pasting and ":set nopaste"
>afterwards. Or use a 'pastetoggle' as explained in the help.
Another option is to make use of bracketed paste, if possible: https://cirw.in/blog/bracketed-paste
--
--
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/20190831155533.GA8816%40rainslide.net.
Search history question
I started noticing this a while ago, but it's somewhat new (months, not years):
-- If I search for "abcd" with incremental search enabled, the search characters get highlighted as I type them, which is obviously why I have incremental search enabled. However, when I look through my search history, I'm pretty sure I used to only see the one search entry for "abcd". These days, I see four: a, ab, abc and abcd. What happened?
This adds entries that don't really do anything because I might be in the middle of a regular expression and having search entries containing partially-entered expressions are somewhat meaningless, such as \( but without a closing \).
Is there a way to only have it register the entry in the search history when I press enter?
Obviously, setting @/ via a let creates just the one entry, but that's when I don't care about the incremental display.
Best regards,
--
Salman
Salman
--
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/CANuxnEfs86XdN64%3Dw%3DHcmc01S-om%2BcMuUCS%3DjN0KLoW3cdUWsg%40mail.gmail.com.
Friday, August 30, 2019
Re: Mapping erases search count message
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 -- 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/201908301112.x7UBCrfx004773%40masaka.moolenaar.net.
> 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 -- 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/201908301112.x7UBCrfx004773%40masaka.moolenaar.net.
Re: Mapping erases search count message
Christian wrote:
> On Do, 29 Aug 2019, Bram Moolenaar wrote:
>
> > The <silent> 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 <silent> 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 -- 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/201908301112.x7UBCrnm004785%40masaka.moolenaar.net.
> On Do, 29 Aug 2019, Bram Moolenaar wrote:
>
> > The <silent> 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 <silent> 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 -- 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/201908301112.x7UBCrnm004785%40masaka.moolenaar.net.
Re: Mapping erases search count message
On Do, 29 Aug 2019, 'Andy Wokula' via vim_use wrote:
> > nmap n nzv
> > nnoremap <silent> zv zv:call AdjCursor()<cr>
>
> :nmap n n<SID>(adj-cursor)
> :nnoremap <silent> <SID>(adj-cursor) zv:call AdjCursor()<CR>
>
>
> " first command can be written as:
> :nmap <script> n n<SID>(adj-cursor)
> :nnoremap <script> n n<SID>(adj-cursor)
Ah yes, I always forget about that possibility.
Best,
Christian
--
Hätten die Neandertaler Atomkraftwerke besessen, wir hätten heute noch
damit zu tun.
-- Jürgen Trittin
--
--
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/20190830074942.GL25942%40256bit.org.
> > nmap n nzv
> > nnoremap <silent> zv zv:call AdjCursor()<cr>
>
> :nmap n n<SID>(adj-cursor)
> :nnoremap <silent> <SID>(adj-cursor) zv:call AdjCursor()<CR>
>
>
> " first command can be written as:
> :nmap <script> n n<SID>(adj-cursor)
> :nnoremap <script> n n<SID>(adj-cursor)
Ah yes, I always forget about that possibility.
Best,
Christian
--
Hätten die Neandertaler Atomkraftwerke besessen, wir hätten heute noch
damit zu tun.
-- Jürgen Trittin
--
--
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/20190830074942.GL25942%40256bit.org.
Thursday, August 29, 2019
Re: Mapping erases search count message
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190830062136.GK25942%40256bit.org.
> 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+unsubscribe@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
From 6e56a15734d34a449235145265d5bff26466db93 Mon Sep 17 00:00:00 2001
From: Christian Brabandt <cb@256bit.org>
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)
+ vim_memset(r, ' ', pat_len);
+ else
+ vim_memset(msgbuf + pat_len, ' ', r - msgbuf);
+ }
+ }
+ #endif
+ msg_outtrans(msgbuf);
+ msg_clr_eos();
+ msg_check();
+
+ gotocmdline(FALSE);
+ out_flush();
+ msg_nowait = TRUE; // don't wait for this message
+ }
}
}
@@ -1572,7 +1576,7 @@ do_search(
// Show [1/15] if 'S' is not in 'shortmess'.
if ((options & SEARCH_ECHO)
&& messaging()
- && !(cmd_silent + msg_silent)
+ && !msg_silent
&& c != FAIL
&& !shortmess(SHM_SEARCHCOUNT)
&& msgbuf != NULL)
--
2.20.1
On Do, 29 Aug 2019, Bram Moolenaar wrote:
> The <silent> 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 <silent> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190830061958.GJ25942%40256bit.org.
From: Christian Brabandt <cb@256bit.org>
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)
+ vim_memset(r, ' ', pat_len);
+ else
+ vim_memset(msgbuf + pat_len, ' ', r - msgbuf);
+ }
+ }
+ #endif
+ msg_outtrans(msgbuf);
+ msg_clr_eos();
+ msg_check();
+
+ gotocmdline(FALSE);
+ out_flush();
+ msg_nowait = TRUE; // don't wait for this message
+ }
}
}
@@ -1572,7 +1576,7 @@ do_search(
// Show [1/15] if 'S' is not in 'shortmess'.
if ((options & SEARCH_ECHO)
&& messaging()
- && !(cmd_silent + msg_silent)
+ && !msg_silent
&& c != FAIL
&& !shortmess(SHM_SEARCHCOUNT)
&& msgbuf != NULL)
--
2.20.1
On Do, 29 Aug 2019, Bram Moolenaar wrote:
> The <silent> 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 <silent> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190830061958.GJ25942%40256bit.org.
Re: Failed to parse vim.desktop file msgs
Hi,
-- I checked it for invalid utf-8 and it was clean as far as I can tell.
I'll keep digging.
thx,
-m
--
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/dff1f7c1-3820-4c4a-b0df-7a22106025f5%40googlegroups.com.
Re: Mapping erases search count message
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
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829205233.GB27112%40phoenix.
> 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
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829205233.GB27112%40phoenix.
Re: Mapping erases search count message
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 <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:
This is what <script> mappings are for.
> nmap n nzv
> nnoremap <silent> zv zv:call AdjCursor()<cr>
:nmap n n<SID>(adj-cursor)
:nnoremap <silent> <SID>(adj-cursor) zv:call AdjCursor()<CR>
" first command can be written as:
:nmap <script> n n<SID>(adj-cursor)
:nnoremap <script> n n<SID>(adj-cursor)
--
Andy
--
--
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/5D682DFC.2070903%40yahoo.de.
>
> 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:
This is what <script> mappings are for.
> nmap n nzv
> nnoremap <silent> zv zv:call AdjCursor()<cr>
:nmap n n<SID>(adj-cursor)
:nnoremap <silent> <SID>(adj-cursor) zv:call AdjCursor()<CR>
" first command can be written as:
:nmap <script> n n<SID>(adj-cursor)
:nnoremap <script> n n<SID>(adj-cursor)
--
Andy
--
--
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/5D682DFC.2070903%40yahoo.de.
Re: Mapping erases search count message
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>
The <silent> 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 -- 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/201908291859.x7TIx2gh026578%40masaka.moolenaar.net.
> 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>
The <silent> 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 -- 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/201908291859.x7TIx2gh026578%40masaka.moolenaar.net.
Re: What happened to "Search hit BOTTOM, continuing at TOP"?
On Thu, Aug 29, 2019 at 01:30:06PM +0200, Christian Brabandt wrote:
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.
Why is overwriting a concern? There should be enough space in a
80-column wide terminal to display
search hit TOP, continuing at BOTTOM [1/3]
with no need for a pause (which would be annoying, it's what Mutt does
after it displays error messages and I feel annoyance every time it does that).
Marius Gedminas
--
A body of SF less upbeat than US SF as a whole right now probably involves a
community too paralyzed by clinical depression to pick up a pen, let alone
compose.
-- James Nicoll
--
--
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/20190829183911.m5gcygd44t4hv2hf%40blynas.
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.
Why is overwriting a concern? There should be enough space in a
80-column wide terminal to display
search hit TOP, continuing at BOTTOM [1/3]
with no need for a pause (which would be annoying, it's what Mutt does
after it displays error messages and I feel annoyance every time it does that).
Marius Gedminas
--
A body of SF less upbeat than US SF as a whole right now probably involves a
community too paralyzed by clinical depression to pick up a pen, let alone
compose.
-- James Nicoll
--
--
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/20190829183911.m5gcygd44t4hv2hf%40blynas.
Re: Are the --enable-hangulinput and --enable-xim confilct?
Namsh wrote:
> >> 2019-08-25 오후 2:25에 Hongyi Zhao 이(가) 쓴 글:
> >>> Hi,
> >>>
> >>> I try to build vim with the --enable-hangulinput and --enable-xim
> >>> confilct at the same time, but failed with error:
> >>>
> >>> -------------------------
> >>> vim.h:1585:63: error: called object 'size_t' is not a function or
> >>> function pointer
> >>> #define STRNCMP(d, s, n) strncmp((char *)(d), (char *)(s), (size_t)(n))
> >>> ^
> >>> ex_docmd.c:8459:6: note: in expansion of macro 'STRNCMP'
> >>> if (STRNCMP(arg, "FALLBACK ", 9) == 0)
> >>> ^~~~~~~
> >>> In file included from /usr/include/wchar.h:887:0,
> >>> from spell.h:250,
> >>> from vim.h:2110,
> >>> from ex_docmd.c:14:
> >>> /usr/include/x86_64-linux-gnu/bits/wchar2.h:507:20: note: declared here
> >>> __fortify_function size_t
> >>> ^~~~~~
> >>> Makefile:3059: recipe for target 'objects/ex_docmd.o' failed
> >>> make[1]: *** [objects/ex_docmd.o] Error 1
> >>> make[1]: Leaving directory '/home/werner/software/editor/vim/vim.git/src'
> >>> Makefile:26: recipe for target 'first' failed
> >>> make: *** [first] Error 2
> >>> -----------------------------
> >>>
> >>> Are these two options conflict?
> >>
> >> Regardless of compilation error, the hangulin feature is for
> >> environments where XIM is not available.
> >>
> >> You can find next line with ':help hangul'.
> >> ./configure --with-x --enable-multibyte --enable-hangulinput \
> >> --disable-xim
> >
> > That's a bit of a disadvantage when someone tries to build a version
> > that works with multiple languages. Can we make this a runtime choice
> > instead of a compile time choice? No idea how much work that would be.
>
> Here is a minimal patch (no documentation, no indenting to minimize).
> If vim supports both xim and hangulinpt and user set 'imdisable',
> hangulinput feature is selected.
>
> I tested this patch by adding '--enable-xim --enable-hangulinput' to my
> default configure option.
> $ auto/configure --enable-perlinterp=no --disable-gpm
> --enable-python3interp=dynamic --enable-tclinterp=no --enable-cscope
> --with-features=huge --enable-terminal --enable-multibyte --enable-xim
> --enable-hangulinput --prefix=/opt/local --with-x --enable-gui=gtk3
>
> While testing this patch, I noticed one glitch.
> Though I set 'imdisable' in the vimrc and I confirmed the setting with
> ':set imdisable?', when I typed S-Space for the first time, vim connects
> to XIM. After that, go to english input mode and type S-Space again, vim
> enters to hangulinput mode. My system environement may cause this glitch??
Thanks. I think it always creates the "xim" object, also when
'imdisable' is set. Perhaps it starts in the wrong mode? It is
possible that a check for 'imdisable' is missing somewhere.
--
hundred-and-one symptoms of being an internet addict:
129. You cancel your newspaper subscription.
/// 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/201908291716.x7THG3Cj003761%40masaka.moolenaar.net.
> >> 2019-08-25 오후 2:25에 Hongyi Zhao 이(가) 쓴 글:
> >>> Hi,
> >>>
> >>> I try to build vim with the --enable-hangulinput and --enable-xim
> >>> confilct at the same time, but failed with error:
> >>>
> >>> -------------------------
> >>> vim.h:1585:63: error: called object 'size_t' is not a function or
> >>> function pointer
> >>> #define STRNCMP(d, s, n) strncmp((char *)(d), (char *)(s), (size_t)(n))
> >>> ^
> >>> ex_docmd.c:8459:6: note: in expansion of macro 'STRNCMP'
> >>> if (STRNCMP(arg, "FALLBACK ", 9) == 0)
> >>> ^~~~~~~
> >>> In file included from /usr/include/wchar.h:887:0,
> >>> from spell.h:250,
> >>> from vim.h:2110,
> >>> from ex_docmd.c:14:
> >>> /usr/include/x86_64-linux-gnu/bits/wchar2.h:507:20: note: declared here
> >>> __fortify_function size_t
> >>> ^~~~~~
> >>> Makefile:3059: recipe for target 'objects/ex_docmd.o' failed
> >>> make[1]: *** [objects/ex_docmd.o] Error 1
> >>> make[1]: Leaving directory '/home/werner/software/editor/vim/vim.git/src'
> >>> Makefile:26: recipe for target 'first' failed
> >>> make: *** [first] Error 2
> >>> -----------------------------
> >>>
> >>> Are these two options conflict?
> >>
> >> Regardless of compilation error, the hangulin feature is for
> >> environments where XIM is not available.
> >>
> >> You can find next line with ':help hangul'.
> >> ./configure --with-x --enable-multibyte --enable-hangulinput \
> >> --disable-xim
> >
> > That's a bit of a disadvantage when someone tries to build a version
> > that works with multiple languages. Can we make this a runtime choice
> > instead of a compile time choice? No idea how much work that would be.
>
> Here is a minimal patch (no documentation, no indenting to minimize).
> If vim supports both xim and hangulinpt and user set 'imdisable',
> hangulinput feature is selected.
>
> I tested this patch by adding '--enable-xim --enable-hangulinput' to my
> default configure option.
> $ auto/configure --enable-perlinterp=no --disable-gpm
> --enable-python3interp=dynamic --enable-tclinterp=no --enable-cscope
> --with-features=huge --enable-terminal --enable-multibyte --enable-xim
> --enable-hangulinput --prefix=/opt/local --with-x --enable-gui=gtk3
>
> While testing this patch, I noticed one glitch.
> Though I set 'imdisable' in the vimrc and I confirmed the setting with
> ':set imdisable?', when I typed S-Space for the first time, vim connects
> to XIM. After that, go to english input mode and type S-Space again, vim
> enters to hangulinput mode. My system environement may cause this glitch??
Thanks. I think it always creates the "xim" object, also when
'imdisable' is set. Perhaps it starts in the wrong mode? It is
possible that a check for 'imdisable' is missing somewhere.
--
hundred-and-one symptoms of being an internet addict:
129. You cancel your newspaper subscription.
/// 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/201908291716.x7THG3Cj003761%40masaka.moolenaar.net.
Re: What happened to "Search hit BOTTOM, continuing at TOP"?
On Thu, Aug 29, 2019 at 1:30 PM Christian Brabandt <cblists@256bit.org> wrote:
>
>
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.
>
> Best,
> Christian
Ah, that was it. Thanks Christian and Marius.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsGHx7E%3DGR4MbExGMiHtTLDWrjhEWsPiPXCdLf-uM3bbQ%40mail.gmail.com.
>
>
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.
>
> Best,
> Christian
Ah, that was it. Thanks Christian and Marius.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsGHx7E%3DGR4MbExGMiHtTLDWrjhEWsPiPXCdLf-uM3bbQ%40mail.gmail.com.
Re: Mapping erases search count message
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>
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829153613.GI25942%40256bit.org.
>
> 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>
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829153613.GI25942%40256bit.org.
Re: What happened to "Search hit BOTTOM, continuing at TOP"?
On Do, 29 Aug 2019, Marius Gedminas wrote:
> (I like the [N/M] index, but I also think the W is way too subtle, and I
> find myself looping again and again.)
When the N/M index was first introduced, it did show the error message
and forced a small delay to make sure it can be read before the N/M
index would potentially overwrite it. However people complained about
vim being unresponsive, so it was changed and the 'W' indicator was
added as a compromise.
Best,
Christian
--
Jeder Tag an dem du nicht lächelst, ist ein verlorener Tag.
-- Charlie Chaplin
--
--
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/20190829113006.GH25942%40256bit.org.
> (I like the [N/M] index, but I also think the W is way too subtle, and I
> find myself looping again and again.)
When the N/M index was first introduced, it did show the error message
and forced a small delay to make sure it can be read before the N/M
index would potentially overwrite it. However people complained about
vim being unresponsive, so it was changed and the 'W' indicator was
added as a compromise.
Best,
Christian
--
Jeder Tag an dem du nicht lächelst, ist ein verlorener Tag.
-- Charlie Chaplin
--
--
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/20190829113006.GH25942%40256bit.org.
Re: compiler plugin
On Do, 29 Aug 2019, Wesley Peng wrote:
> Does vim have a compiler plugin for compiling script languages like python?
Does https://github.com/vim/vim/tree/master/runtime/compiler answer your
question?
Best,
Christian
--
Dem Alltagsstreß kann man entgehen, vermeidet man es aufzustehen.
--
--
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/20190829112715.GG25942%40256bit.org.
> Does vim have a compiler plugin for compiling script languages like python?
Does https://github.com/vim/vim/tree/master/runtime/compiler answer your
question?
Best,
Christian
--
Dem Alltagsstreß kann man entgehen, vermeidet man es aufzustehen.
--
--
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/20190829112715.GG25942%40256bit.org.
compiler plugin
Does vim have a compiler plugin for compiling script languages like python?
Thanks.
--
--
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/2b00f6ed-4b64-3bdd-e0fb-ba29c4c27773%40gmail.com.
Thanks.
--
--
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/2b00f6ed-4b64-3bdd-e0fb-ba29c4c27773%40gmail.com.
Re: What happened to "Search hit BOTTOM, continuing at TOP"?
On Thu, Aug 29, 2019 at 08:56:15AM +0200, Tony Mechelynck wrote:
> :help 'shortmess' still says that the s flag means not to give the
> "Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
> searching, which I understand as meaning that in the absence of this
> flag, the message will be given. Well, I just noticed that in my
> current gvim build (Big 8.1.1935) it isn't, and yet the flag is
> absent. Maybe I unwittingly set some other option preventing it? Or
> has it been retired? I found this message useful to avoid unwittingly
> looping several times in succession through a file's text.
It's been replaced by the new [N/M] index shown on the bottom right.
Specifically, a little W appears after it, e.g.
[1/7] W
You can turn off the entire index with :set shortmess+=S and you'll get
the old "search hit TOP/BOTTOM, continuing at BOTTOM/TOP" message back.
(I like the [N/M] index, but I also think the W is way too subtle, and I
find myself looping again and again.)
Marius Gedminas
--
As a rule of thumb, I reckon Python to be an order of magnitude more wasteful
of CPU cycles and memory than my favourite low-level language, C++.
-- Thomas Guest
--
--
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/20190829101708.iiezumvnbuyui2jj%40blynas.
> :help 'shortmess' still says that the s flag means not to give the
> "Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
> searching, which I understand as meaning that in the absence of this
> flag, the message will be given. Well, I just noticed that in my
> current gvim build (Big 8.1.1935) it isn't, and yet the flag is
> absent. Maybe I unwittingly set some other option preventing it? Or
> has it been retired? I found this message useful to avoid unwittingly
> looping several times in succession through a file's text.
It's been replaced by the new [N/M] index shown on the bottom right.
Specifically, a little W appears after it, e.g.
[1/7] W
You can turn off the entire index with :set shortmess+=S and you'll get
the old "search hit TOP/BOTTOM, continuing at BOTTOM/TOP" message back.
(I like the [N/M] index, but I also think the W is way too subtle, and I
find myself looping again and again.)
Marius Gedminas
--
As a rule of thumb, I reckon Python to be an order of magnitude more wasteful
of CPU cycles and memory than my favourite low-level language, C++.
-- Thomas Guest
--
--
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/20190829101708.iiezumvnbuyui2jj%40blynas.
Re: Mapping erases search count message
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.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829092521.GF25942%40256bit.org.
> 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.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190829092521.GF25942%40256bit.org.
Re: What happened to "Search hit BOTTOM, continuing at TOP"?
On Do, 29 Aug 2019, Tony Mechelynck wrote:
> :help 'shortmess' still says that the s flag means not to give the
> "Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
> searching, which I understand as meaning that in the absence of this
> flag, the message will be given. Well, I just noticed that in my
> current gvim build (Big 8.1.1935) it isn't, and yet the flag is
> absent. Maybe I unwittingly set some other option preventing it? Or
> has it been retired? I found this message useful to avoid unwittingly
> looping several times in succession through a file's text.
Do you have the `S` removed from the shortmessage option? Then it will
output the search stat (and a trailing 'W' when it wrapped). Because
otherwise this warning message will overwrite the search_stat.
Best,
Christian
--
Endlich! - Das WerbeMüllLaberZuKaufmichKommerzGeldloswerdBuntiKlickiNetz
ist da. T-Online.
--
--
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/20190829092203.GE25942%40256bit.org.
> :help 'shortmess' still says that the s flag means not to give the
> "Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
> searching, which I understand as meaning that in the absence of this
> flag, the message will be given. Well, I just noticed that in my
> current gvim build (Big 8.1.1935) it isn't, and yet the flag is
> absent. Maybe I unwittingly set some other option preventing it? Or
> has it been retired? I found this message useful to avoid unwittingly
> looping several times in succession through a file's text.
Do you have the `S` removed from the shortmessage option? Then it will
output the search stat (and a trailing 'W' when it wrapped). Because
otherwise this warning message will overwrite the search_stat.
Best,
Christian
--
Endlich! - Das WerbeMüllLaberZuKaufmichKommerzGeldloswerdBuntiKlickiNetz
ist da. T-Online.
--
--
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/20190829092203.GE25942%40256bit.org.
Wednesday, August 28, 2019
What happened to "Search hit BOTTOM, continuing at TOP"?
:help 'shortmess' still says that the s flag means not to give the
"Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
searching, which I understand as meaning that in the absence of this
flag, the message will be given. Well, I just noticed that in my
current gvim build (Big 8.1.1935) it isn't, and yet the flag is
absent. Maybe I unwittingly set some other option preventing it? Or
has it been retired? I found this message useful to avoid unwittingly
looping several times in succession through a file's text.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXt8w4jUU2b0A_mTNXXxOgLsC1ugJTzvvHppPMG2Mm6xdg%40mail.gmail.com.
"Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
searching, which I understand as meaning that in the absence of this
flag, the message will be given. Well, I just noticed that in my
current gvim build (Big 8.1.1935) it isn't, and yet the flag is
absent. Maybe I unwittingly set some other option preventing it? Or
has it been retired? I found this message useful to avoid unwittingly
looping several times in succession through a file's text.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXt8w4jUU2b0A_mTNXXxOgLsC1ugJTzvvHppPMG2Mm6xdg%40mail.gmail.com.
Re: Are the --enable-hangulinput and --enable-xim confilct?
diff --git a/src/feature.h b/src/feature.h
index 8afa98797..3bca4fb54 100644
--- a/src/feature.h
+++ b/src/feature.h
@@ -569,9 +569,6 @@
# define ESC_CHG_TO_ENG_MODE /* if defined, when ESC pressed,
* turn to english mode
*/
-# if defined(FEAT_XIM) && !defined(LINT)
- Error: You should select only ONE of XIM and HANGUL INPUT
-# endif
#endif
#if defined(FEAT_HANGULIN) || defined(FEAT_XIM)
/* # define X_LOCALE */ /* for OS with incomplete locale
diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
index 4940b87e2..e34e9001a 100644
--- a/src/gui_gtk_x11.c
+++ b/src/gui_gtk_x11.c
@@ -1160,6 +1160,9 @@ key_press_event(GtkWidget *widget UNUSED,
#endif
#ifdef FEAT_HANGULIN
+#if defined(FEAT_XIM)
+ if (p_imdisable)
+#endif
if (key_sym == GDK_space && (state & GDK_SHIFT_MASK))
{
hangul_input_state_toggle();
diff --git a/src/gui_x11.c b/src/gui_x11.c
index 3555ffae0..155f0cca5 100644
--- a/src/gui_x11.c
+++ b/src/gui_x11.c
@@ -864,6 +864,9 @@ gui_x11_key_hit_cb(
#endif
#ifdef FEAT_HANGULIN
+#if defined(FEAT_XIM)
+ if (p_imdisable)
+#endif
if ((key_sym == XK_space) && (ev_press->state & ShiftMask))
{
hangul_input_state_toggle();
2019-08-27 오전 4:25에 Bram Moolenaar 이(가) 쓴 글:
>
> Namsh wrote:
>
>> 2019-08-25 오후 2:25에 Hongyi Zhao 이(가) 쓴 글:
>>> Hi,
>>>
>>> I try to build vim with the --enable-hangulinput and --enable-xim
>>> confilct at the same time, but failed with error:
>>>
>>> -------------------------
>>> vim.h:1585:63: error: called object 'size_t' is not a function or
>>> function pointer
>>> #define STRNCMP(d, s, n) strncmp((char *)(d), (char *)(s), (size_t)(n))
>>> ^
>>> ex_docmd.c:8459:6: note: in expansion of macro 'STRNCMP'
>>> if (STRNCMP(arg, "FALLBACK ", 9) == 0)
>>> ^~~~~~~
>>> In file included from /usr/include/wchar.h:887:0,
>>> from spell.h:250,
>>> from vim.h:2110,
>>> from ex_docmd.c:14:
>>> /usr/include/x86_64-linux-gnu/bits/wchar2.h:507:20: note: declared here
>>> __fortify_function size_t
>>> ^~~~~~
>>> Makefile:3059: recipe for target 'objects/ex_docmd.o' failed
>>> make[1]: *** [objects/ex_docmd.o] Error 1
>>> make[1]: Leaving directory '/home/werner/software/editor/vim/vim.git/src'
>>> Makefile:26: recipe for target 'first' failed
>>> make: *** [first] Error 2
>>> -----------------------------
>>>
>>> Are these two options conflict?
>>
>> Regardless of compilation error, the hangulin feature is for
>> environments where XIM is not available.
>>
>> You can find next line with ':help hangul'.
>> ./configure --with-x --enable-multibyte --enable-hangulinput \
>> --disable-xim
>
> That's a bit of a disadvantage when someone tries to build a version
> that works with multiple languages. Can we make this a runtime choice
> instead of a compile time choice? No idea how much work that would be.
Here is a minimal patch (no documentation, no indenting to minimize).
If vim supports both xim and hangulinpt and user set 'imdisable',
hangulinput feature is selected.
I tested this patch by adding '--enable-xim --enable-hangulinput' to my
default configure option.
$ auto/configure --enable-perlinterp=no --disable-gpm
--enable-python3interp=dynamic --enable-tclinterp=no --enable-cscope
--with-features=huge --enable-terminal --enable-multibyte --enable-xim
--enable-hangulinput --prefix=/opt/local --with-x --enable-gui=gtk3
While testing this patch, I noticed one glitch.
Though I set 'imdisable' in the vimrc and I confirmed the setting with
':set imdisable?', when I typed S-Space for the first time, vim connects
to XIM. After that, go to english input mode and type S-Space again, vim
enters to hangulinput mode. My system environement may cause this glitch??
Thanks,
namsh
--
--
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/47ca13c8-ba84-1334-dea3-b55adceb1029%40gmail.com.
index 8afa98797..3bca4fb54 100644
--- a/src/feature.h
+++ b/src/feature.h
@@ -569,9 +569,6 @@
# define ESC_CHG_TO_ENG_MODE /* if defined, when ESC pressed,
* turn to english mode
*/
-# if defined(FEAT_XIM) && !defined(LINT)
- Error: You should select only ONE of XIM and HANGUL INPUT
-# endif
#endif
#if defined(FEAT_HANGULIN) || defined(FEAT_XIM)
/* # define X_LOCALE */ /* for OS with incomplete locale
diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
index 4940b87e2..e34e9001a 100644
--- a/src/gui_gtk_x11.c
+++ b/src/gui_gtk_x11.c
@@ -1160,6 +1160,9 @@ key_press_event(GtkWidget *widget UNUSED,
#endif
#ifdef FEAT_HANGULIN
+#if defined(FEAT_XIM)
+ if (p_imdisable)
+#endif
if (key_sym == GDK_space && (state & GDK_SHIFT_MASK))
{
hangul_input_state_toggle();
diff --git a/src/gui_x11.c b/src/gui_x11.c
index 3555ffae0..155f0cca5 100644
--- a/src/gui_x11.c
+++ b/src/gui_x11.c
@@ -864,6 +864,9 @@ gui_x11_key_hit_cb(
#endif
#ifdef FEAT_HANGULIN
+#if defined(FEAT_XIM)
+ if (p_imdisable)
+#endif
if ((key_sym == XK_space) && (ev_press->state & ShiftMask))
{
hangul_input_state_toggle();
2019-08-27 오전 4:25에 Bram Moolenaar 이(가) 쓴 글:
>
> Namsh wrote:
>
>> 2019-08-25 오후 2:25에 Hongyi Zhao 이(가) 쓴 글:
>>> Hi,
>>>
>>> I try to build vim with the --enable-hangulinput and --enable-xim
>>> confilct at the same time, but failed with error:
>>>
>>> -------------------------
>>> vim.h:1585:63: error: called object 'size_t' is not a function or
>>> function pointer
>>> #define STRNCMP(d, s, n) strncmp((char *)(d), (char *)(s), (size_t)(n))
>>> ^
>>> ex_docmd.c:8459:6: note: in expansion of macro 'STRNCMP'
>>> if (STRNCMP(arg, "FALLBACK ", 9) == 0)
>>> ^~~~~~~
>>> In file included from /usr/include/wchar.h:887:0,
>>> from spell.h:250,
>>> from vim.h:2110,
>>> from ex_docmd.c:14:
>>> /usr/include/x86_64-linux-gnu/bits/wchar2.h:507:20: note: declared here
>>> __fortify_function size_t
>>> ^~~~~~
>>> Makefile:3059: recipe for target 'objects/ex_docmd.o' failed
>>> make[1]: *** [objects/ex_docmd.o] Error 1
>>> make[1]: Leaving directory '/home/werner/software/editor/vim/vim.git/src'
>>> Makefile:26: recipe for target 'first' failed
>>> make: *** [first] Error 2
>>> -----------------------------
>>>
>>> Are these two options conflict?
>>
>> Regardless of compilation error, the hangulin feature is for
>> environments where XIM is not available.
>>
>> You can find next line with ':help hangul'.
>> ./configure --with-x --enable-multibyte --enable-hangulinput \
>> --disable-xim
>
> That's a bit of a disadvantage when someone tries to build a version
> that works with multiple languages. Can we make this a runtime choice
> instead of a compile time choice? No idea how much work that would be.
Here is a minimal patch (no documentation, no indenting to minimize).
If vim supports both xim and hangulinpt and user set 'imdisable',
hangulinput feature is selected.
I tested this patch by adding '--enable-xim --enable-hangulinput' to my
default configure option.
$ auto/configure --enable-perlinterp=no --disable-gpm
--enable-python3interp=dynamic --enable-tclinterp=no --enable-cscope
--with-features=huge --enable-terminal --enable-multibyte --enable-xim
--enable-hangulinput --prefix=/opt/local --with-x --enable-gui=gtk3
While testing this patch, I noticed one glitch.
Though I set 'imdisable' in the vimrc and I confirmed the setting with
':set imdisable?', when I typed S-Space for the first time, vim connects
to XIM. After that, go to english input mode and type S-Space again, vim
enters to hangulinput mode. My system environement may cause this glitch??
Thanks,
namsh
--
--
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/47ca13c8-ba84-1334-dea3-b55adceb1029%40gmail.com.
Tuesday, August 27, 2019
Re: Mapping erases search count message
On Wed, Aug 28, 2019 at 8:12 AM Gary Johnson <garyjohn@spocom.com> 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 <silent> n n" the count is indeed not
echoed, but with ":noremap n n" instead, it is. I suppose that the
<silent> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsAz5Tz3mPomDJfX3%3DpAsgQ8Y%3Dr3wEH1GRp6Ygvh0tjCA%40mail.gmail.com.
> 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 <silent> n n" the count is indeed not
echoed, but with ":noremap n n" instead, it is. I suppose that the
<silent> 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+unsubscribe@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
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.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828061843.GA27112%40phoenix.
> 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.
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+unsubscribe@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
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 <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?
> >
> > 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828061339.GA26834%40phoenix.
> 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 <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?
> >
> > 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828061339.GA26834%40phoenix.
Re: Failed to parse vim.desktop file msgs
On Di, 27 Aug 2019, M Kelly wrote:
> Hi,
>
> I get many of these msgs on my system in syslog:
>
> Aug 27 15:02:15 <hostname> gnome-session[XXXX]: (gnome-software:YYYY): As-WARNING **: failed to rescan: Failed to parse /usr/local/share/applications/vim.desktop file: cannot process file of type application/x-desktop
>
> Anyone know why ?
> I do not get this warning with gvim even though there is a very similar gvim.desktop file in the same dir.
> I am installing from master and the /usr/local/share/applications/vim.desktop file gets copied there from make install
> I am on ubuntu 16.04 with newer kernel. gnome-software verson is: 3.20.5
Check the desktop file if it contains invalid utf-8 or duplicate
entries. I believe Ubuntu 16.04 msgfmt is seriously brocken and we had
to work around it in the build script.
Best,
Christian
--
Alle Vögel sind schon da.
-- Deutsche Burschenschaften
(Marc-Uwe Kling: Falsch zugeordnete Zitate)
--
--
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/20190828061210.GB25942%40256bit.org.
> Hi,
>
> I get many of these msgs on my system in syslog:
>
> Aug 27 15:02:15 <hostname> gnome-session[XXXX]: (gnome-software:YYYY): As-WARNING **: failed to rescan: Failed to parse /usr/local/share/applications/vim.desktop file: cannot process file of type application/x-desktop
>
> Anyone know why ?
> I do not get this warning with gvim even though there is a very similar gvim.desktop file in the same dir.
> I am installing from master and the /usr/local/share/applications/vim.desktop file gets copied there from make install
> I am on ubuntu 16.04 with newer kernel. gnome-software verson is: 3.20.5
Check the desktop file if it contains invalid utf-8 or duplicate
entries. I believe Ubuntu 16.04 msgfmt is seriously brocken and we had
to work around it in the build script.
Best,
Christian
--
Alle Vögel sind schon da.
-- Deutsche Burschenschaften
(Marc-Uwe Kling: Falsch zugeordnete Zitate)
--
--
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/20190828061210.GB25942%40256bit.org.
Re: Mapping erases search count message
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?
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828060810.GA25942%40256bit.org.
> 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?
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+unsubscribe@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
On Wed, Aug 28, 2019 at 7:31 AM Gary Johnson <garyjohn@spocom.com> 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?
>
> 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+unsubscribe@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.
>
> 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?
>
> 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+unsubscribe@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.
Mapping erases search count message
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?
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828053221.GA10925%40phoenix.
'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?
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190828053221.GA10925%40phoenix.
Re: Failed to parse vim.desktop file msgs
On Wed, Aug 28, 2019 at 12:51 AM M Kelly <mckelly2833@gmail.com> wrote:
>
> Hi,
>
> I get many of these msgs on my system in syslog:
>
> Aug 27 15:02:15 <hostname> gnome-session[XXXX]: (gnome-software:YYYY): As-WARNING **: failed to rescan: Failed to parse /usr/local/share/applications/vim.desktop file: cannot process file of type application/x-desktop
>
> Anyone know why ?
> I do not get this warning with gvim even though there is a very similar gvim.desktop file in the same dir.
> I am installing from master and the /usr/local/share/applications/vim.desktop file gets copied there from make install
> I am on ubuntu 16.04 with newer kernel. gnome-software verson is: 3.20.5
>
> thanks for all vim,
> -m
Strange.
I didn't know about hese .desktop files but looking for them finds
them not only at the same place in the directory tree, but with the
same date as my home-compiled /usr/local/bin/vim binary (to which
/usr/local/bin/gvim is a soft link). Comparing them with vimdiff shows
that they are extremely similar, though not identical, to each other.
Most of the differences are what one would expect from .desktop files
meant, the one for gvim and the other for vim.
Normally I start Vim either as "gvim -S" with a handwritten session
file from a handwritten desktop icon, or by typing the executable name
(vim, view, vimdiff, etc.) with apropriate arguments at a bash shell
prompt, thus entirely bypassing those .desktop shortcuts (which are
not installed on my KDE desktop anyway). This never gives me problems.
I am on openSUSE 15.1 where I compile and install the latest Vim
(currently 8.1.1933) every time I see a new version on Christian's
Mercurial mirror (presently the 256bit.org one, in prevision of
Bitbucket's demise as a Mercurial hosting facility in a little less
than a year) of Bram's master repository on github; my other software
packages come from the openSUSE 15.1 distro's various software
repositories, including the "Update-Test" repository; for instance the
Linux kernel there is at version 4.12.14-lp151.28.3 where the part
after the dash is a kind of "SUSE build number".
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXt45Vw0JP3kyqCkp%3DqaavS56EkzMFFap_C%3DFd-zYB%3DC%3DQ%40mail.gmail.com.
>
> Hi,
>
> I get many of these msgs on my system in syslog:
>
> Aug 27 15:02:15 <hostname> gnome-session[XXXX]: (gnome-software:YYYY): As-WARNING **: failed to rescan: Failed to parse /usr/local/share/applications/vim.desktop file: cannot process file of type application/x-desktop
>
> Anyone know why ?
> I do not get this warning with gvim even though there is a very similar gvim.desktop file in the same dir.
> I am installing from master and the /usr/local/share/applications/vim.desktop file gets copied there from make install
> I am on ubuntu 16.04 with newer kernel. gnome-software verson is: 3.20.5
>
> thanks for all vim,
> -m
Strange.
I didn't know about hese .desktop files but looking for them finds
them not only at the same place in the directory tree, but with the
same date as my home-compiled /usr/local/bin/vim binary (to which
/usr/local/bin/gvim is a soft link). Comparing them with vimdiff shows
that they are extremely similar, though not identical, to each other.
Most of the differences are what one would expect from .desktop files
meant, the one for gvim and the other for vim.
Normally I start Vim either as "gvim -S" with a handwritten session
file from a handwritten desktop icon, or by typing the executable name
(vim, view, vimdiff, etc.) with apropriate arguments at a bash shell
prompt, thus entirely bypassing those .desktop shortcuts (which are
not installed on my KDE desktop anyway). This never gives me problems.
I am on openSUSE 15.1 where I compile and install the latest Vim
(currently 8.1.1933) every time I see a new version on Christian's
Mercurial mirror (presently the 256bit.org one, in prevision of
Bitbucket's demise as a Mercurial hosting facility in a little less
than a year) of Bram's master repository on github; my other software
packages come from the openSUSE 15.1 distro's various software
repositories, including the "Update-Test" repository; for instance the
Linux kernel there is at version 4.12.14-lp151.28.3 where the part
after the dash is a kind of "SUSE build number".
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXt45Vw0JP3kyqCkp%3DqaavS56EkzMFFap_C%3DFd-zYB%3DC%3DQ%40mail.gmail.com.
Failed to parse vim.desktop file msgs
Hi,
-- I get many of these msgs on my system in syslog:
Aug 27 15:02:15 <hostname> gnome-session[XXXX]: (gnome-software:YYYY): As-WARNING **: failed to rescan: Failed to parse /usr/local/share/applications/vim.desktop file: cannot process file of type application/x-desktop
Anyone know why ?
I do not get this warning with gvim even though there is a very similar gvim.desktop file in the same dir.
I am installing from master and the /usr/local/share/applications/vim.desktop file gets copied there from make install
I am on ubuntu 16.04 with newer kernel. gnome-software verson is: 3.20.5
thanks for all vim,
-m
--
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/75ad70e2-6de0-4806-bbcc-3e8b92c4ff63%40googlegroups.com.
Re: 回复：auto indent
Hi
on 2019/8/27 17:11, Tony Mechelynck wrote:
> You shouldn't set it permanently, because it has a lot of
> side-effects: it sets a lot of options to off or to 0, and in
> addition, in 'paste' mode, mappings don't work.
>
> What you can do is ":set paste" just before pasting and ":set nopaste"
> afterwards. Or use a 'pastetoggle' as explained in the help.
that's right. thanks.
--
--
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/c5e61457-6693-90dc-02fb-7eff35991136%40ChinaBuckets.com.
on 2019/8/27 17:11, Tony Mechelynck wrote:
> You shouldn't set it permanently, because it has a lot of
> side-effects: it sets a lot of options to off or to 0, and in
> addition, in 'paste' mode, mappings don't work.
>
> What you can do is ":set paste" just before pasting and ":set nopaste"
> afterwards. Or use a 'pastetoggle' as explained in the help.
that's right. thanks.
--
--
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/c5e61457-6693-90dc-02fb-7eff35991136%40ChinaBuckets.com.