system vimrc file maps <Esc> key-combinations

English Applications
#1

In vim I have no timeout for mappings. But the timeout was not working for the <Esc> key. Then I realised that the default /etc/vimrc defines some mappings which contain the <Esc> key, so that vim is waiting for additional input whenever I press <Esc>.

  1. Is there some reason for these mappings in /etc/vimrc ? I commented them, and everything still seems to work.
  2. Is modifying /etc/vimrc the best way to prevent these mappings? What will happen to /etc/vimrc when I update vim?

Greetings

#2

It will probably revert to the install defaults.

I prefer old fashioned “vi” behavior. I was just removing “/etc/vimrc”. But that became tiresome. So now, the first three lines of my “.vimrc” are:


syntax off
set compatible
set viminfo=

and that seems to turn off the behavior that I don’t like.

#3

Ah, thanks.

One would say that vi is frozen for so many years, but switching to Leap 15.0 (from 13.1) confronted me with all sorts of irritating behaviour.

To begin with, “old” vi checked a file to see if it contains Unicode (more then ASCII) and then automaticaly took that into account. "New’ vi doesn’t. Thus I had to create aliases in my ~/.alias file to avoid seeing strange characters and allowing me to enter thye characters I need.

alias vi='vi --cmd ":set encoding=utf-8"'
alias view='view --cmd ":set encoding=utf-8"'

And then, when typing HTML, it interferes with my layout, apparently knowing better how I like my programs to look like then I do myself. >:(

#4

Try running your vim in an Xterm console, the “enhancements” you see are likely because the Terminal app you’re using has standard openSUSE feature enhancements (Xterm is always installed by default and has no such features).

TSU

#5

First, to be precise, I use the vi command, not the vim command. I know that the same executable is then started, but nevertheless the program may (and I hope will) act different.

It struck me that you think that a CLI editor that apparently is context aware of certain “types” of text files (the type detected either by looking at a suffix of the file name or by making an intelligent guess upon the contents) would change it’s awareness actions depending on the terminal (emulator) used.

Thus, as suggested I opened the same file in Konsole and Xterm side by side and did the same action (adding a HTML tag in a line) in both. In both cases it added a TAB character in front of the line. Something that did not happen in vi in openSUSE 13.1 and something I did not ask for, irritates me because I have then to correct that.

So far for the “enhanced” features of vi being contributed to Konsole.

And about the encoding.

In both cases (on Konsole and on Xterm), vi opens the file interpreting the encoding as UTF-8 because of my alias. This checked by using the :set command in vi.
But, characters that are correctly shown in Konsole (e.g Fédérés), are shown as (Fédérés for the same word) in Xterm.

When I use the command /usr/bin/vi, thus avoiding my alias, the :set command does not show any encoding indication, thus I have no idea how it is inetrpreted, but in the Konsole case only some characters are shown wrong (not those in Fédérés), where Xterm looks the same as before.

My conclusions:

  • the context awareness if vi is not influenced by the termianl (emulator) used;
  • Xterm lacks support for UTF-8 in some way or the other, even if vi states that it is UTF-8.
#6

I normally use “xterm”. I’m not a big fan of Konsole. But the difference in behavior might be a matter of $TERM, and there is a Konsole setting for that.

#7

I verified this HTML behavior on a 15.1 vim running in xterm.

So, I listed the installed plugins by typiing the following in vim

:scriptnames

I see at least one and possibly a second plugin that might be doing the indenting (there is a plugin called “Indent”)

Remove that/those plugins and you might see the undesirable behavior disappear.
Or, modify the plugin to apply the indenting you prefer.
You can load/unload the plugins and enable/disable other things in the following

:function

TSU

#8

While I appreciate the effort you put into finding features for me to undo the new behaviour, my main point was not as much as finding these as well as a confirmation to the OP here that things in vi/vim are changed and a thank you to @nrickert for publishing a way to make vi act as vi.

The main point here is IMHO that somebody decided that vi should be “improved”, and that then was implemented and forced upon the users (that were happy with vi as it was for tens of years) as new (and thus unexpected) default behaviour.
Before switching to a new version of openSUSE (or any other operating system), you can test what you want, but the nasty things are always on those places you wouldn’t expect them. And a different behaviour of such a basic tool as vi is, at least for me, frustrating, tiring, annoying, etc. When I start vi, I want to edit something, I do not want to have to spend time in finding out why the thing does not do what it did since ~1970!

#9

I guess we know where to report/complain about these things (bugzilla)

Personally, I am a little bit (only a little) that plugins are implemented without a plugin manager…
But, that’s just my preference for organizing plugins in a management tool rather than simply activating by configuration.

TSU

#10

In this case, it is not so much a bug. Rather, it is a feature (or misfeature) that some of us really dislike.

#11

I should maybe add: the rest of “.vimrc” is just copied from my old “.exrc”. Once you have a “.vimrc”, it no longer reads “.exrc”.

I’ll note that a basic Ubuntu install uses a stripped down “vim” (I think they call it “tinyvim”) which doesn’t do that annoying syntax highlighting. And it complains about that “syntax off” line in “.vimrc”. So I just use “.exrc” for Ubuntu and “.vimrc” for openSUSE. And I’ll note that Ubuntu is just for testing – I never much liked it, though it does work pretty well.