Hello,
When I leave insert or visual mode with <esc> the visual
selection stays. I can move around normally (since I'm now in normal
mode), but the screen doesn't update until I move. Adding the
following mappings fixes the issue:
> Hello,
> When I leave insert or visual mode with <esc> the visual
> selection stays. I can move around normally (since I'm now in normal
> mode), but the screen doesn't update until I move. Adding the
> following mappings fixes the issue:
On Fri, Oct 5, 2012 at 1:11 AM, Christian Brabandt <cbli...@256bit.org> wrote:
> Hi Josh!
> On Do, 04 Okt 2012, Josh . wrote:
>> Hello,
>> When I leave insert or visual mode with <esc> the visual
>> selection stays. I can move around normally (since I'm now in normal
>> mode), but the screen doesn't update until I move. Adding the
>> following mappings fixes the issue:
>> My `lazyredraw` option is off. For clarity: I don't think the above
>> mappings should be needed, so I think this is a redraw bug. Thoughts?
> is this the gui or terminal version of vim? If terminal, which one are
> you using?
> regards,
> Christian
> --
> Der sittliche Mensch liebt seine Seele, der gewöhnliche sein Eigentum.
> -- Konfuzius (551-479 v. Chr.)
> --
> You received this message from the "vim_dev" 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
On Fri, Oct 5, 2012 at 7:56 AM, Josh . <randomendu...@gmail.com> wrote:
> Terminal vim (huge version iirc) on Arch Linux x64 in urxvt. I can
> grab the full output of `:version` tonight if you like.
> On Fri, Oct 5, 2012 at 1:11 AM, Christian Brabandt <cbli...@256bit.org> wrote:
>> Hi Josh!
>> On Do, 04 Okt 2012, Josh . wrote:
>>> Hello,
>>> When I leave insert or visual mode with <esc> the visual
>>> selection stays. I can move around normally (since I'm now in normal
>>> mode), but the screen doesn't update until I move. Adding the
>>> following mappings fixes the issue:
>>> My `lazyredraw` option is off. For clarity: I don't think the above
>>> mappings should be needed, so I think this is a redraw bug. Thoughts?
>> is this the gui or terminal version of vim? If terminal, which one are
>> you using?
>> regards,
>> Christian
>> --
>> Der sittliche Mensch liebt seine Seele, der gewöhnliche sein Eigentum.
>> -- Konfuzius (551-479 v. Chr.)
>> --
>> You received this message from the "vim_dev" 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 could have pasted that information right into the mail. So I can quote the information and not every subscriber of this list is able to fetch the information.
Since your vim version is pretty recent, I would guess, that you have an issue with urxvt. I am running latest Vim using urvt 9.14 and have never seen something like this. Would you mind, testing with an older version of urxvt? Having said this, this sounds a lot like this bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631793 unfortunately, no response there. So you might want to report it upstream as well.
Oddly enough I don't have this issue on my laptop (same versions of
everything iirc), but _do_ in xterm(283) _and_ in urxvt 9.15 on my
desktop. Just to be clear, when I have things selected in visual
mode, then hit esc, it appears I'm still in visual mode w/the text
being selected. When I move the cursor, then it shows that I'm in
normal mode and the text isn't being selected anymore. Also, I still
have this issue after running: `mv .vimrc temp.vimrc && mv .vim/
temp.vim/`. Could it be an X thing? Hardware thing? Xmonad thing?
> You could have pasted that information right into the mail. So I can
> quote the information and not every subscriber of this list is able to
> fetch the information.
> Since your vim version is pretty recent, I would guess, that you have an
> issue with urxvt. I am running latest Vim using urvt 9.14 and have never
> seen something like this. Would you mind, testing with an older version
> of urxvt? Having said this, this sounds a lot like this bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631793 > unfortunately, no response there. So you might want to report it
> upstream as well.
> regards,
> Christian
> --
> --
> You received this message from the "vim_dev" 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
Sorry for bumping an old thread, but with the help of some clever folk, I've found out how to reproduce the issue:
1) Use terminal vim, NOT macvim
2) Run vim with `vim --noplugin -u NONE`
3) Everything works as desired, yay!
3) Run `:set notimeout nottimeout`
4) Select some text and hit <esc>
5) Now you need to hit another key for a redraw
I've found that setting `timeoutlen=1` is a good workaround, but this is still a bug, right? Thanks for taking a look again!
Josh
On Oct 11, 2012, at 4:48 PM, Josh . <randomendu...@gmail.com> wrote:
> Oddly enough I don't have this issue on my laptop (same versions of
> everything iirc), but _do_ in xterm(283) _and_ in urxvt 9.15 on my
> desktop. Just to be clear, when I have things selected in visual
> mode, then hit esc, it appears I'm still in visual mode w/the text
> being selected. When I move the cursor, then it shows that I'm in
> normal mode and the text isn't being selected anymore. Also, I still
> have this issue after running: `mv .vimrc temp.vimrc && mv .vim/
> temp.vim/`. Could it be an X thing? Hardware thing? Xmonad thing?
> On Tue, Oct 9, 2012 at 12:11 PM, Christian Brabandt <cbli...@256bit.org> wrote:
>> Hi Josh!
>> You could have pasted that information right into the mail. So I can
>> quote the information and not every subscriber of this list is able to
>> fetch the information.
>> Since your vim version is pretty recent, I would guess, that you have an
>> issue with urxvt. I am running latest Vim using urvt 9.14 and have never
>> seen something like this. Would you mind, testing with an older version
>> of urxvt? Having said this, this sounds a lot like this bug
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631793 >> unfortunately, no response there. So you might want to report it
>> upstream as well.
>> regards,
>> Christian
>> --
>> --
>> You received this message from the "vim_dev" 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
On Thu, January 17, 2013 21:09, Josh wrote:
> Sorry for bumping an old thread, but with the help of some clever folk,
> I've found out how to reproduce the issue:
> 1) Use terminal vim, NOT macvim
> 2) Run vim with `vim --noplugin -u NONE`
> 3) Everything works as desired, yay!
> 3) Run `:set notimeout nottimeout`
> 4) Select some text and hit <esc>
> 5) Now you need to hit another key for a redraw
> I've found that setting `timeoutlen=1` is a good workaround, but this is
> still a bug, right? Thanks for taking a look again!
Well don't do it then ;)
After setting timeout to off and hitting ESC Vim is still waiting for
you to press another key (and hasn't left visual mode yet, so there
is no reason to trigger a redraw yet).
Setting timout to off, means Vim needs to wait after hitting <ESC>
to see, which other key is pressed to know whether you really have hit
the <esc> key or just another key like the Cursor key (which
internally is just a mapped <Esc> sequence).
> On Thu, January 17, 2013 21:09, Josh wrote:
>> Sorry for bumping an old thread, but with the help of some clever folk,
>> I've found out how to reproduce the issue:
>> 1) Use terminal vim, NOT macvim
>> 2) Run vim with `vim --noplugin -u NONE`
>> 3) Everything works as desired, yay!
>> 3) Run `:set notimeout nottimeout`
>> 4) Select some text and hit <esc>
>> 5) Now you need to hit another key for a redraw
>> I've found that setting `timeoutlen=1` is a good workaround, but this is
>> still a bug, right? Thanks for taking a look again!
> Well don't do it then ;)
> After setting timeout to off and hitting ESC Vim is still waiting for
> you to press another key (and hasn't left visual mode yet, so there
> is no reason to trigger a redraw yet).
> Setting timout to off, means Vim needs to wait after hitting <ESC>
> to see, which other key is pressed to know whether you really have hit
> the <esc> key or just another key like the Cursor key (which
> internally is just a mapped <Esc> sequence).
> regards,
> Christian
> -- > You received this message from the "vim_dev" 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
Ahh, thanks for the explanation. I think I get it now. I just need to figure out what I'm losing now if I get rid of the timeout with `ttimeoutlen=0` or something :). Docs'll help me w/that; Thanks again!
