Re: vi issue in etch
[This message has also been posted to linux.debian.user.]
In article <9vqqV-64Y-1@gated-at.bofh.it>, David Fox wrote:
> On 11/30/07, cls@truffula.sj.ca.us <cls@truffula.sj.ca.us> wrote:
>
>> I tried to use the equivs package to inform Etch that my
>> custom vim "provides vi", and link it to the
>> /etc/alternatives/vi, but I got lost in the complexity of it.
>
> I am not so sure that you need to go that far to get the same
> functionality. I'm also not sure how you got 'nvi' installed in Etch.
apt-get install nvi
http://packages.debian.org/etch/nvi
Bug-compatible. You can't backspace past a newline in insert mode.
One level of undo. Bletch.
> I'm on a lenny system, and I have 'vim basic' installed (which does
> seem to lack the mouse pointer facilities, but I don't normally try
> and use vi(m) with a mouse).
Sometimes it's less work. <shift-click>c<shift-click> to
replace from here to there when neither end is on object boundaries.
Shifted, it's just another cursor motion command, works with all the
operators. No number multipliers, though, and "dot" (repeat last
visual edit) is seldom useful.
Unshifted, it's traditional drag- or block-and-paste word processor
behavior. Having learned vi before word processors, I don't
use it that way much. But visual selection can be handy.
Vim really is Improved.
>And, /etc/alternatives/vi on this Lenny
> install is a symlink to /usr/bin/vim.basic.
Debian's alternatives thing for vi is complicated. Much more
than a symlink. There is a set of symlinks to take care of
the various executables (view, ex, rvi...) and manpages. Most of
them are "slaves" to a "master" so they can be changed as a "link group".
And there is a database /var/lib/dpkg/alternatives which knows which
ones you have installed so it can restore the previous one if you
remove the current one, and which link groups are in "automatic mode."
Unfortunately, equivs-build doesn't seem to know anything
about it.
> Now, it seems to me (although untested) that if you were to install
> vim.full, you would then have the setups needed for your
> /etc/alternatives to point to the desired flavor of vi you want.
But then I would pull in a bunch of stuff I don't want on
a remote server. Big chunks of GNOME. X11 Session Management.
Vim-full seems mostly to be about gvim(1), which I don't use.
I like running vim(1) via ssh(1) in an xterm(1).
Gvim via ssh's X forwarding through a 25 ms link is no substitute.
> One would also think that if it didn't do that (expected) behavior,
> then it might be a packaging bug.
In a way, it is. The "rather standard set of features" is
missing a critical one.
But, to be honest, it's not why I made my own vim 7 for that server.
Vim 7.0 in Etch testing was seriously broken. Segfaults everywhere.
It's fixed, now.
Cameron
Reply to: