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
> <antoine.mechelynck@gmail.com <mailto:antoine.mechelynck@gmail.com>> 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
No comments:
Post a Comment