[This message has also been posted to linux.debian.user.] In article <[EMAIL PROTECTED]>, David Fox wrote: > On 11/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
