I got this reply by private mail today, but I think the issues it raises
are of interest to the list.
On 31/08/10 02:25, Henry Hertz Hobbit wrote:
THANKS! It is that autocmd that is doing it. I just commented it
out and it works fine now. I don't have too much of an issue with
the nomodeline except insofar that it deviates from what I think
needs to be provided which is a commonaliry that we can come
to depend on, on ALL platforms. It is these things where the
default behavior is not the same that is causing the problem. I
guess what I am arguing for is that all Linux distros should probably
NOT tamper with what ever Bram thinks should be in the /etc/vimrc
file and we can go from there. This inconsistency of one Linux distro
with another or what is provided on Sun Solaris and Windows drives
me nuts. Mostly, what is going into my .vimrc file is NOT my
additions but something to get rid of all these differences and
come up with some commonality. My needs are fairly simple. But
for example, Fedora and RHEL both had it wrapping my files that
had ".txt" as an extension at the 80th column. Who asked them to
do that? If you ask me, the /etc/vimrc file should be very sparse and
give only what Bram deems needs to be there (what I get when I
install vim on Solaris or windows is fine).
I wouldn't say that that autocommand is "not what Bram deems needs to be
there". In fact, Bram's own vimrc_example.vim has that same autocommand,
and (about what you're saying in the next paragraph) it does bring you
back to the last known cursor position ("back to where you were at"),
not forcibly at the bottom unless that's where the cursor happened to be
when you last closed the file.
About ":r" and ":rew": ":r" (read) reads a _different_ file after the
indicated range (or after the current line by default), it doesn't set
any "known location" concerning the file named as an argument, which is
not the file you edit but something which gets copied into it. ":rewind"
(go to the first file in the argument list) is something I don't use, I
prefer to have all the files with which I'm currently working open in
windows or tabs, at least if I'm really switching between one and the
other. In the case of successive chapters into which I may divide a
larger work, I keep the current one in a window, with maybe the table of
content and the index in two others; chapters other than the current one
are not even loaded except when going from one to the next, or when I
need to refer back to them.
But I also do think the behavior of not coming back to where you were
at in an edit buffer during a current edit session but shoving it to the
bottom of the window instead is NOT a good default behavior. vi doesn't
do it, EMACS doesn't do it, and what I used to use which is
MicroEMACS (no more termcap so I had to say goodbye to it) didn't do
it. Neither does vim on Ubuntu. The problem is that when I come back
to the buffer I need to see both below and above where I was at. I didn't
mind it being just exactly where I was at when I left the buffer in a
current editing session which should probably be the default behavior.
I am of course referring to using the ":r" & ":rew" commands. But the
centering of the cursor via the zz in my macros is INFINITELY better
than shoving the edit cursor to the bottom of the screen. That is exactly
what happens with vim on OpenSuse. Even when I let vim has its
history (don't use -i NONE), it still has this HORRIBLE behavior.
Me too I like to see at least a few lines above and below the cursor (if
there are any), for that I use the 'scrolloff' option (q.v.) ATM I have
scrolloff=3 -- if you set it to some high value such as 999 the cursor
line will always be held near the middle of the window except when
you're at the top or bottom of the file.
With Windows, you don't have this problem. You get what Bram provided
which is just fine with me. But I am really baffled by what OpenSuse did.
Unlike Ubuntu which doesn't have a root login which I bypass by doing a
sudo of an xterm, Suse DOES have a /root $HOME folder for root and the
nomodeline can be set there in /root/vimrc. It is distros like Ubuntu that
should be throwing things like nomodeline into the /etc/vimrc file since
root doesn't have a home - well, it does now for me. But I am not the norm.
In the sudo'd xterm I also have to type:
cd /root
. .profile
. .bashrc
The stuff I am editing almost never has me going back to where I was at
except within a current editing session. That is when I want to be put back
precisely to where I was at using the ":n", "rew" commands. After an
editing
session has ended I want the editor to forget what I was doing because I am
almost always doing something different than what I did before with the
same file.
Even if I am doing the same thing I have an excellent memory. That is ue to
playing Mahjongg tiles and backing up when it fails which excercises my
memory to remember where everything was at. Even after several days or
even weeks I can go right back to where I was at. That isn't with just one
thing either - I can do it dozens of things.
All history is for me is something somebody can use to find out what I
was doing. Similarly, when I reboot from Linux to Windows I close all of
my xterms, then open one last xterm that I type "trim" in. It deletes not
only the BASH history but lots of other history things as well. I like each
session to come up with a clean state. History of what I have done is
neither needed nor wanted except within the narrow confines of a current
edit session for vim or a current login. Thereafter I like to start
fresh. If
you saw what I deal with (preventing Windows malware, reducing tracking
of what you do online, etcetera) you will begin to understand that
history is
a security loophole that can be abused to keep Linux malware going long
after it should be dead. If malware ever comes to Linux I can promise it
will use these history mechanisms to keep it going. Clean state is ALWAYS
better from a security perspective.
I'm not that paranoid -- or I exercise my paranoia in different ways:
for instance, not letting someone else at my keyboard (at home -- I'm
retired and celibate), not opening suspicious emails other than in "View
Source" mode, never clicking a link if I have no idea what it links to,
even in an email from a known friend (and bye-bye greeting cards and
other tinyurl links), etc. Even using Linux rather than Windows could be
seen as a security measure, though I take with a grain of salt the
affirmations that "there are no viruses targeting Linux" which used to
be an argument used by distros against packaging any kind of antivirus
software when I first tried Linux -- I think it was SuSE 6.4 or some such.
I don't pretend that my memory is as perfect as silver-halide
photographic film, but even if it were, I would still keep some info in
history and registers from one session to the next: for instance, in
Insert mode at the start of an HTML file I prefer hitting Ctrl-R d than
typing (without the outer quotes) "<!DOCTYPE html PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN">" -- and that's just one example among several.
If you need to hide from other people (your boss? your wife?) everything
that you've been doing while at the keyboard, maybe you ought not to
have done it in the first place?
Best regards,
Tony.
--
A billion here, a couple of billion there -- first thing you know it
adds up to be real money.
-- Senator Everett McKinley Dirksen
On Sat, Jul 24, 2010 at 3:42 AM, Tony Mechelynck
<[email protected] <mailto:[email protected]>> wrote:
On 23/07/10 06:13, Henry Hertz Hobbit wrote:
When I am using vim on OpenSuse 11.2 and switch from one buffer to
another I have already been in using the :rew or :n it has the very
disturbing behavior of positioning the cursor at the bottom of the
screen. At first I thought it was just a behavior that exists in an
xterm but then I found it also exists in gvim as well. I finally
mapped the following function keys to get rid of this strange
behavior
(this my entire ~/.vimrc file):
set hlsearch
set nobackup
set nocompatible
set noerrorbells
set nowrapscan
set showmatch
set showmode
map<F5> :n<CR>zz
map<F6> :rew<CR>zz
map<F7> :wn<CR>zz
map<F8> :w!<CR>zz
map<F12> :x!<CR>
" set so=999
behave xterm
All they have are the following files in /etc:
/etc/vimrc
/etc/skel/.vimrc
I cannot find what is doing it in the /etc/vimrc file. What do I
need
to do to turn this behavior of bottoming of the cursor off
(other than
using the preceding Fn keys)?. If nothing else this argues for Bram
coming up with a standard that all Linux and Unix vendors should use
for the /etc files to give a minimal standard for everybody to
proceed
from. Some turn on hlsearch (I prefer it) and some don't. I can
clearly see that is something that is optional that should
probably be
off by default. That isn't the problem - I want all of these
differences to disappear and not have something like this happen
again.
Or is it a bug that has been fixed? It doesn't happen on Ubuntu
10.04. Please send me a personal answer if at all possible since I
only receive the Abridged summary.
"Bram's standard" applies if there is _no_ system vimrc. Any
/etc/vimrc (if that's the compioled-in place where your distro's Vim
looks instead of $VIM/vimrc) overrides Bram's defaults, often
misguidedly.
I've had a look at the openSUSE /etc/vimrc, and I notice two things
near the end: one, which I'd say is misguided is that "the SuSE
security team requires 'nomodeline' to be unconditionally set" — not
only when running as root which has lately become the Vim default.
The other is an autocommand, copied from the
$VIMRUNTIME/vimrc_example.vim (a "typical" vimrc distributed with
Vim, and which could be called "Bram's optional standard for those
who don't expressly want behaviour 'compatible' with legacy vi"),
and it moves the cursor to the "last known position" whenever you
open a file. If that last known position was at the very bottom
you'll be at the bottom of the window — there's nothing after that
in the file. If there is no last known position, it will by default
be at the top of the file, and that also means the top of the
window. If you've been looking at the contents of an existing file
it could be at any point in the file and in that case it will be
near the middle of the window. Don't you think that this "bring me
back where I left off" behaviour is useful? I do.
Best regards,
Tony.
--
New members urgently required for SUICIDE CLUB, Watford area.
-- Monty Python's Big Red Book
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
