calling system() in InsertEnter/InsertLeave may print garbage in terminal
38 views
Skip to first unread message
Alexey Radkov
Jun 11, 2012, 5:59:14 AM6/11/12
to vim_dev
Hi.
It is not steadily reproducible though. I use gnome-teminal in Gnome3, with TERM set to xterm-256color, vim from Fedora 17 (or for testing latest vim built from mercurial repo, - no matter). I use call system() in autocmd InsertEnter and InsertLeave. To make it simple i will show the issue on a very basic test example, putting in .vimrc lines
fun! <SID>do_smth()
let aaa = system('echo AAA')
endfun
autocmd InsertEnter * call <SID>do_smth()
The issue trigger ONLY upon the very start of the vim, when i do it using 'vim - c start' - in this case i get result like in the first image attached, with this crazy line '[[>1;3201;01', this line is only garbage on the screen and i can start printing just upon this, or clear it using Ctrl-L in Normal mode. The issue is not really steadily reproducible - i seldom get it in konsole and xterm (but anyway it sometimes happen there as well). Making TERM=gnome-256color seems to make the issue go but it has other unnrelated nasty effects when sometimes all terminal content disappears and it get just empty.
There is another side of coin: sometimes (but very seldom) garbage may occur when i leave Insert mode (of course when i set autocmd InsertLeave): it happens when i press <Esc> in Insert mode and momentarily press some arrow key (Up, Down etc.)
Why do i bother about it? Because i use plugins c.vim and perl.vim that turn terminal into Insert mode for new files upon putting file headers. And i almost all the time get same annoying garbage printed: see 2nd image that i made by doing 'vim tmp.pl'.
The issue seems not to be related to influence by other installed plugins: it can happen when i do not use plugins (probably rarer, and in this case it may say that loading time may influence it).
I tried to debug it, but it is not simple because issue may arise from some gnome-terminal/vte bug/feature. Also i tried to change ttimeoutlen value: no luck. But i found that if i disable turning terminal im TMODE_COOKED when system() is called the issue goes away (i removed flag SHELL_COOKED in f_system() in eval.c). This is not a solution of course, because it disables Ctrl-C for background command interruption.
Probably someone have good advice for this, some workaround?
Cheers, Alexey.
It is not steadily reproducible though. I use gnome-teminal in Gnome3, with TERM set to xterm-256color, vim from Fedora 17 (or for testing latest vim built from mercurial repo, - no matter). I use call system() in autocmd InsertEnter and InsertLeave. To make it simple i will show the issue on a very basic test example, putting in .vimrc lines
fun! <SID>do_smth()
let aaa = system('echo AAA')
endfun
autocmd InsertEnter * call <SID>do_smth()
The issue trigger ONLY upon the very start of the vim, when i do it using 'vim - c start' - in this case i get result like in the first image attached, with this crazy line '[[>1;3201;01', this line is only garbage on the screen and i can start printing just upon this, or clear it using Ctrl-L in Normal mode. The issue is not really steadily reproducible - i seldom get it in konsole and xterm (but anyway it sometimes happen there as well). Making TERM=gnome-256color seems to make the issue go but it has other unnrelated nasty effects when sometimes all terminal content disappears and it get just empty.
There is another side of coin: sometimes (but very seldom) garbage may occur when i leave Insert mode (of course when i set autocmd InsertLeave): it happens when i press <Esc> in Insert mode and momentarily press some arrow key (Up, Down etc.)
Why do i bother about it? Because i use plugins c.vim and perl.vim that turn terminal into Insert mode for new files upon putting file headers. And i almost all the time get same annoying garbage printed: see 2nd image that i made by doing 'vim tmp.pl'.
The issue seems not to be related to influence by other installed plugins: it can happen when i do not use plugins (probably rarer, and in this case it may say that loading time may influence it).
I tried to debug it, but it is not simple because issue may arise from some gnome-terminal/vte bug/feature. Also i tried to change ttimeoutlen value: no luck. But i found that if i disable turning terminal im TMODE_COOKED when system() is called the issue goes away (i removed flag SHELL_COOKED in f_system() in eval.c). This is not a solution of course, because it disables Ctrl-C for background command interruption.
Probably someone have good advice for this, some workaround?
Cheers, Alexey.
Chris Jones
Jun 11, 2012, 11:49:07 AM6/11/12
to vim_dev
On Mon, Jun 11, 2012 at 05:59:14AM EDT, Alexey Radkov wrote:
> It is not steadily reproducible though. I use gnome-teminal in Gnome3,
> with TERM set to xterm-256color, vim from Fedora 17 (or for testing
> latest vim built from mercurial repo, - no matter). I use call
> system() in autocmd InsertEnter and InsertLeave. To make it simple
> i will show the issue on a very basic test example, putting in .vimrc
> lines
[..]
> It is not steadily reproducible though. I use gnome-teminal in Gnome3,
> with TERM set to xterm-256color, vim from Fedora 17 (or for testing
> latest vim built from mercurial repo, - no matter). I use call
> system() in autocmd InsertEnter and InsertLeave. To make it simple
> i will show the issue on a very basic test example, putting in .vimrc
> lines
> Probably someone have good advice for this, some workaround?
emulatins & different terminfo entries, I guess I would first try to
swap the keyboard just in case..
Then look in ~/.vimrc and other config files & plugins for custom
termcap definitions..
Won't hurt posting the output of ‘:set termcap’ to the list.
Otherwise, I don't use gnome-terminal (or any other vte-related stuff),
but I would definitely not have TERM point to an xterm terminfo entries:
infocmp shows significant differences. If the gnome-* entries cause
other problems they probably need to be addressed.
Maybe this would be better addressed on the vim_use list at this point?
CJ
--
WHAT YOU SAY??
Reply all
Reply to author
Forward
0 new messages