cga2000 wrote:
On Fri, Apr 20, 2007 at 11:06:24PM EDT, A.J.Mechelynck wrote:
cga2000 wrote:
I recently installed vim 7.x and I'm very impressed with all the new
features, especially the new tab stuff ..
On the other hand, I'm sorry to say that there is _ONE_ feature that's
literally driving me _NUTS_.
If I hit the CTRL-P combo by accident .. "p" is very close to "[" ..
and I use CTRL-[ a lot .. well, some "popup menu" materializes out of
the blue .. presenting me with a list of "completion" choices ..
Thanks, but I am not senile or otherwise mentally challenged .. I know
what I want to type .. and most of the time vim does not .. and since I
can type reasonably well .. I do _NOT_ need this completion "feature".
Is there any way I can turn of this completion popup .. ?
Since unwanted popups is one of the absolute evils of the web .. I'm
unsure why this should have become a default feature of the current
version vim and I sincerely hope it will cease to be the default with
the next release.
Maybe this might make some sense for GUI users .. but could it be left
our of the terminal version?
Thanks,
cga
:imap <C-P> <Nop>
will make it do nothing. Another possibility (I think) is
:set complete=
As it turns out the way to turn this off is
:set completeopt=
I have to read the entire doc, but as far as I can tell this takes care
of reinstating the normal vim behavior where repeating CTRL-P will
toggle the successive completions.
I'll add this to my .vimrc right after this.
So, maybe I over-reacted but after over a month when I must have hit
CTRL-[ hundreds of times (I don't use the <Esc> key) .. typing CTRL-P
instead had never happened to me once.
Now, I'm in the middle of something rather involved .. it's the end of
the day .. I'm tired .. hungry .. frustrated .. and suddenly there
appears this huge long rectangle of some bright pink color masking a
sizeable chunk of whatever I am doing .. now what .. have I been
rooted..? So unexpected that it must have taken me at least ten seconds
before I realized that this artifact was meant to be a popup menu.
Because you see, the text on this menu (non-GUI) is a barely legible
light grey on a pink background. Even with the default color scheme.
Here (with an "almost-default" colorscheme that doesn't change the popup menu
colours) it's black on pink with the highlighted line black on light grey.
Quite legible (in gvim). You can change it, of course, see ":help hl-Pmenu"
and what follows it.
And guess what .. after this rude encounter with progress .. I tried
to continue my editing session .. I was so upset that I kept hitting
CTRL-P instead of CTRL-[ .. must've done it a dozen times ..
Next time something untoward like that happens, first take a deep breath, then
make sure your fingers go where you want them to go ;-) The [ key is more
crowded and (on some keyboards like the one I'm using at the mo') narrower
than the Esc key. But it _is_ nearer to where the right hand usually hovers.
I don't believe in using completion any more .. too much overhead to be
worth the trouble .. I'd rather work on my typing skills. All the same
I'm rather curious as to why this was implemented via a popup menu that
masks part of the contents of the buffer rather than some kind of
mini-window ..
And where would that mini-window have gone? If the result would have been
shoving the whole display up by the height of your "mini-window", it would
IMHO have been much more disruptive. The way it is done here, the popup
happens near the cursor but doesn't hide the part of the buffer where the
insertion is made, and it doesn't move whatever text is not directly overlaid
by the popup. Minimum eye movement. I like it.
I guess it was done this way because whoever programmed it (and sent in a
patch) did it this way, and Bram had no objections against the principle.
I'll have to search the archives .. see if there was some kind of
discussion at one point over this implementation choice?
I find it rather hard to believe that I am the only user of vim to
regard this as .. hmm.. I think "wrong" is the word.
In the future I guess I'll have to read the release notes carefully to
avoid such nasty surprises.
which should (IIUC) disable both Ctrl-N and Ctrl-P except when the popup is
_already_ up.
A third possibility is to disable the +insert_expand feature at
compile-time.
BTW, me too I know what I want to type, but I found out recently that for
_long_ words which have already been used in the current session (or in any
file still listed in the buffer list) it is often more efficient (and less
error-prone) to type the first letter(s) then Ctrl-N, then maybe a few
additional Ctrl-N's to select the right entry, than to type the whole
shebang by hand again. If there are too many completions, Ctrl-P to get
back to what I typed then add letters one by one, will usually narrow the
choices to just a few, including the one I want.
Makes sense when you have to work on somebody else's screwy source with
function & variable names long as your arm .. maybe. I think my main
beef with completion is that even in vim you need to juggle at least
three different mechanisms .. Insert-mode completion as above .. Ex mode
.. and whatever completions your shell allows .. The latter is not vim
sensu stricto .. but since I often escape to a shell from a vim
session, the bottom line is that it adds up to a lot of acrobatics.
Even for just a French narrative, where the word "Angleterre" often comes up,
A Ctrl-N Ctrl-N goes faster than typing the whole word. (I usually get ALIGN
first [from some HTML attributes], then Anglais, then Angleterre). Similarly B
Ctrl-N for Bourgogne (the first hit is BODY which happens near the top of
every HTML page). And of course, as you said, that kind of completion would be
even more useful if I were hacking Mozilla source, where there are identifiers
like nsJSRuntimeServiceImpl .
So I have decided to live with the typos .. they punish me .. I improve.
And yes, I use mostly gvim, but I would use it the same way in Console vim.
As for making it the default in console Vim only, I don't see why a feature
which works identically in gvim and console Vim should have different
defaults in both, especially when it is easy to disable it in the vimrc.
Works?
No it doesn't .. it _works_ in gvim because popups .. context menus ..
belong in the GUI world .. and it doesn't work on a terminal because
popups .. context menus .. do not belong in the terminal world.
I mean it "does the same thing" in both. Whether the user likes it or not is
"in the eyes of the beholder". Vim and gvim mostly "do the same thing" (gvim
has a menu and toolbar, but I hardly ever use them, and it's possible to
enable the gvim menus in Normal mode even in console Vim (if +menu was
compiled-in), see ":help console-menus". They work quite nicely and
unobtrusively (only the status line is overwritten).
Besides, I you _have_ to have completion .. the traditional CTRL-P
mechanism that goes down your list one entry at a time and places the
successive choices right where you need them rather than presenting you
with the whole list and masking possibly useful data in the process
strikes me as considerably more effective.
Definitely anti-KISS.
Question of opinion. I like it better than the (command-line) 'wildmenu' on
the status line because I can see faster how far away is the item I want. And
I like the 'wildmenu' better than "blind completion" (getting the completions
one by one with no idea how many there may be). OTOH I don't like Ctrl-D
completion (on the command line) because my whole display is shoved away, not
only the part (if any) "overlaid" by the menu.
As for disabling Insert-mode completion by default in both console Vim and
gvim, don't count on it: Bram has a long history of preferring whatever
doesn't break existing behaviour, and I can't fault him on that. ;-)
You mean Bram doesn't learn from his mistakes like the rest of us?
Just kidding ..
:-)
I mean, when it's not "obviously bad" in everyone's eyes (not just cga2000's),
then keep it as it is: that's Vim policy. Even keep some "bugs" as an option
because they've been there for so long some people regard them as "features"
(like the 'compatible' behaviour, cf. ":help design-compatible").
Thanks,
cga
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
186. You overstay in the office so you can have more time surfing the net.
