[buug] vim annoyances

[Paul Ivanov]

Hi Michael,

I'm sorry vim doesn't work the way you expect, but I can't sit by
and let you drag my $EDITOR through the mud ;) without responding
to at least some of your frustrations. See also the last
paragraph of the email, if you're not very interested in the
solutions provided here ;)

If you find yourself forced to use vim - I'll give you a few
entries to add to your vimrc that will hopefully make your life
better.  (NB: having a .vimrc reverts the default behavior vim
starting in "compatible" mode - so you'll want to include that as
well - since having one clearly indicates that you know what vim
is).

" Note: double quotes are the comment character in .vimrc
"

Michael Paoli, on 2011-04-06 19:51,  wrote:
> Yes, vim bit me again today,
> :q! wouldn't quit

was there a message? can you give steps on how to reproduce?
was there another buffer you edited that hadn't been saved"

from :help :quit!

:q[uit]  Quit without writing, also when visible buffers have
         changes.  Does not exit when there are changed hidden
         buffers.  Use ":qall!" to exit always.

" .vimrc solution
" have a save/ignore popup, instead of e.g. failing to quit a
" modified buffer. This will make your :q! experiences more sane
set confirm

> and it quite repeatedly forgot the name of the file I was editing.
> And all that even with its "compatible" mode.

Compatible mode never promised to be a bug-for-bug compatible
with vi. But for all its shortcomings, vim does have extensive
documentation to help you navigate through all of its
'annoyances'.
	
from :help compat

  This option has the effect of making Vim either more
  Vi-compatible, or make Vim behave in a more useful way.

see :help posix for all the documented ways in which vim does not
adhere to POSIX vi behaviour.


> From my vim annoyances collection (at least what I bothered to note,
> anyway):
> 
> vim never ceases to annoy me:
> 
> I edit a series of files using their full pathnames - given as command
> line arguments, I use ^G to note which file I'm editing - vim displays
> only a partial relative pathname - omitting the portion which allows me
> to distinguish which of two files I might be editing that have the last
> to parts of their pathname that are identical.  To make it worse, "Ah,
> workaround; :!echo %<CR> ... no go, it still only tells me that
> relative pathname tail component!  ARRRRGH!
> This causes various problems, e.g. things like this don't behave as one
> would expect:
> :!cd / && ls -ld %<CR>
> vim should never have the arrogance to presume it's smarter than those
> using it or knows better what they want than they do

you can get the full path by appending :p to the %
:!echo %:p ... is the thing you wanted
see :help filename-modifiers for more

another way of getting around this is to :cd / first - so
everything gets a full path (your ^G will work as you expect it
to). You can cd back to the directory of a given file using 
:cd %:h

" I have a :CD command defined in my .vimrc to do just that
" CD to directory containing the current file
command! CD :cd %:h

> 
> bloody .swp files!
 

" Let's not sprinkle .swp files in every directory we go inside -  ~/tmp 
" ought to be enough, use the full path of the file (//)
set dir=~/tmp//,/var/tmp//,/tmp//


> When one does an operation that happens to take a long time in vim, e.g.
> deleting a bunch of lines:
> :1,BIGNUMd
> It's darn near impossible to interrupt/stop vim!
> interrupt (e.g. control-C) doesn't stop it, neither does:
> quit (e.g. control-\)
> and it doesn't even let one use job control to suspend (e.g. control-Z)
> so that one can manually kill the sucker with some appropriate
> signal(s).  One typically has to resort to killing the sucker via some
> other login session on the host.
> 
> Dark blue on black?  You've got to be kidding!  If I wanted comments to
> be bloody invisible I wouldn't have written them!
> 
> Colors?  Ewwww, ... yuck!  Distracting!  Makes it much harder for the
> eyeballs to scan and see what I want to identify.
 
"turn off syntax highlighting
syn off

> Oh my gosh, something went horribly wrong!  I invoked vi with no
> arguments, and there's a whole lot more on the screen than just the
> tildie (~) characters in the leftmost column.  Must be some
> catastrophic error.  Oh, yes, it is ... vim.
> 
> ~
> ~                              VIM - Vi IMproved
> ~
> ~                               version 7.1.314
> ~                           by Bram Moolenaar et al.
> ~                 Vim is open source and freely distributable
> ~
> ~                           Sponsor Vim development!
> ~                type  :help sponsor<Enter>    for information
> ~
> ~                type  :q<Enter>               to exit
> ~                type  :help<Enter>  or  <F1>  for on-line help
> ~                type  :help version7<Enter>   for version info
> 

" don't show startup message - just gimme a column of tildes, the
" way Bill Joy wanted it
set shortmess+=I

> "Oh, you can change that in vim, just configure ..." - bloody heck, it
> should do the right thing by default!  

I'd argue that this *is* the right thing - it's letting you know
that it's *NOT* vi - it's something slightly different.

> And yes, I've tried vim's :se
> compatible - it's not very compatible, and it's also not the default
> either.

it's the default if it didn't find a .vimrc or a .gvimrc

'compatible' 'cp' boolean (default on, off when a |vimrc| or |gvimrc| file is found)

> 
> bloody .sw[o-z] files
> 
> bloody non-FHS compliant doesn't know where to properly write temporary
> files!  I did mention .sw[o-z] files, right?  I don't think I mentioned
> them enough yet.

" if you really don't want swapfiles, you can stop making them
set noswapfile
 
> regular expressions, there's shell metasyntax, there's Basic Regular
> Expressions, there's Extended Regular Expressions, there's Perl Regular
> Expressions, and damn near everyone does it exactly or almost exactly
> like one of those, but vim, no, you couldn't do like those with one or
> two or three or so exceptions, but you add a whole bunch of stuff in
> vim regular expressions that matches no one else's regular expressions
> - highly incompatible.  And yes I tried vim's compatible option, and
> not it's not compatible.
> 
> I've used (classic UNIX) vi and BSD vi / nvi for decades, my fingers
> fly on the keyboard issuing vi commands - it works, and works damn
> well.  I know what to expect and it does what I expect.  Vim does not,
> and repeatedly slows me down, frustrates me, and causes significant
> errors.  And yes I tried vim's compatible mode - it's not compatible.

if vim slows you down, please do not use it. Emacs slows me down
to no end - but you won't hear me complaining about it ;)

 
> :se all
> Though shallt fit complete full output of :se all within a single 80x24
> window, ... not 3 bloody screenfulls of 80x24.
> 
> vim is bloated:
> $ ls -lLs /usr/bin/nvi /usr/bin/vim /usr/bin/vim.tiny | sort -bn
>  372 -rwxr-xr-x 3 root root  372740 Jan 28  2010 /usr/bin/nvi
>  624 -rwxr-xr-x 1 root root  632884 Jul 11  2010 /usr/bin/vim.tiny
> 1480 -rwxr-xr-x 1 root root 1510796 Jul 11  2010 /usr/bin/vim
> $
> Yes, even it's tiny version is bloated

You have to consider functionality, not just size. By that
measure, nvi is bloated, too - since it's still almost 9x larger
than ed: 
$ ls -ls /bin/ed
40 -rwxr-xr-x 1 root root 39700 2010-03-04 19:47 /bin/ed

I didn't follow all of the rest but I'd be happy to try to sort
through them with you tomorrow.

It seems like your angst is a bit misdirected - you should be
mad at whoever is forcing you to use vim, or if you're not being
forced - use your preferred editor.

best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110406/5c38d86d/attachment.sig>