Peter Hodge wrote:
Hello,
Backspacing or typing while the Vim 7 Insert completion popup window is running
is very difficult when the completion list is long or comes from many sources.
Because the popup menu refreshes itself on each backspace, each keystroke can
take up to half a second to appear, and it was actually easier to hit escape
and re-enter insert mode to stop the popup menu guzzling CPU cycles on each
keystroke.
Miraculously, it was very easy for me to create an extra value for
'completeopt' which stops the popup menu as soon as something is backspaced or
added, and allows me to have the popup menu turned on, but without it getting
in my way as I type.
Do you think it would be worthwhile adding this patch into Vim?
regards,
Peter
Patch for the online help:
==========================
*** /usr/share/vim/vim70/doc/options.txt Wed Sep 13 13:44:48 2006
--- doc/options.txt Wed Sep 13 14:59:04 2006
[...]
Patch for Vim 7 source (after patch 101)
========================================
*** vim70.orig/src/edit.c Wed Sep 13 14:35:14 2006
--- vim70/src/edit.c Wed Sep 13 14:26:45 2006
[...]
It might or might not be worthwhile (that's for Bram to decide), but:
1. The second title above is misleading. Bram uses "(after patch nnn)"
when a patch _depends_ on another, i.e., requires patch nnn to have been
applied previously, usually because the later patch fixes a bug
introduced by the earlier one. For instance, official patch 7.0.057 is
labeled "(extra; after 7.0.45)"; both are about compilation trouble with
various W32 compilers.
In this case, patch 101 is
2732 7.0.101 "zw" mostly doesn't work; "zg" may create wrong directory
which is _only_ about spelling. I don't see how this one, which doesn't
even touch spell.c (the only file other than version.c changed by patch
101) can be "dependent" upon patch 101.
2. Official patches are supposed to be applied with "patch -p0 <
patchfilename", the top directory of the build hierarchy (i.e.
vim<version>, not $VIMRUNTIME but the parent of runtime/, src/,
pixmaps/, etc. -- on my system it would be /root/build/vim/vim70/, not
/usr/local/share/vim/vim70/) being current. _Any_ patch should at least
be constructed so that it can be applied from a single "current
directory". Here one part of the patch [the C code part] is supposed to
be applied from the parent of the top vim70 build directory (one level
higher than usual) and another part [the help text part] from its
"runtime/" subdirectory (one level lower than usual). Trying to do
"patch -p0 < Fixed:\ prevent\ slowness\ from\ Insert\ mode\
completion.eml" is bound to make the patcher cough. (And BTW, patching
$VIMRUNTIME/doc/options.txt rather than [for instance]
/root/build/vim/vim70/runtime/doc/options.txt would cause the changes to
be lost when "make install" copies the latter onto the former a few
minutes later.)
Sorry if I sound griping, but it's easier for everyone if patches follow
uniform conventions. (Here I'm intentionally calling your email "one"
patch: look at Bram's patches in ftp://ftp.vim.org/pub/vim/patches/7.0/
, they are the raw text of his emails, with sig and all. Each of them
patches at least two files and sometimes half a dozen or so.)
Best regards,
Tony.
