this issue has annoyd me since a long time,
I wonder if nobody else has had a problem with it.
When I have opened a file and want to do things like
: set ai
and then type my text,
if I tyoe fast and don't wait until the ":" appears in the status line,
I will be in insert mode and type my text then,
without the command being executed.
Then one of the possible insert commands following the
":" (s, a, i) will be accepted by vim.
So, somehow it looks like the input is not processed
character by character, but somehow by likelyhood.
As if the input buffer is discarded and possibly
only the "a" for append or one of the other edit-commands
is used then.
This problem is annoying especially on slow machines or when
I use syntax on, because this somehow seems to eat up performance
and makes the problem popping up.
So I have to wait until the ":" can be seen,
which means it stops me in my flow.
I would await that what I type is buffered, and processed
one char after the next.
Is this a known issue?
Is it already planned to fix this?
If not: can this please be added to the bug-list?
> this issue has annoyd me since a long time,
> I wonder if nobody else has had a problem with it.
> When I have opened a file and want to do things like
> : set ai
> and then type my text,
> if I tyoe fast and don't wait until the ":" appears in the status line,
> I will be in insert mode and type my text then,
> without the command being executed.
> Then one of the possible insert commands following the
> ":" (s, a, i) will be accepted by vim.
> So, somehow it looks like the input is not processed
> character by character, but somehow by likelyhood.
> As if the input buffer is discarded and possibly
> only the "a" for append or one of the other edit-commands
> is used then.
> This problem is annoying especially on slow machines or when
> I use syntax on, because this somehow seems to eat up performance
> and makes the problem popping up.
> So I have to wait until the ":" can be seen,
> which means it stops me in my flow.
> I would await that what I type is buffered, and processed
> one char after the next.
> Is this a known issue?
> Is it already planned to fix this?
> If not: can this please be added to the bug-list?
> Thanks in Advance,
> Oliver
It is not necessarily a Vim problem. It could be a human problem (typing so fast you hit beside the colon key), a hardware problem (if the keyboard fails to see some of the keys you hit) or a firmware or system software problem (if the keyboard driver in the BIOS ROM or in your OS kernel fails to see some keyhits). This has happened to me with many programs (not only Vim) especially under conditions of heavy system load. For instance it has happened to me to type a full line "blind" into SeaMonkey Mail before it suddenly appeared. Sometimes a letter was missing haphazardly here and there.
One possible reason (I imagine) for not seeing a key could be a load so heavy (maybe due to heavy swapping in and out of virtual memory) that the OS doesn't get the time to handle a keyboard interrupt before the next keyboard interrupt arrives, wiping the unhandled one.
Best regards,
Tony.
-- "I'd love to go out with you, but the man on television told me to say
tuned."
> this issue has annoyd me since a long time,
> I wonder if nobody else has had a problem with it.
> When I have opened a file and want to do things like
> : set ai
> and then type my text,
> if I tyoe fast and don't wait until the ":" appears in the status line,
> I will be in insert mode and type my text then,
> without the command being executed.
> Then one of the possible insert commands following the
> ":" (s, a, i) will be accepted by vim.
> So, somehow it looks like the input is not processed
> character by character, but somehow by likelyhood.
> As if the input buffer is discarded and possibly
> only the "a" for append or one of the other edit-commands
> is used then.
> This problem is annoying especially on slow machines or when
> I use syntax on, because this somehow seems to eat up performance
> and makes the problem popping up.
> So I have to wait until the ":" can be seen,
> which means it stops me in my flow.
> I would await that what I type is buffered, and processed
> one char after the next.
> Is this a known issue?
> Is it already planned to fix this?
> If not: can this please be added to the bug-list?
I'm currently seeing some kind of race involving the termresponse
and some other event(s) that occur during startup. It think it has
to do with the slowness of the connection between the X server on my
desktop and the machine I work on in the back room. I don't think
many developers have this sort of setup so I figure it's up to me to
diagnose the problem. I just haven't had the time to do so.
If you are seeing another manifestation of this same problem, you
might try putting
> > this issue has annoyd me since a long time,
> > I wonder if nobody else has had a problem with it.
> > When I have opened a file and want to do things like
> > : set ai
> > and then type my text,
> > if I tyoe fast and don't wait until the ":" appears in the status line,
> > I will be in insert mode and type my text then,
> > without the command being executed.
> > Then one of the possible insert commands following the
> > ":" (s, a, i) will be accepted by vim.
> > So, somehow it looks like the input is not processed
> > character by character, but somehow by likelyhood.
> > As if the input buffer is discarded and possibly
> > only the "a" for append or one of the other edit-commands
> > is used then.
> > This problem is annoying especially on slow machines or when
> > I use syntax on, because this somehow seems to eat up performance
> > and makes the problem popping up.
> > So I have to wait until the ":" can be seen,
> > which means it stops me in my flow.
> > I would await that what I type is buffered, and processed
> > one char after the next.
> > Is this a known issue?
> > Is it already planned to fix this?
> > If not: can this please be added to the bug-list?
> > Thanks in Advance,
> > Oliver
> It is not necessarily a Vim problem. It could be a human problem (typing > so fast you hit beside the colon key), a hardware problem (if the > keyboard fails to see some of the keys you hit) or a firmware or system > software problem (if the keyboard driver in the BIOS ROM or in your OS > kernel fails to see some keyhits). This has happened to me with many > programs (not only Vim) especially under conditions of heavy system > load. For instance it has happened to me to type a full line "blind" > into SeaMonkey Mail before it suddenly appeared. Sometimes a letter was > missing haphazardly here and there.
If I wait until the ":" is in status bar, it's there.
It is not forgotten.
If I type faster, then it seems to be forgotten.
If it would be forgotten because of slow system,
it would also be, if I just type this ":" and nothing more.
Normally there is a buffer in the system.
Things don't get lost.
They just be available later.
So I think there is a true vim problem.
Of course other programs may have that problem too...
But... yes, with heavy load the problem is there even harder.
I remember ancient times, when this was not a problem.
Then later I found it occuring only when syntax-highlighting is on.
Now I see it even with syntax off.
Thats what I remember. As far as I rmemeber, in the eraly days I did not have
such problems.
> On 2012-10-06, Oliver wrote:
[...]
> > So I have to wait until the ":" can be seen,
> > which means it stops me in my flow.
> > I would await that what I type is buffered, and processed
> > one char after the next.
> > Is this a known issue?
> > Is it already planned to fix this?
> > If not: can this please be added to the bug-list?
> I'm currently seeing some kind of race involving the termresponse
> and some other event(s) that occur during startup.
Thank you for exploring the problem.
I hope you can locate and fix it.
It would be of great help.
[...]
> If you are seeing another manifestation of this same problem, you
> might try putting
> If I wait until the ":" is in status bar, it's there.
> It is not forgotten.
Following one of suggested explanations: typing colon and nothing: keyboard interrupt is not overriden.
> If I type faster, then it seems to be forgotten.
Typing faster: keyboard interrupt is overriden.
> If it would be forgotten because of slow system,
> it would also be, if I just type this ":" and nothing more.
False.
> Normally there is a buffer in the system.
> Things don't get lost.
> They just be available later.
> So I think there is a true vim problem.
Type that fast in terminal without vim (if using terminal vim) or in other GTK app (if using gvim). If you don’t observe the same problem you may suggest it is a true vim problem. I reread your messages and did not see you saying you checked typing *exactly the same characters with roughly the same speed* in other application, only
> Of course other programs may have that problem too...
. Without testing this you have no reasons to blame vim and write here.
If you are using terminal vim, there is another way to check whether it is a vim problem: use screen which may stuff characters to vim at the fastest possible speed (really making them available in stdin at once):
gvim --echo-wid | read DUMMY VID
xdotool type --delay 1ms :test-characters
(you may use xdotool with normal vim as well if you want, it is universal. But you then can’t distinguish between situation “terminal emulator looses characters” and “vim looses characters”, screen provides its own terminal emulator that does not receive keys from X).
I have never seen vim loosing anything, neither did my system (most of the time heavy load here == heavy IO load, rarely 5-or-more-threaded (4 cores, 4+1 as suggested by handbook, sometimes simultaneous installs) compilation of something (rarely as it is less threaded unless I want the software right now)).
> > If I wait until the ":" is in status bar, it's there.
> > It is not forgotten.
> Following one of suggested explanations: typing colon and nothing: keyboard
interrupt is not overriden.
> > If I type faster, then it seems to be forgotten.
> Typing faster: keyboard interrupt is overriden.
> > If it would be forgotten because of slow system,
> > it would also be, if I just type this ":" and nothing more.
> False.
> > Normally there is a buffer in the system.
> > Things don't get lost.
> > They just be available later.
> > So I think there is a true vim problem.
> Type that fast in terminal without vim (if using terminal vim) or in other GTK
app (if using gvim). If you
> don’t observe the same problem you may suggest it is a true vim problem. I
reread your messages and did not
> see you saying you checked typing *exactly the same characters with roughly
the same speed* in other
> application, only
> > Of course other programs may have that problem too...
> . Without testing this you have no reasons to blame vim and write here.
I never experienced something like that outside vim.
To follow the "testing procedure" I just tested it again
and the result is: this does not happen in my shell it does only happen when
using vim.
The problem does not occur on any other
situations with vim.
Only when switching temporarily to ex-mode with ":".
In any other situation no characters are missing,
even under heavy load.Only when the ":" is involved.
Looks like ":" triggers a sleep-command, eats up
some chars and then does go to insert mode.
When going diretcly to insert mode, nothing is missing.
I doubt that thois specific behaviour is caused by
some other reasons than vim.
понедельник, 8 октября 2012 г., 22:00:44 UTC+4 пользователь oliver написал:
> The problem does not occur on any other
> situations with vim.
> Only when switching temporarily to ex-mode with ":".
> In any other situation no characters are missing,
> even under heavy load.Only when the ":" is involved.
> Looks like ":" triggers a sleep-command, eats up
> some chars and then does go to insert mode.
> When going diretcly to insert mode, nothing is missing.
> I doubt that thois specific behaviour is caused by
> some other reasons than vim.
What about screen/xdotool tests? And what you see when you run
:verbose map :<CR>
:cmap<CR> (shows all command-mode mappings, seek for characters in test-characters)
:debug normal :test-characters<CR>
s<CR>
<CR>
<CR>
...
? (Maybe it is problem with some plugin, it should show up here.)
Does it happen when you type the same thing inside vim launched without configuration:
vim -u NONE
(it may be not plugin problem, but a problem with a set of specific options.)
> this issue has annoyd me since a long time,
> I wonder if nobody else has had a problem with it.
> When I have opened a file and want to do things like
> : set ai
> and then type my text,
> if I tyoe fast and don't wait until the ":" appears in the status line,
> I will be in insert mode and type my text then,
> without the command being executed.
you don't have defined a normal mode mapping for the colon, do you?
Regards,
J rgen
-- Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
