[vim/vim] Keyboard Input Delay only when using VIM (Issue #11692)

362 views
Skip to first unread message

Roger

unread,
Dec 11, 2022, 4:09:55 PM12/11/22
to vim/vim, Subscribed

Steps to reproduce

  1. Open a 1-2 Megabyte text file. (eg. GPL license)
  2. Activate insert mode and press one key/charter down, activating key repeat.
  3. After several lines of key repeat, VIM display will delay displaying characters received from the keyboard.

The problem becomes extremely more obvious with faster keyboard repeat rates:
$ xset r rate 500 50

I do not see the problem by simply typing within any terminal, whether Linux command line console or X/Xorg.

I do see this problem whenever opening VIM text file, whether within a simple Linux command line console or within X/Xorg.

Expected behaviour

As I see within using other operating systems on this same computer, or using different computers/hardware, VIM should likely not be stuttering or exhibiting a delay when typing characters.

Version of Vim

vim-9.0.0948_1

Environment

operating system: void linux

terminal: xterm

$TERM: screen-256color-bce

shell: bash

Logs and stack traces

No response


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692@github.com>

Roger

unread,
Dec 11, 2022, 4:13:06 PM12/11/22
to vim/vim, Subscribed

After noticing the above environmental variables as a possible factor, maybe my bashrc/bash_profile, or other environmental variable is causing the delayed input/output problem.

I just logged in as root, via simple linux command line console, with and without bashrc/bash_profile, and could not reproduce this problem.

Any help debugging this would be appreciated.

I'll next try removing/modifying possible files possibly causing this problem. (eg. bashrc/bash_profile)

I'm aware of "vim -V9" as a possible debugging method, although disturbing all keyboard input; any others methods?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1345657846@github.com>

Roger

unread,
Dec 11, 2022, 4:34:58 PM12/11/22
to vim/vim, Subscribed

I believe I've solved this bug/problem.

The likely cause of the delay/stutter problem is the likely slower speed of the hard drive. Would appear something else is being written to the slower hard drive from within VIM while VIM is also receiving keyboard input and displaying keyboard output.

I do not see, or for the time being, the delay problem when using files residing on a solid state drive. Only seeing the delay when opening/editing files residing on a hard drive.

Again, options/feedback? This is strange as I do not believe I've ever noticed this VIM delay/stuttering input/output problem with any older computers using hard drives, until now with this super fast computer.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1345662266@github.com>

Roger

unread,
Dec 11, 2022, 4:49:17 PM12/11/22
to vim/vim, Subscribed

Here's a solution or workaround.

I have my operating system (eg. /) installed to solid state drive.
My /home folder is installed to hard drive.

The problem/bug seems to be caused by VIM writing to a swap file (with VIM's default swap folder order of choice being $HOME/tmp, /var/tmp, /tmp), and in my case initially to the slower $HOME/tmp folder on the hard drive.

So by adding the following, I reassigned to write swap files to the faster solid state drive:

file $HOME/.vimrc
set directory=/tmp/

Still not sure as to why the recently purchased hard drive(s) is slowing VIM swap file writes, inhibiting input/output delays.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1345665720@github.com>

Bram Moolenaar

unread,
Dec 11, 2022, 4:52:55 PM12/11/22
to vim/vim, Subscribed


> After noticing the above environmental variables as a possible factor,
> maybe my bashrc/bash_profile, or other environmental variable is
> causing the delayed input/output problem.
>
> I just logged in as root, via simple linux command line console, with
> and without bashrc/bash_profile, and could not reproduce this problem.
>
> Any help debugging this would be appreciated.
>
> I'll next try removing/modifying possible files possibly causing this
> problem. (eg. bashrc/bash_profile)
>
> I'm aware of "vim -V9" as a possible debugging method, although
> disturbing all keyboard input; any others methods?

Start with "vim --clean". That will not use your startup files and only
set a few options to a useful value (such as 'nocompatible').

If you still see the problem, try ":syntax off".
If that helps then use "verbose set ft" to see what the value of
'filetype' is and where it was set.

--
Facepalm statement #5: "Petrol getting more expensive? Not for me, I'm always
tanking for 20 dollars"

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1345666462@github.com>

Roger

unread,
Dec 11, 2022, 4:55:43 PM12/11/22
to vim/vim, Subscribed

I found the likely source of the problem five minutes ago, and posted just prior to your post. ;-)


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1345666997@github.com>

Christian Brabandt

unread,
Dec 12, 2022, 4:18:01 PM12/12/22
to vim/vim, Subscribed

yes, possibly you can tune the swapsync option to disable fsync'ing the swapfile (this is a bit risky however). I believe it may also depend on the 'updatecount' option.

I don't think this is a bug here, so closing.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1347342128@github.com>

Christian Brabandt

unread,
Dec 12, 2022, 4:18:01 PM12/12/22
to vim/vim, Subscribed

Closed #11692 as completed.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/11692/issue_event/8018660221@github.com>

Roger

unread,
Dec 12, 2022, 10:00:02 PM12/12/22
to vim/vim, Subscribed

Ditto. Looked over the fine tuning swap options via help:swap, figured adjusting might cause undesirable behavior, aside from maybe 2x's the time/character swap write operations, as I think most can easily type a full paragraph, at whim, while looking at the display/monitor, disregarding proper typing ethics of not looking at the display/monitor.

For the time being as a workaround until I can think of something else or fine tune the previously mentioned, just using ~/.vimrc: set directory=/tmp/ or relocating swap writes to the solid state drive... again disregarding possibly side effects.

Extremely disturbing while typing and seeing abrupt pauses, if one is watching what their typing.

There's also the possibility the disk/bus is getting loaded with iptable writes alongside VIM swap writes, as minimal as they seem to be. Again however, I've never seen such problems on other computers. Really weird!


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/11692/1347676286@github.com>

Reply all
Reply to author
Forward
0 new messages