Loading ...
Sorry, an error occurred while loading the content.

Re: OpenSuse snafu resolved - need standard minimum

Expand Messages
  • sc
    ... granted, bram is the BDFL for vim, but doubt he can dictate anything the distros do -- at most i think he can suggest personally i think your argument
    Message 1 of 3 , Sep 4, 2010
    • 0 Attachment
      On Saturday 04 September 2010 12:48:48 Henry Hertz Hobbit wrote:

      > The solution is to comment out the autocmd. But this argues
      > for the people in this user list and Bram to dictate what
      > should be in the /etc virmc files (they are in the /etc/vimrc
      > folder on Ubuntu). I

      granted, bram is the BDFL for vim, but doubt he can dictate
      anything the distros do -- at most i think he can suggest

      personally i think your argument should be to remove such an
      invasive autocommand from the example_vimrc, and you'll have a
      greater chance of success

      sc

      --
      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
    • bill lam
      ... IMO you may try nvi which has far less features and thus immuned to changes. As an example, modeline will never be implemented as stated inside it s man
      Message 2 of 3 , Sep 4, 2010
      • 0 Attachment
        Сбт, 04 Сен 2010, Henry Hertz Hobbit писал(а):
        > After some emails back and forth between me and Tony Mechelynck
        > who first commented that OpenSuse had an autocmd and nomodeline
        > the answer to getting rid of the shoving the cursor down to the bottom
        > on re-entry into a previous buffer is revealed. It is the autocmd that is
        > doing it. As far as the nomodeline is concerned, it seems to me that
        > Ubuntu would be the one that needs it since root has no login ability
        > there. That is a design snafu (only using sudo - you cannot login as
        > root on the console) they will come to regret when malware moves into
        > normal user accounts. The best way to get rid of it is to login as root
        > to fix the damage.
        >
        > The solution is to comment out the autocmd. But this argues for
        > the people in this user list and Bram to dictate what should be in
        > the /etc virmc files (they are in the /etc/vimrc folder on Ubuntu). I
        > would say the minimal amount is an optimal solution. Fedora at
        > one time had auto-wrap turned on if the file name had a ".txt"
        > extension. At first I thought it was what Bram had decided was
        > appropriate. It drove me nuts and I finally deleted it. But this cursor
        > being shoved to the bottom of the window made it impossible to edit
        > and compare two very similar files until I added the buffer function key
        > macros with a zz at the end of the macro. Once that was done some
        > sanity was restored. IMHO, Bram with consultation of the Vim gurus
        > in this user list needs to reduce these heresies to zero. I don't want
        > the behavior to be different from one Linux distro to the next when the
        > user either has no .vimrc file or if they do have one it has zero length.
        > It has got to the point that I am using my .vimrc to add the precious
        > few alterations I provide but far more are things I am using to reduce
        > or eliminate this cross platform chaos.
        >
        > I can tolerate a slight difference on Windows due to the nature of the
        > beast but even there the change needs to be only what is necessary.
        > Until now I shifted back and forth between using a little race horse editor
        > called MicroEMACS and vim depending on what I was doing. If I was
        > using ad-hoc macros I would use MicroEMACS since they ran infinitely
        > quicker. But termcap is gone now on OpenSuse and after comparing
        > the slow vim ad-hoc macro (compared to MicroEMACS) capabilities to
        > the glacially slow emacs macros I shifted to using vim for all normal
        > editor chores.
        >
        > I will have some comments on this and lot of other stuff in just
        > a few days here:
        >
        > http://www.securemecca.com/public/VimStandard.txt
        >
        > Basically, this:
        >
        > http://preview.tinyurl.com/2bv5pwc
        >
        > has turned up the time-line for when I say people need to say
        > goodbye to Windows. But to do it we need some standardizing
        > first.
        >
        > Browsers:
        > Chrome, Firefox, or Opera (alpha order)
        >
        > Editors:
        > OpenOffice
        > vim (consistent base standard across all platforms and distros)
        > emacs (ditto)
        >
        > People don't have time for personal preference changes due to
        > some distro authors who think this wham doozle way of doing
        > things is something everybody should want. If they want to do
        > it, have them put them in the skeleton .vimrc files but commented
        > out so people can make their own decisions on whether it is
        > appropriate for them. Personally, I don't want vim history and
        > always use "-i NONE". But I don't think most people would share
        > that viewpoint. It is just that every time I edit a file I edited before I
        > am almost never doing the same thing. Having vim going to
        > where I was at rather than clean state is not what I want. But
        > in general I don't much of history in anything except for a
        > temporary basis for BASH in an xterm.
        >
        > There is more to this than just the standardizing of vim, but
        > lets start there, okay?

        IMO you may try nvi which has far less features and thus immuned to
        changes. As an example, modeline will never be implemented as stated
        inside it's man page.

        PS. I use both, vim as an ide and nvi as an editor.

        --
        regards,
        ====================================================
        GPG key 1024D/4434BAB3 2008-08-24
        gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

        --
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.