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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

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

-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org