switching to vim-tiny for standard vi?
Joey Hess
create a vim-tiny package that is vim without some of the extras such as
syntax highlighting. It's now only marginally larger than nvi, which is
the standard vi included in the base system (amazingly, it's smaller
than nano, the other editor in the base system). Stefano suggested that
vim-tiny could replace nvi and become part of base, and I think it's a
good idea.
There are obviously users who will prefer nvi to vim (and others who
prefer some other vi), but I get the impression there are rather more who
prefer vim, it's probably the most commonly used vi in linux these days.
One argument I can think of for keeping nvi in base is that it is the
closest to bug-compatible with the original vi. However, I don't think
that will prevent hardcore vi users from easily using vim-tiny if
it's in base.
----- Forwarded message from Stefano Zacchiroli <za...@debian.org> -----
From: Stefano Zacchiroli <za...@debian.org>
Date: Sun, 18 Dec 2005 16:19:50 +0100
To: Joey Hess <jo...@debian.org>
Cc: Len Sorensen <lennart...@ruggedcom.com>, 222...@bugs.debian.org
Subject: vim-tiny is in unstable
User-Agent: Mutt/1.5.11
On Tue, Nov 01, 2005 at 01:46:27PM -0500, Joey Hess wrote:
> > Do you like me to ping you again when the packaging is in its final
> > shape - perhaps after the upload to unstable - so that you can start
> > the thread on d-d (after all you're the submitter and a member of
> > the d-i team) or what?
> Yes that would be fine.
Hi Joey, vim-tiny is available in debian/unstable. There are still some
minor bugs, but the package is fine. The installed-size of it and of
vim-common are as I anticipated (776 + 232 on i386); the only additional
dependencies are libc6 and libncurses5.
Feel free to start the discussion on d-d for the inclusion of vim-tiny
in the base system in place of nvi (or just ask and I will do it).
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
----- End forwarded message -----
--
see shy jo
Lars Wirzenius
> One argument I can think of for keeping nvi in base is that it is the
> closest to bug-compatible with the original vi. However, I don't think
> that will prevent hardcore vi users from easily using vim-tiny if
> it's in base.
I'm one of the people who prefers nvi over vim. I do so quite strongly,
because I find that nvi obeys my fingers and vim does not. The
differences are minute, of course, but they are really irritating.
Unfortunately, I can't enlist them properly, since my fingers don't talk
to me: I notice vim's incompatibility from the fact that my fingers have
to keep correcting text under vim, but not under nvi. On days when I'm
generally annoyed already, if I accidentally use vim instead of nvi, I
can get quite lyrical with my cursing.
I'm not bothered at all by switching nvi with vim-tiny in base. As long
as I can install nvi if I want to, I'm happy. I'd even be happy without
any vi-like editor in base. As long as there is one editor in base that
I can without great difficulty in an emergency (nano seems to qualify),
I don't need anything more.
In fact, given that it's good for base to be small, I'd like to suggest
that we don't have more than one editor there.
--
The most difficult thing in programming is to be simple and
straightforward.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew M.A. Cater
> There are obviously users who will prefer nvi to vim (and others who
> prefer some other vi), but I get the impression there are rather more who
> prefer vim, it's probably the most commonly used vi in linux these days.
the most basic system, no matter how stripped down.
>
> One argument I can think of for keeping nvi in base is that it is the
> closest to bug-compatible with the original vi. However, I don't think
> that will prevent hardcore vi users from easily using vim-tiny if
> it's in base.
/AIX admins who may have got used to nvi? Unfortunately, the vi/vim
flamewars are not yet concluded :(
All IMHO, ATB,
Andy
Norbert Tretkowski
> In fact, given that it's good for base to be small, I'd like to
> suggest that we don't have more than one editor there.
We already have two editors in the base system, nvi and nano.
Norbert
Marco d'Itri
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
Sure, I often use vim over serial consoles.
--
ciao,
Marco
Lars Wirzenius
> * Lars Wirzenius wrote:
> > In fact, given that it's good for base to be small, I'd like to
> > suggest that we don't have more than one editor there.
>
> We already have two editors in the base system, nvi and nano.
Yes, that being the bloat I was referring to.
--
C is the *wrong* language for your application.
Joey Hess
> I'm one of the people who prefers nvi over vim. I do so quite strongly,
> because I find that nvi obeys my fingers and vim does not. The
> differences are minute, of course, but they are really irritating.
> Unfortunately, I can't enlist them properly, since my fingers don't talk
> to me: I notice vim's incompatibility from the fact that my fingers have
> to keep correcting text under vim, but not under nvi. On days when I'm
> generally annoyed already, if I accidentally use vim instead of nvi, I
> can get quite lyrical with my cursing.
Yeah, I understand the feeling (coming at it from the exact opposite
side). It would be helpful if there were an analysis of the major differences
somewhere; the ones I am most aware of incude:
- home, end, page up, page down, and delete, all do something reasonable in
vim in insert or append mode, but do nothing very useful in nvi in those
modes.
- in vim the arrow keys always move around even in insert mode. In nvi
they do too (surely it diverges from "real vi" here?), but if you arrow
to the end of a line, it flashes the screen and drops you out of insert
mode.
- vim wordwraps long lines by default as they are inserted (bloody annoying);
nvi usefully just logically wraps the single long line for display
- backspace in vim deletes the character to the left, instead of just
moving the cursor back and temporarily turning off insert mode
- backspace in vim can delete text you have not just inserted; in nvi it
only backspaces through the just inserted text
- delete in vim deletes the character under the cursor and if you delete
all the way to the end of the line, pulls the next line "up" and begins
deleting it too, whereas in nvi delete begins backspacing through the
remainder of the line if you reach the end of the line, and it never
deletes other lines
- vim supports multiple levels of undo; in nvi the second undo undoes your
undo
- some commands like 'cw' display differently in vim, although the end
result of the keystrokes is the same for all the standard vi commands I
use
- nvi flashes the screen/bell when a command fails; vim does not
- :help vi-differences in vim describes some other differences that are
less noticible
> I'm not bothered at all by switching nvi with vim-tiny in base. As long
> as I can install nvi if I want to, I'm happy. I'd even be happy without
> any vi-like editor in base. As long as there is one editor in base that
> I can without great difficulty in an emergency (nano seems to qualify),
> I don't need anything more.
>
> In fact, given that it's good for base to be small, I'd like to suggest
> that we don't have more than one editor there.
IIRC the reason we have a vi in base, and at priority important at that
is because of the definition in policy that:
`important'
Important programs, including those which one would expect to
find on any Unix-like system. If the expectation is that an
experienced Unix person who found it missing would say "What on
earth is going on, where is `foo'?", it must be an `important'
package.
Which of course includes a vi. (Note that the paragraph goes on to explicitly
rule out emacs.)
--
see shy jo
Joey Hess
> Will it work fine over a serial console?
Yes, vim works fine over a serial console. You might want to turn off
part of the status line if using it at less than 9600 baud.
> Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi?
I imagine they might have gotten used to non-bash shells too; I don't
think the goal of Debian is to exactly replicate those systems, and we
should instead strive to pick default unix tools that are the commonly
recognised best of breed today.
--
see shy jo
Graham Wilson
> On Sun, Dec 18, 2005 at 01:38:57PM -0500, Joey Hess wrote:
> > There are obviously users who will prefer nvi to vim (and others who
> > prefer some other vi), but I get the impression there are rather more who
> > prefer vim, it's probably the most commonly used vi in linux these days.
>
> Count me as an nvi person. Vim is great - but not as the default in
> the most basic system, no matter how stripped down.
Why is nvi better if the size of nvi and vim-tiny are comparable?
--
gram
Joey Hess
includes the vimtutor command, which is a fairly good way to learn how
to use vim (or any vi; it avoids most vim-isms). The tutor is how I
finally learned (to love) vi after years of badly using and loathing it
as the base editor on other unixes. Having our base vi be self-teaching
like that could be nice.
--
see shy jo
Lars Wirzenius
> Yeah, I understand the feeling (coming at it from the exact opposite
> side). It would be helpful if there were an analysis of the major differences
> somewhere; the ones I am most aware of incude:
I'm not personally very interested in this. If the size of vim-tiny is
not bigger than nvi, I really couldn't care less which one is the
default. Either is good enough as a vi clone for base; the
incompatibilities are small enough not to matter for that case. I don't
want to spend any effort (again, personally) in convincing people to
switch their preferred editor, or preferred vi clone.
That being said, I'd like to point out the minor error in the list you
wrote so far:
> - vim supports multiple levels of undo; in nvi the second undo undoes your
> undo
In nvi, to undo more than one level, you use the "repeat last edit"
command (bound to period); "u" undoes an undo (and period after that
repeats, so undoes further undos). For some people this is quite
logical, and it drives other people nuts.
> IIRC the reason we have a vi in base, and at priority important at that
> is because of the definition in policy that:
>
> `important'
> Important programs, including those which one would expect to
> find on any Unix-like system. If the expectation is that an
> experienced Unix person who found it missing would say "What on
> earth is going on, where is `foo'?", it must be an `important'
> package.
>
> Which of course includes a vi. (Note that the paragraph goes on to explicitly
> rule out emacs.)
In the name of reducing base's size, I would support a policy change
here, excempting vi clones, but I suspect I'd be shouted down.
Personally, I think "standard" would be the appropriate priority for for
the vi clone.
--
Fundamental truth #2: Attitude is usually more important than skills.
Joey Hess
> In the name of reducing base's size, I would support a policy change
> here, excempting vi clones, but I suspect I'd be shouted down.
> Personally, I think "standard" would be the appropriate priority for for
> the vi clone.
In which case it wouldn't really reduce base's size, since standard is
installed anyway on (most) systems.
--
see shy jo
Russ Allbery
> On Sun, Dec 18, 2005 at 06:54:42PM +0000, Andrew M.A. Cater wrote:
>> Count me as an nvi person. Vim is great - but not as the default in
>> the most basic system, no matter how stripped down.
> Why is nvi better if the size of nvi and vim-tiny are comparable?
Among other things, because it doesn't do the obnoxious auto-indent thing
that you have to work around with :set paste. I have no objections to vim
as an editor, but it would be nice for vi to be, er, vi. vim isn't really
vi; it's something that was originally based on vi and is now something
slightly different.
(Of course, nvi isn't exactly vi either, but it's a lot closer.)
This isn't really new information. I guess I'm just speaking up to
represent those people who do indeed care about tighter compatibility to
the original vi than vim offers. I won't lose lots of sleep if I lose
this argument. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Glenn Maynard
> Lars Wirzenius wrote:
> > I'm one of the people who prefers nvi over vim. I do so quite strongly,
> > because I find that nvi obeys my fingers and vim does not. The
> > differences are minute, of course, but they are really irritating.
> > Unfortunately, I can't enlist them properly, since my fingers don't talk
> > to me: I notice vim's incompatibility from the fact that my fingers have
> > to keep correcting text under vim, but not under nvi. On days when I'm
> > generally annoyed already, if I accidentally use vim instead of nvi, I
> > can get quite lyrical with my cursing.
>
> Yeah, I understand the feeling (coming at it from the exact opposite
> side). It would be helpful if there were an analysis of the major differences
> somewhere; the ones I am most aware of incude:
":set compatible" will switch Vim's behavior for all of these, except for:
> - in vim the arrow keys always move around even in insert mode. In nvi
> they do too (surely it diverges from "real vi" here?), but if you arrow
> to the end of a line, it flashes the screen and drops you out of insert
> mode.
In "compatible", arrow keys don't work at all in insert mode, like vi
("set esckeys" to revert).
I'm not sure how to get the "moving cursor past the end of line drops out of
insert mode" behavior.
> - some commands like 'cw' display differently in vim, although the end
> result of the keystrokes is the same for all the standard vi commands I
> use
(don't know)
> - nvi flashes the screen/bell when a command fails; vim does not
":set visualbell"
--
Glenn Maynard
Joey Hess
> ":set compatible" will switch Vim's behavior for all of these, except for:
Nope, I was running vim in compatible mode (the default without a
~/.vimrc) for all of them.
> In "compatible", arrow keys don't work at all in insert mode, like vi
> ("set esckeys" to revert).
They do here.
--
see shy jo
Gabor Gombas
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi?
As an ex-Solaris/AIX admin I can say that I used vim there too (except
when the filesystem containing vim did not come up for some reason :-)
And yes, it works fine on a real vt220.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Glenn Maynard
> Glenn Maynard wrote:
> > ":set compatible" will switch Vim's behavior for all of these, except for:
>
> Nope, I was running vim in compatible mode (the default without a
> ~/.vimrc) for all of them.
/etc/vim/vimrc sets "nocompatible", among other things. Comment that out,
or run ":set compatible".
Stefano Zacchiroli
> Oh, another possible advantage to having vim-tiny in base is that it
> includes the vimtutor command, which is a fairly good way to learn how
The vimtutor content is not available if vim-runtime is not installed,
and it wont be in the base system ('vim-runtime' is the huge 13 Mb
monster package).
Stefano Zacchiroli
> Among other things, because it doesn't do the obnoxious auto-indent thing
> that you have to work around with :set paste. I have no objections to vim
Well, this is a matter of configuration, not really a matter of editor.
Debian's vim has autoindent enabled in system-wide vimrc, but it can be
disabled.
Josselin Mouette
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
> /AIX admins who may have got used to nvi? Unfortunately, the vi/vim
> flamewars are not yet concluded :(
Erm, wouldn't the fact nvi is almost as crappy as the standard PHUX
editor be a reason to drop it instead?
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Joey Hess
> The vimtutor content is not available if vim-runtime is not installed,
> and it wont be in the base system ('vim-runtime' is the huge 13 Mb
> monster package).
In that case perhaps vimtutor should move from vim-common to
vim-runtime? Although you've probably considered that already.
--
see shy jo
Joey Hess
contentious, there are some who like nvi but noone who feels very
strongly that it needs to remain the editor in base.
A few places were identified where vim's defaults are particularly
umcomfortable to people who expect a standard vi, these include
autoindent being defaulted to on in the system wide vimrc, and
nocompatible being turned on there also, which makes vim -C not behave
as expected and enables lots of divergant behavior. vim's maintainer may
want to consider documenting/otherwise dealing with these if vim-tiny
goes into base and becomes the program people get when running "vi" by
default.
I'd still like to know what Steve Greenland thinks of this, since he
maintains nvi. I think that if the maintainers of vim and nvi agree to
swap the one that is in base, that's their perogative to do now since
the thread hasn't turned up any particular reasons not to do it.
--
see shy jo
John H. Robinson, IV
> Stefano suggested that vim-tiny could replace nvi and become part of
> base, and I think it's a good idea.
I would personally vote for vim-tiny over nvi. nvi may be bug-for-bug
compatible with vi, but I don't want bugs in my editor. I find vim to be
a more user-friendly vi-like editor than nvi.
One of the first things I do on any debian install is to install vim,
and set that to be a far higher priority for editor than anything else
imaginable.
--
John H. Robinson, IV jaq...@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
Gabor Gombas
> One of the first things I do on any debian install is to install vim,
> and set that to be a far higher priority for editor than anything else
> imaginable.
Same here. That's why I do not care what the default editor in base is
:-)
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Anthony Towns
> A few places were identified where vim's defaults are particularly
> umcomfortable to people who expect a standard vi, these include
> autoindent being defaulted to on in the system wide vimrc, and
> nocompatible being turned on there also, which makes vim -C not behave
> as expected and enables lots of divergant behavior.
TBH, I think these are showstoppers. Otherwise, as long as the space issue
is fixed as you say it is, sounds fine.
Cheers,
aj
Glenn Maynard
> On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote:
> > A few places were identified where vim's defaults are particularly
> > umcomfortable to people who expect a standard vi, these include
> > autoindent being defaulted to on in the system wide vimrc, and
> > nocompatible being turned on there also, which makes vim -C not behave
> > as expected and enables lots of divergant behavior.
Hmm. It's unexpected--on its face, though the reason is obvious--that
setting "nocompatible" in vimrc breaks "-C". I wonder if there's a way
for vimrc to say "turn on nocompatible unless -C was used".
> TBH, I think these are showstoppers. Otherwise, as long as the space issue
> is fixed as you say it is, sounds fine.
I'm confused. A simple configuration change is a showstopper? (":set
compatible noautoindent" in /etc/vim/vimrc.) I havn't seen any significant
differences between vi and vim mentioned that aren't trivially fixed.
--
Glenn Maynard
Glenn Maynard
>
> This isn't really new information. I guess I'm just speaking up to
> represent those people who do indeed care about tighter compatibility to
> the original vi than vim offers. I won't lose lots of sleep if I lose
> this argument. :)
One of Vim's "selling points" is that it can be made "100% vi-compatible" [1],
so I assume any incompatibilities with vi are considered bugs. I've never
used old vi, so I don't know the accuracy of the claim, but everything listed
so far are things that :set compatible "fixes". (Except maybe the display of
"cw"--I'm not sure if nvi or vim's display is how vi did it.)
[1] http://www.vim.org/viusers.php
--
Glenn Maynard
Anthony Towns
> > TBH, I think these are showstoppers. Otherwise, as long as the space issue
> > is fixed as you say it is, sounds fine.
> I'm confused. A simple configuration change is a showstopper?
Yeah; vi not behaving like vi by default seems like a showstopper.
> (":set compatible noautoindent" in /etc/vim/vimrc.)
Just commenting out the nocompatible and autoindent lines in the default
config works too.
Cheers,
aj
Glenn Maynard
> On Mon, Dec 19, 2005 at 10:58:02PM -0500, Glenn Maynard wrote:
> > > TBH, I think these are showstoppers. Otherwise, as long as the space issue
> > > is fixed as you say it is, sounds fine.
> > I'm confused. A simple configuration change is a showstopper?
>
> Yeah; vi not behaving like vi by default seems like a showstopper.
"Can't make vim act like vi" might be a showstopper. "The default
configuration makes vim not act like vi" isn't a showstopper--it's
trivial to change.
I guess there are two competing goals here: acting like vi by default,
for the people in a time capsule, and acting like vim by default, to
show off vim's cool features. I wonder if there's a sensible way to
do both, eg. argv[0] for "vi" and "vim".
Glenn Maynard
> On Mon, Dec 19, 2005 at 03:33:35PM -0800, John H. Robinson, IV wrote:
>
> > One of the first things I do on any debian install is to install vim,
> > and set that to be a far higher priority for editor than anything else
> > imaginable.
>
> Same here. That's why I do not care what the default editor in base is
> :-)
Well, I get to use other people's systems now and then, and I'm always having
to ask people to install vim. If vim is the default, and configured to act
like vi by default, then people who like old vi get it, and people who like
new vim can change it with just .vimrc. A rare opportunity--everybody wins. :)
--
Glenn Maynard
Anthony Towns
> > Yeah; vi not behaving like vi by default seems like a showstopper.
> "Can't make vim act like vi" might be a showstopper. "The default
> configuration makes vim not act like vi" isn't a showstopper--it's
> trivial to change.
Geez, I hate arguments about defaults. If it's trivial to change, that's
great; but until the defaults are changed it's still a showstopper.
> I guess there are two competing goals here: acting like vi by default,
> for the people in a time capsule,
*sigh*
> and acting like vim by default, to
> show off vim's cool features. I wonder if there's a sensible way to
> do both, eg. argv[0] for "vi" and "vim".
The following patch lets you have a /usr/share/vim/virc (which should
be a symlink to /etc, like /usr/share/vim/vimrc) to specify different
behaviour when vim's invoked as vi instead of vim.
--- vim-6.4.old/vim64/src/main.c 2005-02-15 23:09:15.000000000 +1000
+++ vim-6.4/vim64/src/main.c 2005-12-20 16:36:49.000000000 +1000
@@ -1363,6 +1363,10 @@
* Get system wide defaults, if the file name is defined.
*/
#ifdef SYS_VIMRC_FILE
+# ifdef SYS_VIM_VIRC_FILE
+ if (STRCMP(initstr, "vi") != 0 ||
+ do_source((char_u *)SYS_VIM_VIRC_FILE, FALSE, FALSE) == FAIL)
+# endif
(void)do_source((char_u *)SYS_VIMRC_FILE, FALSE, FALSE);
#endif
--- vim-6.4.old/vim64/src/os_unix.h 2003-11-10 19:53:44.000000000 +1000
+++ vim-6.4/vim64/src/os_unix.h 2005-12-20 16:14:07.000000000 +1000
@@ -233,6 +233,9 @@
#ifndef SYS_VIMRC_FILE
# define SYS_VIMRC_FILE "$VIM/vimrc"
#endif
+#ifndef SYS_VIM_VIRC_FILE
+# define SYS_VIM_VIRC_FILE "$VIM/virc"
+#endif
#ifndef SYS_GVIMRC_FILE
# define SYS_GVIMRC_FILE "$VIM/gvimrc"
#endif
Cheers,
aj
Stefano Zacchiroli
> umcomfortable to people who expect a standard vi, these include
> autoindent being defaulted to on in the system wide vimrc, and
> nocompatible being turned on there also, which makes vim -C not behave
> as expected and enables lots of divergant behavior. vim's maintainer may
> want to consider documenting/otherwise dealing with these if vim-tiny
> goes into base and becomes the program people get when running "vi" by
> default.
I have no objection in having a separate system-wide configuration file
(/etc/vim/virc) for vim when invoked as "vi", as implemented by aj's
patch. If the other members of the vim maintaince team (Cc-ed) have
neither as well I can apply the patch and come up with a suitable
configuration file which is more in the vi spirit.
So far the only two changes proposed for such a configuration file wrt
to the current one are:
- avoid setting "nocompatible"
- avoid setting "autoindent" on per default
Correct me if I'm wrong.
> I'd still like to know what Steve Greenland thinks of this, since he
> maintains nvi.
AOL
Gabor Gombas
> Well, I get to use other people's systems now and then, and I'm always having
> to ask people to install vim. If vim is the default, and configured to act
> like vi by default, then people who like old vi get it, and people who like
> new vim can change it with just .vimrc. A rare opportunity--everybody wins. :)
Not everyone. I personally like the advanced features like syntax
highlighting, and that definitely will not be part of base (because
vim-runtime is huge). And if I still have to install vim-runtime by hand
then I can install the vim binary package as well.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Steve Greenland
> I'd still like to know what Steve Greenland thinks of this, since he
> maintains nvi. I think that if the maintainers of vim and nvi agree to
> swap the one that is in base, that's their perogative to do now since
> the thread hasn't turned up any particular reasons not to do it.
I've been avoiding commenting on this, waiting to see what the
consensus is, if any. I was hoping that there would be a strong pull one
way or the other; that hasn't happened. My thoughts:
I'm still missing the incentive. Joey Hess wrote in his earlier message
that "It's now only marginally larger than nvi". It achieves that by
removing many of the features that distinguish vim from nvi, to the
point that my guess is that most of those who prefer vim will need to
install the full vim anyway, while those that prefer nvi will just fell
vaguely dissastified by the change. If the result of this is that a)
base is not smaller, and b) vim users still have to install vim-nottiny,
and c) nvi users now have to install nvi, I don't think it's a net win.
The defaults really need to be changed to match maximum nvi
compatibility. The problem, of course, is that when someone then
installs vim-full (or whatever it's called), they don't get the benefits
of the full vim feature set or standard vim behavior w/o modifying the
config. Someone noted that it was possible to get different behaviour
depending on whether vim was started with "vi" or "vim" - I think that's
probably a good idea, but it may not be enough. It's too bad that
dpkg-divert doesn't work with config files...
Another consideration is that vim-tiny would need to swap priorities on
the /usr/bin/vi (et. al.) alternative, so that if nvi is installed, it
becomes the standard vi. But that's more of a packaging detail between
myself and Stefano.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Steve Greenland
> So far the only two changes proposed for such a configuration file wrt
> to the current one are:
> - avoid setting "nocompatible"
> - avoid setting "autoindent" on per default
>
> Correct me if I'm wrong.
Disable syntax highlighting. I understand that won't affect vim-tiny,
but it would make vi much more usable on machines with vim-nottiny
installed.
No, I'm not against syntax highlighting, I use it in emacs. The problem
is that the colors[1] are unreadable except on when the terminal
background is black and there are no lights on in the room. I realize a
lot of hackers work that way, but a lot of us don't.
And yes, of course you can adjust the colors. But if the point
of the change is to make vim-when-invoked-as-vi more like nvi, then
disabling syntax highlighting would be a good thing.
Steve
[1] Dark blue on black. Need I say more?
Stefano Zacchiroli
> Disable syntax highlighting.
Syntax highlighting is not enabled per default in /etc/vim/vimrc. In
case we decide to switch it on, it wont be in /etc/vim/virc of course.
Cheers.
Stefano Zacchiroli
> If the result of this is that a) base is not smaller, and b) vim users
> still have to install vim-nottiny, and c) nvi users now have to
> install nvi, I don't think it's a net win.
My feeling is that having vim-tiny installed is in the middle in the
"amount of features" spectrum among having nvi and having vim-nottiny.
I feel that Joey's (and mine) point in having vim-tiny instead of nvi in
base is that being in the middle of that spectrum is better than being
in the nvi corner, given that the size is comparable.
Of course is a matter of personal opinions and taste, that's why we are
asking here.
> The defaults really need to be changed to match maximum nvi
> compatibility. The problem, of course, is that when someone then
> installs vim-full (or whatever it's called), they don't get the
> benefits of the full vim feature set or standard vim behavior w/o
> modifying the config. Someone noted that it was possible to get
> different behaviour depending on whether vim was started with "vi" or
> "vim" - I think that's probably a good idea, but it may not be enough.
> It's too bad that dpkg-divert doesn't work with config files...
IMO the "vi" vs "vim" choice is enough. And since we can have two
completely different configuration file I agree that in the /etc/vim/vi
we should strive for maximum _vi_ compatibility. If going that direction
makes us more compatible with _nvi_ as well ... ok. If not I believe
that even nvi should make a step forward to be more vi compatible.
Do you have any other suggestion in addition to the two proposed to make
vim more vi compatible?
> Another consideration is that vim-tiny would need to swap priorities
> on the /usr/bin/vi (et. al.) alternative, so that if nvi is installed,
> it becomes the standard vi. But that's more of a packaging detail
> between myself and Stefano.
Agreed.
Gabor Gombas
> [1] Dark blue on black. Need I say more?
That's not vim's fault:
$ echo $TERM
xterm
But this is gnome-terminal, and _not_ xterm. xterm used a white
default background since prehistoric times, so when vim detects xterm,
it uses colors that look good with the traditional xterm colors. If it
detects the Linux console, it uses colors that look good on the console.
Now, if your terminal pretends to be xterm but does not use the color
scheme of xterm, how should vim know that?
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Henning Makholm
> But this is gnome-terminal, and _not_ xterm. xterm used a white
> default background since prehistoric times, so when vim detects xterm,
> it uses colors that look good with the traditional xterm colors. If it
> detects the Linux console, it uses colors that look good on the console.
> Now, if your terminal pretends to be xterm but does not use the color
> scheme of xterm, how should vim know that?
I would suggest that the right solution is that every program that
sets foreground colors should also, as its default behavior, make sure
to set a background color that goes well with the chosen foreground.
The "if you pick one color, pick them all" maxim of web design works
for non-web user interfaces, too.
Even with a genuine xterm users can and do set their personal color
scheme preferences in X resources. But if you're going to override the
foreground color you might as well also override the background
one. Of course any good program should offer per-user customization of
its color scheme, and offer "default" as an option for background
color, in case the user's preferred background is not among the ones
that can be set with ordinary "setb/setab" strings.
(Of course², nobody said that this will be easy to do for any
particular program).
--
Henning Makholm "Unmetered water, dear. Run it deep."
Steve Greenland
> On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote:
>
> > [1] Dark blue on black. Need I say more?
>
> That's not vim's fault:
>
> $ echo $TERM
> xterm
>
> But this is gnome-terminal, and _not_ xterm. xterm used a white
> default background since prehistoric times, so when vim detects xterm,
> it uses colors that look good with the traditional xterm colors.
No it doesn't. I use a white terminal background, and the default vim
syntax colors are unreadable there, too. (Yellow and cyan on white, in
shell scripts.)
> If it detects the Linux console, it uses colors that look good on the
> console.
Nope, because that's where I noticed the blue-on-black problem. For
example, evaluated environment variables in shell scripts.
> Now, if your terminal pretends to be xterm but does not use the color
> scheme of xterm, how should vim know that?
Well, since in fact gnome-terminal and xterm and rxvt and pretty much
every other x terminal emulator lets you configure the background and
foreground colors, basing color choices on the value of TERM is bogus
anyway.
The reality is that visibility of color combinations is heavily
dependent on all kinds of things that vim can't determine, from the font
being used and the default background color, to the ambient lighting
of the room and the vision capability of the user (not just color
blindness, but very fine variances in the color sensitivity of the user,
or even how tired the person is, which can affect their ability to
focus.) Color really needs to be tuned to the needs of the individual
user.
The problem is that there are really enough distinct colors to
complicated syntax highlighting that works with a variety of backgrounds
and lighting. I use syntax highlighting in emacs under X, because I can
set the actual fonts and styles to vary in readable (for me) ways. With
only color to work with, it becomes (IMO) pretty useless.
All of which is irrelevant if the default is "syntax off". Stefano (I
think) pointed out that it was, and I just confirmed. Maybe it used
to be on? Or maybe I'm just confused - I have to work on a lot of RH
machines, too, where vim is installed by default, definitely with
"syntax on".
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Graham Wilson
> is that the colors[1] are unreadable except on when the terminal
> background is black and there are no lights on in the room. I realize a
> lot of hackers work that way, but a lot of us don't.
I've found vim's defaults are unreadable except on a white background,
since that is what vim assumes you have by default. If you use a black
background, try
:set background=dark
which I've found improves readability quite a bit.
--
gram
Steve Greenland
> My feeling is that having vim-tiny installed is in the middle in the
> "amount of features" spectrum among having nvi and having vim-nottiny.
> I feel that Joey's (and mine) point in having vim-tiny instead of nvi in
> base is that being in the middle of that spectrum is better than being
> in the nvi corner, given that the size is comparable.
If vim-tiny does have a significant feature advantage over nvi, then
yeah, that makes sense. Since I'm not a vim user, I can't guess how
many vim users will start vim-tiny and almost immediately wonder "where
the fsck is foo; oh yeah, need to install vim". If that number is
"most of them", then defaulting to vim-tiny over nvi is not a win. Of
course, that doesn't make it a loss, either, if the size difference is
negligible. Perhaps asking over on debian-boot with the actual numbers
might make sense.
> Do you have any other suggestion in addition to the two proposed to make
> vim more vi compatible?
Nope, now that you've corrected my mistake about syntax highlighting
being on by default.
Regards,
Pierre Habouzit
> On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote:
> > A few places were identified where vim's defaults are particularly
> > umcomfortable to people who expect a standard vi, these include
> > autoindent being defaulted to on in the system wide vimrc, and
> > nocompatible being turned on there also, which makes vim -C not
> > behave as expected and enables lots of divergant behavior. vim's
> > maintainer may want to consider documenting/otherwise dealing with
> > these if vim-tiny goes into base and becomes the program people get
> > when running "vi" by default.
>
> I have no objection in having a separate system-wide configuration
> file (/etc/vim/virc) for vim when invoked as "vi", as implemented by
> aj's patch. If the other members of the vim maintaince team (Cc-ed)
> have neither as well I can apply the patch and come up with a
> suitable configuration file which is more in the vi spirit.
note that this is sth that quite a lot of distro already do : vi is a
mostly vi-compatible thing, and vim is the one with the fancy features
on.
I personnally like this a lot.
--
·O· Pierre Habouzit
··O madc...@debian.org
OOO http://www.madism.org
Steve Greenland
> I've found vim's defaults are unreadable except on a white background,
> since that is what vim assumes you have by default.
Actually, I do use a white background. Apparently your tolerance for
yellow on white is higher than mine. (Not meant sarcastically, it's
quite possible that you do see that combo better than I do.)
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Steve Greenland
> The problem is that there are really enough distinct colors to
> complicated syntax highlighting that works with a variety of backgrounds
> and lighting.
"... are NOT really enough distinct colors to DO complicated syntax
highlighting ,.."
Sigh,
Glenn Maynard
> On Tue, Dec 20, 2005 at 12:19:16AM -0500, Glenn Maynard wrote:
>
> > Well, I get to use other people's systems now and then, and I'm always having
> > to ask people to install vim. If vim is the default, and configured to act
> > like vi by default, then people who like old vi get it, and people who like
> > new vim can change it with just .vimrc. A rare opportunity--everybody wins. :)
>
> Not everyone. I personally like the advanced features like syntax
> highlighting, and that definitely will not be part of base (because
> vim-runtime is huge). And if I still have to install vim-runtime by hand
> then I can install the vim binary package as well.
OK. At least, you're not any worse off with vim-tiny than nvi.
--
Glenn Maynard
Glenn Maynard
> If vim-tiny does have a significant feature advantage over nvi, then
> yeah, that makes sense. Since I'm not a vim user, I can't guess how
> many vim users will start vim-tiny and almost immediately wonder "where
> the fsck is foo; oh yeah, need to install vim". If that number is
> "most of them", then defaulting to vim-tiny over nvi is not a win. Of
> course, that doesn't make it a loss, either, if the size difference is
> negligible. Perhaps asking over on debian-boot with the actual numbers
> might make sense.
I'd much rather have to use a system with vim and my .vimrc installed, but
lacking a few "big" features like syntax highlighting, than have to use
nvi. For me, it's a clear win: at least I can edit files. I'm probably
a fairly typical vim user.
--
Glenn Maynard
Frans Pop
> For me, it's a clear win: at least I can edit files. I'm
> probably a fairly typical vim user.
I have to agree with that.
I have used the standard vi for quite some time but always got into
problems by pressing cursor keys which resulted in being dropped out of
edit mode and a letter changing to uppercase for weird reasons.
Ever since discovering vim, I have no more problems (well, except for
occasionally pressing q instead of :q and ending up in macro mode or
something). So now it's one of the first things I install on a new
system.
IMO vim is a lot more intuitive for users who are not old-hat Linux/Unix.
Adam Borowski
> On 20-Dec-05, 09:56 (CST), Gabor Gombas <gom...@sztaki.hu> wrote:
>> On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote:
>>> [1] Dark blue on black. Need I say more?
> dependent on all kinds of things that vim can't determine, from the font
> being used and the default background color, to the ambient lighting
> of the room and the vision capability of the user (not just color
> blindness, but very fine variances in the color sensitivity of the user,
> or even how tired the person is, which can affect their ability to
> focus.) Color really needs to be tuned to the needs of the individual
> user.
The color depends a lot more on the monitor in question, rather than the
user. Nearly all of us with full color vision have roughly the same
sensitivity to all colors -- but, monitors of different manufacturers and
of different age vary a lot.
But, it's trivial to fix this issue.
On Linux console, PuTTY and a good deal of terminal emulators:
echo -ne '\e]P40000ff'
(ESC ] P <color num (0..f)> <RRGGBB color code>)
You can put your palette into /etc/issue, bash prompt or anywhere else.
On real xterms, you can mess with X resources.
On gnome-terminal and konsole, you waddle through the GUI.
If you happen to use CRT monitors that are more than a couple years old,
improving the color palette is pretty much a must.
--
/-----------------------\ Shh, be vewy, vewy quiet,
| kilo...@mimuw.edu.pl | I'm hunting wuntime ewwows!
\-----------------------/
Segmentation fault (core dumped)
Adam Borowski
> Scripsit Gabor Gombas <gom...@sztaki.hu>
>> Now, if your terminal pretends to be xterm but does not use the color
>> scheme of xterm, how should vim know that?
You can't.
real console: TERM='linux'
xterm: TERM='xterm'
gnome-terminal: TERM='xterm'
konsole: TERM='xterm'
PuTTY: TERM='xterm'
rxvt: TERM='rxvt'
aterm: TERM='rxvt'
wterm: TERM='rxvt'
> I would suggest that the right solution is that every program that
> sets foreground colors should also, as its default behavior, make sure
> to set a background color that goes well with the chosen foreground.
> The "if you pick one color, pick them all" maxim of web design works
> for non-web user interfaces, too.
Good idea.
Just stick \e[40m into the program's color codes and suddenly the scheme
becomes XXX-on-black. Use \e[47m and you get XXX-on-white. And, if
termcap/terminfo claim the terminal doesn't support \e[4Xm, it's termcap
which is wrong -- according to my data, Win3.1..ME telnet.exe was the last
terminal emulator in existence which can't handle these.
> Even with a genuine xterm users can and do set their personal color
> scheme preferences in X resources. But if you're going to override the
> foreground color you might as well also override the background
> one. Of course any good program should offer per-user customization of
> its color scheme, and offer "default" as an option for background
> color, in case the user's preferred background is not among the ones
> that can be set with ordinary "setb/setab" strings.
Few fancy terminal emulators obey X resources, but you're right. While
the way to set the color palette differs, all of the terminals I named in
this message provide a way to do so.
However, you're wrong if you believe "setb/setab" are good for anything.
Since termcap and terminfo are based on the value of "TERM", they assume
some random settings which are hardly ever valid.
The list I put in the beginning shows that even terminals which use
completely different code bases and have little coverage of common
standards tend to claim they're "xterm". And that's only several
terminals included in Debian. If you go outside, things get a lot worse;
the most spectacular example happens if you log on into a SunOS machine
using any of three terminals shipped with IRIX (as of ~7 years ago).
The failure mode includes removingallcolorsandallspaces.
It may sound strange, but if you want portability, you can't use termcap,
terminfo or *curses -- but on the other hand, using lowest-common-
denominator vt100 codes, \e[ foo m and ioctl(TIOCGWINSZ) makes things work
perfectly everywhere I tested save for the damned telnet.exe.
--
/-----------------------\ Shh, be vewy, vewy quiet,
| kilo...@mimuw.edu.pl | I'm hunting wuntime ewwows!
\-----------------------/
Segmentation fault (core dumped)
Louis-David Mitterrand
> On 20-Dec-05, 12:54 (CST), Graham Wilson <gra...@mknod.org> wrote:
> > I've found vim's defaults are unreadable except on a white background,
> > since that is what vim assumes you have by default.
>
> Actually, I do use a white background. Apparently your tolerance for
> yellow on white is higher than mine. (Not meant sarcastically, it's
> quite possible that you do see that combo better than I do.)
FWIW I have been using this for years on a white background and it's
much more readable:
if &background == "dark"
hi Comment term=bold ctermfg=Cyan guifg=#80a0ff
hi Constant term=underline ctermfg=Magenta guifg=#ffa0a0
hi Special term=bold ctermfg=LightRed guifg=Orange
hi Identifier term=underline cterm=bold ctermfg=Cyan guifg=#40ffff
hi Statement term=bold ctermfg=Yellow guifg=#ffff60 gui=bold
hi PreProc term=underline ctermfg=LightBlue guifg=#ff80ff
hi Type term=underline ctermfg=LightGreen guifg=#60ff60 gui=bold
hi Ignore ctermfg=black guifg=bg
else
hi Comment term=bold ctermfg=DarkCyan guifg=Blue
hi Constant term=underline ctermfg=DarkBlue guifg=Magenta
hi Special term=bold ctermfg=DarkRed guifg=SlateBlue
hi Identifier term=underline ctermfg=DarkGreen guifg=DarkCyan
" hi Statement term=bold ctermfg=DarkMagenta gui=bold guifg=Brown
hi Statement term=bold ctermfg=DarkMagenta guifg=Brown
hi PreProc term=underline ctermfg=Brown guifg=Purple
" hi Type term=underline ctermfg=DarkGreen guifg=SeaGreen gui=bold
hi Type term=underline ctermfg=DarkGreen guifg=SeaGreen
hi Ignore ctermfg=white guifg=bg
endif
hi Error term=reverse ctermbg=Red ctermfg=White guibg=Red guifg=White
hi Todo term=standout ctermbg=Yellow ctermfg=Black guifg=Blue guibg=Yellow
highlight link Typedef Special
highlight link StorageClass Special
Insert in ~/.vim/syntax.vim and make sure your ~/.vimrc has:
if has("syntax")
let mysyntaxfile = "~/.vim/syntax.vim"
let myscriptsfile = "~/.vim/scripts.vim"
let myfiletypefile = "~/.vim/filetype.vim"
syntax on
endif
--
Typed slowly for those who cannot read fast.
Christian Fromme
> I'm still missing the incentive. Joey Hess wrote in his earlier message
> that "It's now only marginally larger than nvi". It achieves that by
> removing many of the features that distinguish vim from nvi, to the
> point that my guess is that most of those who prefer vim will need to
> install the full vim anyway, while those that prefer nvi will just fell
> vaguely dissastified by the change. If the result of this is that a)
> base is not smaller, and b) vim users still have to install vim-nottiny,
> and c) nvi users now have to install nvi, I don't think it's a net win.
As much as I personally prefer vim, I feel your arguments a) b) and c) are the
strongest I've read so far in this thread and therefore I also have to agree
on the conclusion: Keep nvi as default.
Cheers,
Christian
Jeroen van Wolffelaar
> On 20.12. 08:36, Steve Greenland wrote:
>
> > I'm still missing the incentive. Joey Hess wrote in his earlier message
> > that "It's now only marginally larger than nvi". It achieves that by
> > removing many of the features that distinguish vim from nvi, to the
> > point that my guess is that most of those who prefer vim will need to
> > install the full vim anyway, while those that prefer nvi will just fell
> > vaguely dissastified by the change. If the result of this is that a)
> > base is not smaller, and b) vim users still have to install vim-nottiny,
> > and c) nvi users now have to install nvi, I don't think it's a net win.
>
> As much as I personally prefer vim, I feel your arguments a) b) and c) are the
> strongest I've read so far in this thread and therefore I also have to agree
> on the conclusion: Keep nvi as default.
I don't think it's easily possible to count on people contributing to
this thread to be representative, but I do think (b) is certainly less
than it seems: Even vim-tiny would I think be liked more than nvi --
because vim-tiny invoked as 'vim' can be configured easily to be pretty
much like the real vim, only lacking such features as systax hilighting
which you can do without easily, if you're working on a small-editor
environment. Looking at popcon, vim has about twice the amount of users
as nvi, while nvi is the default vi, and vim is merely optional.
I think this is an excellent question to phrase with a few options in a
devotee-poll, and have people vote on it -- results being purely
advisory, the poll just being informative, and any results updated live,
rather than only after a delay. I think it'd be good to representative
polls on a reasonably regularly basis -- close to the same
representativeness, and stil much much more lighter than a GR, so easier
to just do when some people feel a more clear idea of what the average
DD thinks is needed than what one can gather from a mailinglist thread.
--Jeroen
--
Jeroen van Wolffelaar
Jer...@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Stefano Zacchiroli
> > base is not smaller, and b) vim users still have to install vim-nottiny,
> > and c) nvi users now have to install nvi, I don't think it's a net win.
> As much as I personally prefer vim, I feel your arguments a) b) and c) are the
> strongest I've read so far in this thread and therefore I also have to agree
> on the conclusion: Keep nvi as default.
Your conclusion is of course to be considered as all the others.
Still, we already discussed that (b) is not true: vim users will be
happier with vim-tiny than with vim even without
vim-nottiny/vim-runtime.
Since my feeling is that we have more vim users than nvi ones,
installing the former instead of the latter per default is a net win.
Assuming my feeling is correct of course ...
Riku Voipio
While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit
scary for a base package. While we do not have requirements of base
packages of being easily buildable, changing to vim-tiny will make bootstrapping
a basic debian system again a little bit harder.
nvi:
Build-Depends: debhelper, libncurses5-dev
vs
vim-tiny:
Build-Depends: debhelper (>= 4.2.21), dpkg (>> 1.7.0), bzip2, perl (>= 5.6), libgpmg1-dev [!hurd-i386] | not+linux-gnu, libperl-dev (>= 5.6), tcl8.4-dev [!hurd-i386] | tcl8.3-dev [!hurd-i386], python-dev, libncurses5-dev, ruby, ruby1.8-dev | ruby-dev, libgtk2.0-dev (>= 2.2) | libgtk1.2-dev, libgnomeui-dev [!hurd-i386], lesstif2-dev
Joey Hess
> I don't think it's easily possible to count on people contributing to
> this thread to be representative, but I do think (b) is certainly less
> than it seems: Even vim-tiny would I think be liked more than nvi --
So do I. As others have said, vim users can run vim-tiny and type text
without constantly having to delete their acciental hjkl and strangely
uppercased characters. Compared to that, not having syntax highlighting
when I run visudo is pretty minor.
--
see shy jo
Jeroen van Wolffelaar
holding polls like this -- the discussion on holding polls is not
technical, so does not belong to -devel. For opinions on nvi versus vim,
please reply elsewhere in the current thread, this subthread isn't the
place for it)
For the full discussion leading up to this, please start at
http://lists.debian.org/debian-devel/2005/12/msg00796.html
To repeat myself from
http://lists.debian.org/debian-devel/2005/12/msg01066.html:
On Wed, Dec 21, 2005 at 03:45:51PM +0100, Jeroen van Wolffelaar wrote:
] I don't think it's easily possible to count on people contributing to
] this thread to be representative, [...] Looking at popcon, vim has
] about twice the amount of users as nvi, while nvi is the default vi,
] and vim is merely optional.
]
] I think this is an excellent question to phrase with a few options in a
] devotee-poll, and have people vote on it -- results being purely
] advisory, the poll just being informative, and any results updated live,
] rather than only after a delay. I think it'd be good to representative
] polls on a reasonably regularly basis -- close to the same
] representativeness, and stil much much more lighter than a GR, so easier
] to just do when some people feel a more clear idea of what the average
] DD thinks is needed than what one can gather from a mailinglist thread.
Because this is certainly not the first time I was curious on the
opinion of the so called "Silent majority" (if such beast exists at
all), I decided to simply try out this idea. Therefore, I've set
up devotee (thanks to Manoj for writing it!) on jeroe...@debian.org,
with results updated near realtime on
http://master.debian.org/~jeroen/polls/. To participate in the context
of the nvi vs vim-tiny discussion, please fill in the below ballot, sign
it, and submit it to jeroe...@debian.org. It's currently only
available to DD's, for practical reasons more than for any fundamental
reason -- being a poll, I do think that opinions of non-DD's is
certainly good to have too, possibly simply both tallied for DD only and
for 'all'.
This polling thingy works just like a "real" vote, except:
- It is a poll, a query to the opinion of people.
- As such, results will be public,
- and updated in near realtime
- There is no real deadline per se, as this is not intended as a
decision making instrument, at best a decision-making support
instrument. Some polls will simply stop being relevant at some point,
or maybe will remain of continued relevance.
I'm curious how this pans out.
I intend to launch more polls when I get good idea's to hold one, so
let me know if you have one.
<BALLOT>
(Also found on http://master.debian.org/~jeroen/polls/vi/ballot)
This is an informal poll, conducted with DeVoteE much like the way GR's and
elections are done.
Do not erase anything between the lines below and do not change the
choice names.
Please fill in, and send to jeroe...@debian.org.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
f811dfe7-4e13-423c-8062-8dae621caf0c
[ ] Choice 1: Keep nvi as the default vi in base
[ ] Choice 2: Replace nvi by vim-tiny
[ ] Choice 3: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
</BALLOT>
Glenn Maynard
> (Please followup to -project if you're replying on the subject of
> opinion of the so called "Silent majority" (if such beast exists at
> all), I decided to simply try out this idea. Therefore, I've set
I have no sympathy for the notion of a "silent majority". If you have an
opinion, speak it. What I believe we we really have, most of the time,
is a vocal minority trying to inflate their ranks with a non-existant
"silent majority".
> up devotee (thanks to Manoj for writing it!) on jeroe...@debian.org,
> with results updated near realtime on
> http://master.debian.org/~jeroen/polls/. To participate in the context
> of the nvi vs vim-tiny discussion, please fill in the below ballot, sign
> it, and submit it to jeroe...@debian.org. It's currently only
> available to DD's, for practical reasons more than for any fundamental
> reason -- being a poll, I do think that opinions of non-DD's is
> certainly good to have too, possibly simply both tallied for DD only and
> for 'all'.
Voting on decisions is always disturbing to me: it always seems to be
small steps away from the point where decisions are made based on
uninformed popularity rather than technical merit. Too often, in various
contexts, I've seen people who had an ill-formed opinion and losing an
argument demand a vote, in the hopes that there will be more people who
will vote for that opinion based on what seems "obvious" than those
spending the time to understand the issue. This remains a problem
regardless of how loudly one asserts that a poll is "not a decision
making instrument".
That's the general case, of course--this issue is simple enough that
it could be summarized neatly within the poll, I think. I have to
wonder how many people will vote for nvi bacause "nvi is more like
regular vi than vim". This is important even for an "informal" poll;
a vote is useless if it's heavily skewed, whether it's a poll or a GR.
- vim-tiny is not much bigger than nvi (numbers?)
- even vim-tiny is much preferable to vim users over nvi, even without
vim-runtime
- vim can behave just like old vi (as nvi does), and will do so when
invoked as "vi"
I think a poll might be a lot more useful if it was required that people
had to offer, in a sentence or two, their rationale for their vote. If
you can't even express in brief terms why you think nvi or vim should
be the default, then your opinion is not interesting; and it would let
people get an idea if a lot of people are voting based on rationale
that has been discussed and disproven (eg. "vim is huge" and "vim
differs too much from vi").
(I wish people had to write a few paragraphs justifying their votes
for government elections. Votes in essay format. One can dream ...)
--
Glenn Maynard
MJ Ray
> I have no sympathy for the notion of a "silent majority". If you have an
Hard if you can't hear the question above the NOISE.
> wonder how many people will vote for nvi bacause "nvi is more like
> regular vi than vim". This is important even for an "informal" poll;
I think that will be dwarfed by the "we love vim" effect.
> a vote is useless if it's heavily skewed, whether it's a poll or a GR.
>
> - vim-tiny is not much bigger than nvi (numbers?)
Current unstable Installed-Size:
vim-tiny ranges from 696 to 1852 with a median of 898k.
nvi ranges from 560 to 1040 with a median of 648k
vim-tiny depends on the 200k-ish vim-common too, so nvi seems
about half the total size of a vim-tiny today.
> - even vim-tiny is much preferable to vim users over nvi, even without
> vim-runtime
> - vim can behave just like old vi (as nvi does), and will do so when
> invoked as "vi"
- vim-tiny is on fewer platforms than nvi, which seems as
important as size or accuracy of emulation.
--
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
Lionel Elie Mamane
> While I'm a addicted vim user, the build-dependencies of vim(-tiny)
> is a bit scary for a base package. While we do not have requirements
> of base packages of being easily buildable, changing to vim-tiny
> will make bootstrapping a basic debian system again a little bit
> harder.
Urgh. Yes. Until now I was in favour of vim-tiny, but these build-deps
are just too scary. Unless we put vim-tiny in another source package,
I guess we'd better stick with nvi.
--
Lionel
Steve Greenland
> Current unstable Installed-Size:
> vim-tiny ranges from 696 to 1852 with a median of 898k.
> nvi ranges from 560 to 1040 with a median of 648k
"Ranges"? Over what? Architectures?
> vim-tiny depends on the 200k-ish vim-common too, so nvi seems
> about half the total size of a vim-tiny today.
Okay, so that's not "about the same". Stefano? If the above numbers are
correct, then the best case is a (696+200-560)==336K increase. Last I
heard, the CD builders considered that a non-trivial amount of space. Or
am I confusing the boot image with base?
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Glenn Maynard
> - vim-tiny is on fewer platforms than nvi, which seems as
> important as size or accuracy of emulation.
Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
build, but it won't run on all of the platforms Debian supports?
--
Glenn Maynard
MJ Ray
> On Wed, Dec 21, 2005 at 10:11:14PM +0000, MJ Ray wrote:
> > - vim-tiny is on fewer platforms than nvi, which seems as
> > important as size or accuracy of emulation.
>
> Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
> build, but it won't run on all of the platforms Debian supports?
Who knows? It's not currently built for as many. For hurd-i386,
hppa and s390, nvi is a working editor and vim-tiny isn't. I
can't remember what counts as support right now (URL anyone?)
That's an incentive for nvi over vim-tiny, but nvi is the
current anyway and I don't see many benefits of a change.
The -devel thread seems to have started with two dubious
claims: that vim-tiny isn't much bigger and more prefer vim.
I've questioned the size claim in another subthread and
surely vim users won't be satisfied by vim-tiny.
Please cc me on replies.
Thanks,
--
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
MJ Ray
> On 21-Dec-05, 16:11 (CST), MJ Ray <m...@phonecoop.coop> wrote:
> > Current unstable Installed-Size:
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> "Ranges"? Over what? Architectures?
Yes, architectures.
> > vim-tiny depends on the 200k-ish vim-common too, so nvi seems
> > about half the total size of a vim-tiny today.
>
> Okay, so that's not "about the same". Stefano? If the above numbers are
> correct, then the best case is a (696+200-560)==336K increase. Last I
> heard, the CD builders considered that a non-trivial amount of space. Or
> am I confusing the boot image with base?
The increase is between 101% for ia64 and 58% for i386.
vim-tiny+vim-common is smallish by current standards, but
neither "about the same" as nvi, nor "only marginally larger".
Was there a maths error near the top of this thread?
Workings (rounded down, to be generous):
nvi alpha 328.6 760
vim-tiny alpha 471 1072
vim-common alpha 79.9 232
=total alpha 550.9 1304
CHANGE alpha +67% +71%
nvi amd64 288.3 668
vim-tiny amd64 433.1 900
vim-common amd64 79.5 232
=total amd64 512.6 1132
CHANGE amd64 +77% +69%
nvi arm 270.3 600
vim-tiny arm 376.4 760
vim-common arm 79.2 228
=total arm 455.6 988
CHANGE arm +68% +64%
nvi i386 281.4 632
vim-tiny i386 368.4 776
vim-common i386 78.8 228
=total i386 447.2 1004
CHANGE i386 +58% +58%
nvi ia64 390.2 1040
vim-tiny ia64 687 1852
vim-common ia64 82 240
=total ia64 769 2092
CHANGE ia64 +97% +101%
nvi m68k 255.6 560
vim-tiny m68k 339.5 696
vim-common m68k 78.3 228
=total m86k 417.8 924
CHANGE m68k +63% +65%
nvi mips 302.7 824
vim-tiny mips 457.3 1200
vim-common mips 79.2 232
=total mips 536.5 1432
CHANGE mips +77% +73%
nvi mipsel 302.4 824
vim-tiny mipsel 457.5 1200
vim-common mipsel 79.2 232
=total mipsel 536.7 1432
CHANGE mipsel +77% +73%
nvi powerpc 289.3 648
vim-tiny powerpc 408.8 896
vim-common powerpc 79.1 228
=total powerpc 487.9 1124
CHANGE powerpc +68% +73%
nvi sparc 272.6 628
vim-tiny sparc 376.4 804
vim-common sparc 78.9 228
=total sparc 455.3 1032
CHANGE sparc +67% +64%
no vim-tiny for:
nvi hppa 302.6 652
nvi hurd-i386 281.4 632
nvi s390 285.1 648
Hope that helps and please cc me on replies,
--
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
Glenn Maynard
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)
I'll have to punt on that one, since I know nothing about those
platforms and why vim might not work on them. I can't imagine it's
anything major if those are viable platforms at all, though.
> That's an incentive for nvi over vim-tiny, but nvi is the
> current anyway and I don't see many benefits of a change.
> The -devel thread seems to have started with two dubious
> claims: that vim-tiny isn't much bigger and more prefer vim.
> I've questioned the size claim in another subthread and
> surely vim users won't be satisfied by vim-tiny.
I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
and Joey Hess), and not one person so far has actually said they prefer
nvi over vim--just that they prefer its defaults, which has been
addressed. I don't know how you can possibly call the claim that more
prefer vim over nvi "dubious"; it's a pretty clear-cut one.
It seems like a mindset I've seen elsewhere: "if you can't get 100%,
settle for 0%". I'm 75% with vim-tiny, 95% if I'm not programming
(which I'm probably not, if vim-tiny is installed), and 0% with nvi,
and one doesn't always have the ability to install packages.
> Please cc me on replies.
This is the only time I'll do so, to remind you to set Mail-Followup-To.
It's your job to set headers expressing your preferences (which you
only have to do once, in your mailer configuration), not everyone else's
job to manually set your CC every time. (You've been on these lists for
quite a while; I'm pretty sure you know this ...)
--
Glenn Maynard
Russ Allbery
> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
> nvi over vim--just that they prefer its defaults, which has been
> addressed.
Just to be completely unambiguous about my earlier message, I do indeed
prefer nvi over vim, regardless of how vim is configured. It's smaller
and it does what I expect, which neither vim in its default mode nor vim
in its compatible mode does.
Also, I prefer not to have to configure my vi to behave like vi, but maybe
that will be changed. It's not a matter of just configuring it on one
host, like it is with XEmacs. I only use XEmacs for major editing and can
customize it extensively on the small handful of systems that I use all
the time. I use vi for routine system administration, configuration file
editing, and all small edits, and I use it on a ton of different Debian
machines from a variety of different accounts that don't all share a
single configuration or set of home directories. (I realize that other
people feel the same way about vim. I'm just stating a personal
preference, not arguing that other people's preferences are wrong.)
On the other hand, I don't consider it a major issue and can live with
whatever decision people come to, which is why I voted both alternatives
above further discussion in the straw poll experiment. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Joey Hess
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)
Oh, come on. vim-tiny entered the archive this week. The fact that we
have some slow buildds and ports like hurd-i386 that are perennially
behind is irrelevant to this discussion unless you can point to a build
failure log.
--
see shy jo
Joey Hess
> Okay, so that's not "about the same". Stefano? If the above numbers are
> correct, then the best case is a (696+200-560)==336K increase. Last I
> heard, the CD builders considered that a non-trivial amount of space. Or
> am I confusing the boot image with base?
Anything over a kilobyte matters for certian d-i boot images.
Anything under a half megabyte is pretty much noise for CD building. And
vim is already on the main CD anyway due to its popularity.
I would not have proposed replacing nvi with vim-tiny if it were not
fully technically feasable.
(BTW, spot the 7 mb package that entered standard recently with no prior
discussion.)
--
see shy jo
Joey Hess
> The increase is between 101% for ia64 and 58% for i386.
> vim-tiny+vim-common is smallish by current standards, but
> neither "about the same" as nvi, nor "only marginally larger".
> Was there a maths error near the top of this thread?
The very top of this thread contained a forwarded message containing the
text "(776 + 232 on i386)". If you're trying to imply some sort of error
it might help if you pointed to a message-id.
--
see shy jo
Joey Hess
> While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit
> scary for a base package. While we do not have requirements of base
> packages of being easily buildable, changing to vim-tiny will make bootstrapping
> a basic debian system again a little bit harder.
As far as I know, bootstrapping Debian from scratch is a process of
getting the build-essential packages and their build dependencies to
build and then building everything else. What packages are in the base
system should be irrelevant to that process.
--
see shy jo
Anthony Towns
> On Wed, Dec 21, 2005 at 10:11:14PM +0000, MJ Ray wrote:
> > - vim-tiny is on fewer platforms than nvi, which seems as
> > important as size or accuracy of emulation.
> Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
> build, but it won't run on all of the platforms Debian supports?
vim's failing to build on sparc and arm, at least, with the following
error after compiling while trying to build the package:
cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory
Cheers,
aj
Anthony Towns
On Wed, Dec 21, 2005 at 10:11:14PM +0000, MJ Ray wrote:
> Current unstable Installed-Size:
> vim-tiny ranges from 696 to 1852 with a median of 898k.
> nvi ranges from 560 to 1040 with a median of 648k
vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
downgrading that dependency a possibility, so base could include the
regular vim binary plausible?
As long as the size increase is /reasonably/ small, it's not a problem;
and vim already seems to be on CD#1 anyway.
Cheers,
aj
MJ Ray
> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
I strongly prefer nvi over vim. I dislike vim enough to
install vile when I need a bigger vi than nvi. Last I tried
(albeit many moons ago), vim's vi-compatible mode wasn't and
there seemed little interest in bug reports (attitude of: How
can you not prefer vim? Run vim and all will be well. Love vim.)
AFAICT, Lars Wirzenius and Andrew M A Cater told similar things.
I guess you don't count them for some reason. So, we'll wait
for data on preferences and the size thing seems clear anyway.
[...]
> > Please cc me on replies.
>
> This is the only time I'll do so, to remind you to set Mail-Followup-To.
> It's your job to set headers expressing your preferences [...]
MFT is conceptually broken non-standard DJB-ware, but let's not
have this debate again. If you're using mutt, I'm just asking
you to use g instead of l to reply, not hack headers - you
might like to bugfix mutt to support List-* if it still doesn't.
My request was as suggested by
http://www.debian.org/MailingLists/#codeofconduct
so please honour it.
Thanks,
--
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
Jon Dowland
> su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
> > We already have two editors in the base system, nvi and nano.
>
> Yes, that being the bloat I was referring to.
I think there should be at least one non-modal editor in base.
--
Jon Dowland
http://alcopop.org/
Lars Wirzenius
> On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote:
> > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
> > > We already have two editors in the base system, nvi and nano.
> >
> > Yes, that being the bloat I was referring to.
>
> I think there should be at least one non-modal editor in base.
Behold the awesome non-modality of nano.
--
Boilerplate programming mean tools lack power.
Henning Makholm
> to, 2005-12-22 kello 10:20 +0000, Jon Dowland kirjoitti:
>> On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote:
>> > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti:
>> > > We already have two editors in the base system, nvi and nano.
>> > Yes, that being the bloat I was referring to.
>> I think there should be at least one non-modal editor in base.
> Behold the awesome non-modality of nano.
Yes; therefore it is not bloat to have nvi and nano both in base; they
satisfy different needs (having a vi because we're unix resp. having a
non-modal editor for the rest of us).
--
Henning Makholm "There is a danger that curious users may
occasionally unplug their fiber connector and look
directly into it to watch the bits go by at 100 Mbps."
Stefano Zacchiroli
> > vim-tiny depends on the 200k-ish vim-common too, so nvi seems
> > about half the total size of a vim-tiny today.
> Okay, so that's not "about the same". Stefano? If the above numbers are
If this is some kind of insinuation, ... well, I'm kind of pissed-off by
it. I never used the expression "about the same". Joey forwarded a post
of mine containing the verbatim words:
The installed-size of it and of vim-common are as I anticipated (776
+ 232 on i386);
[ vim-common is now some Kb smaller, but this is not relevant here ]
In the very same post Joey correctly added:
It's now only marginally larger than nvi
Thus, no one of the proposer speaked of something "about the same".
> correct, then the best case is a (696+200-560)==336K increase. Last I
> heard, the CD builders considered that a non-trivial amount of space. Or
> am I confusing the boot image with base?
I asked Joey, as one of the installer maintainer, and for him the size
increase is not a problem. If it is a problem for the CD builders, they
can speak in this thread. If it is not a problem for these people, why
is it a problem for you?
Stefano Zacchiroli
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> downgrading that dependency a possibility, so base could include the
> regular vim binary plausible?
The philosophy in the packaging has been:
* vim-tiny -> has smaller as possible version of vim
* vim -> ordinary vim
vim-tiny has thus been compiled with a small subset of features _and_
minimizing dependencies. vim with a standard set of features without
caring about dependencies.
I don't like downgrading the vim -> vim-runtime dependency since IMO if
a user apt-get-installs vim he expect a fully working vim installation
(including help and syntax highlighting).
If there's the need of more vim features in the standard installation I
would rather prefer to tune vim-tiny compilation including more
features. On this subject, please note that adding gpm support will
trigger the additional libgpmg1 dependency.
Cheers.
Andreas Metzler
> While I'm a addicted vim user, the build-dependencies of vim(-tiny)
> is a bit scary for a base package. While we do not have requirements
> of base packages of being easily buildable, changing to vim-tiny
> will make bootstrapping a basic debian system again a little bit
> harder.
> nvi:
> Build-Depends: debhelper, libncurses5-dev
> vs
> vim-tiny:
> Build-Depends: debhelper (>= 4.2.21), dpkg (>> 1.7.0), bzip2, perl (>= 5.6), libgpmg1-dev [!hurd-i386] | not+linux-gnu, libperl-dev (>= 5.6), tcl8.4-dev [!hurd-i386] | tcl8.3-dev [!hurd-i386], python-dev, libncurses5-dev, ruby, ruby1.8-dev | ruby-dev, libgtk2.0-dev (>= 2.2) | libgtk1.2-dev, libgnomeui-dev [!hurd-i386], lesstif2-dev
As Joey already remarked moving vim to base has no effect on
bootstrapping, because it does change _when_ in the process vim is
built.
However, the nvi is evidently a lot simpler than vim and less likely
both to show from rc-bugs to suffer from being kept out of testing due
to rc-bugs in its build-depencies. This might make a difference the
base-freeze slightly more difficult.
cu andreas
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken. (c) Jasper Ffforde
Andreas Metzler
[...]
> bootstrapping, because it does change _when_ in the process vim is
not
MJ Ray
> [...] In the very same post Joey correctly added:
> It's now only marginally larger than nvi [...]
167% is a rather big margin, isn't it?
> I asked Joey, as one of the installer maintainer, and for him the size
> increase is not a problem. If it is a problem for the CD builders, they
> can speak in this thread. If it is not a problem for these people, why
> is it a problem for you?
If one is honest and says that vim-tiny will replace nvi because
the decision-makers prefer it, then that's fine, but this
doesn't look like a technically-based decision. It doesn't
seem supported by current data to claim that vim-tiny isn't
a real size increase, or that this doesn't mean most vi users
(both vim-fans and vim-haters) will want to install another vi
besides the default one.
Are there many vi users who will just use vim-tiny?
Most "small vi" users don't seem to like vim, IME.
--
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask
Anthony Towns
> On Thu, Dec 22, 2005 at 03:43:14PM +1000, Anthony Towns wrote:
> > > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > > nvi ranges from 560 to 1040 with a median of 648k
> > vim itself is only ~600kB, ignoring its dependency on vim-runtime; is
> > downgrading that dependency a possibility, so base could include the
> > regular vim binary plausible?
> The philosophy in the packaging has been:
> * vim-tiny -> has smaller as possible version of vim
> * vim -> ordinary vim
> vim-tiny has thus been compiled with a small subset of features _and_
> minimizing dependencies. vim with a standard set of features without
> caring about dependencies.
Hrm, I see the figures above are mixing .deb and installed sizes too. The
deb sizes are nvi=288k, vim-tiny=377k, vim=570k.
> I don't like downgrading the vim -> vim-runtime dependency since IMO if
> a user apt-get-installs vim he expect a fully working vim installation
> (including help and syntax highlighting).
Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
Or would vim-basic really not run without the stuff in -runtime? (If the above
means vim becomes an empty package, moving the stuff from vim-runtime into it
might be feasible/worthwhile)
> If there's the need of more vim features in the standard installation I
> would rather prefer to tune vim-tiny compilation including more
> features. On this subject, please note that adding gpm support will
> trigger the additional libgpmg1 dependency.
libgpmg1 is already in standard, and is 50k of .deb.
Cheers,
aj
Eric Dorland
> As you can see below and in the BTS, vim's maintainer has managed to
> create a vim-tiny package that is vim without some of the extras such as
> syntax highlighting. It's now only marginally larger than nvi, which is
> the standard vi included in the base system (amazingly, it's smaller
> than nano, the other editor in the base system). Stefano suggested that
> vim-tiny could replace nvi and become part of base, and I think it's a
> good idea.
>
> There are obviously users who will prefer nvi to vim (and others who
> prefer some other vi), but I get the impression there are rather more who
> prefer vim, it's probably the most commonly used vi in linux these days.
>
> One argument I can think of for keeping nvi in base is that it is the
> closest to bug-compatible with the original vi. However, I don't think
> that will prevent hardcore vi users from easily using vim-tiny if
> it's in base.
Another good reason for doing this is that for basically every Linux
user I've encountered, vi == vim. When I tell non-Debian users that
Debian ships with something called nvi instead of vim by default, they
shake their heads and disbelief and next words out of their mouths
either make fun of Debian, or make fun of me (*snif*).
Now we don't necessarily have to pander to these people, but this
change is the sort of thing that will help the change perception of
Debian for people who think we're a bunch of crazies.
--
Eric Dorland <er...@kuroneko.ca>
ICQ: #61138586, Jabber: ho...@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+
G e h! r- y+
------END GEEK CODE BLOCK------
Anthony Towns
> Stefano Zacchiroli <za...@debian.org>
> > [...] In the very same post Joey correctly added:
> > It's now only marginally larger than nvi [...]
> 167% is a rather big margin, isn't it?
Depends what it's a percentage of; if it were a percentage of all of base,
sure; but it's not, it's a percentage of nvi.
> If one is honest and says that vim-tiny will replace nvi because
> the decision-makers prefer it,
One doesn't need to be honest to say that, merely tautological: yes,
decisions happen when decision makers decide.
> Are there many vi users who will just use vim-tiny?
> Most "small vi" users don't seem to like vim, IME.
I prefer nvi because of the default vim configuration issues discussed
earlier; autoindenting while pasting in particular is annoying. With
that fixed, I'd be happy to have vim be the default vi on my system,
and would tend to do that, since some of my users strenuously prefer
having vim around.
Cheers,
aj
Stefano Zacchiroli
> > I don't like downgrading the vim -> vim-runtime dependency since IMO if
> > a user apt-get-installs vim he expect a fully working vim installation
> > (including help and syntax highlighting).
> Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
> include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
No, it is not of course. I don't have any particular objection on such
approach.
> Or would vim-basic really not run without the stuff in -runtime? (If the above
> means vim becomes an empty package, moving the stuff from vim-runtime into it
> might be feasible/worthwhile)
Yes, it would run, as vim-tiny runs now. No help (just a dummy page
explaining what's going on), no syntax, .... But it would run. vim will
become an empty package indeed, but I don't think that would be a
problem.
> > If there's the need of more vim features in the standard installation I
> > would rather prefer to tune vim-tiny compilation including more
> > features. On this subject, please note that adding gpm support will
> > trigger the additional libgpmg1 dependency.
> libgpmg1 is already in standard, and is 50k of .deb.
Ok, not a problem then.
But still, people have complained in this thread about a size increase
of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
vim-common would mean an *additional* 340 Kb size increase. Is this
still considered a fair increase by the installer/cd teams?
Paul Hedderly
>
> I'm one of the people who prefers nvi over vim. I do so quite strongly,
> because I find that nvi obeys my fingers and vim does not. The
Sounds like you should file a bug against your fingers then.
> differences are minute, of course, but they are really irritating.
> Unfortunately, I can't enlist them properly, since my fingers don't talk
> to me: I notice vim's incompatibility from the fact that my fingers have
If your fingers aren't talking to you, perhaps you should also list them
as MIA.
> to keep correcting text under vim, but not under nvi. On days when I'm
> generally annoyed already, if I accidentally use vim instead of nvi, I
> can get quite lyrical with my cursing.
Funny - on days I'm generally annoyed already and I end up on a machine
with nvi as the default vi... I can get quite lyrical with my ranting.
For me, vim-tiny would be great!
--
Paul
Paul Hedderly
>
> Yeah; vi not behaving like vi by default seems like a showstopper.
But that is not the case. vi by default not acting like a very old and
(imho) broken version of vi... is not a showstopper.
I love vi - and I love the progress vim has made to make use of vi
quicker/better/easier. I don't see that the world has to be stuck in
1985 - should we still be shipping a linux kernel version 1?
Joey Hess
> But still, people have complained in this thread about a size increase
> of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
> vim-common would mean an *additional* 340 Kb size increase. Is this
> still considered a fair increase by the installer/cd teams?
I don't know that adding that 340k to the installed size of base or the
corresponding 188k to the size of the debs would be too much[1], but the
gain of going from vim-tiny to vim(minus -runtim) seems more marginal to
me.
--
see shy jo
[1] It's hard to say for sure since the i386 netinst CD is already too
big for some installation methods and we haven't figured out if
we're going to trim it back down, or drop it.
Glenn Maynard
> On Sun, Dec 18, 2005 at 08:56:42PM +0200, Lars Wirzenius wrote:
> >
> > I'm one of the people who prefers nvi over vim. I do so quite strongly,
> > because I find that nvi obeys my fingers and vim does not. The
>
> Sounds like you should file a bug against your fingers then.
>
> > differences are minute, of course, but they are really irritating.
> > Unfortunately, I can't enlist them properly, since my fingers don't talk
> > to me: I notice vim's incompatibility from the fact that my fingers have
>
> If your fingers aren't talking to you, perhaps you should also list them
> as MIA.
Finger habits are hard to change, especially for an editor like vi. Ridicule
is unwarranted.
--
Glenn Maynard
Steve McIntyre
>
>[1] It's hard to say for sure since the i386 netinst CD is already too
> big for some installation methods and we haven't figured out if
> we're going to trim it back down, or drop it.
Ouch. I'd hope that the netinst should still work. As/when/if we can
drop 2.4 kernels then we should get some space back.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Anthony DeRobertis
> Yeah; vi not behaving like vi by default seems like a showstopper.
I don't understand why. Debian is a GNU/Linux system, not a UNIX system.
Even such simple things as our "echo" command do not behave exactly as
POSIX dictates and classic UNIX does; we've generally, I think, told
tradition to go take a hike when faced with the choice of "better" vs.
"traditional."
Why should vi be any different? If we have a better alternative, replace it.
[Appologies if this message comes dangerously close to starting an
editor war]
Anthony Towns
> On Fri, Dec 23, 2005 at 12:40:40PM +1000, Anthony Towns wrote:
> > > I don't like downgrading the vim -> vim-runtime dependency since IMO if
> > > a user apt-get-installs vim he expect a fully working vim installation
> > > (including help and syntax highlighting).
> > Right; but having vim Depends: vim-basic, vim-runtime; and having vim-basic
> > include /usr/bin/vim from current vim.deb doesn't seem terribly difficult?
> No, it is not of course. I don't have any particular objection on such
> approach.
The advantage is one less version of vim to maintain, and that people
who install the full featured vim don't need to keep a pointless copy of
/usr/bin/vim.tiny. *shrug* perl-base / perl is in a similar situation;
note that with vim-tiny (in whatever form) in base, it probably makes
sense to include vim-runtime as standard too.
> But still, people have complained in this thread about a size increase
> of about 370 Kb (nvi vs vim-tiny + vim-common), moving towards vim +
> vim-common would mean an *additional* 340 Kb size increase. Is this
> still considered a fair increase by the installer/cd teams?
I think the size increase complaints (at least so far) have all been
standing in for when people just want to say "I prefer nvi". The size of
base matters a little, but it's not an "every byte is sacred" situation.
Cheers,
aj (base maintainer, for those playing along at home)
Osamu Aoki
Since I have not seem posting from Miquel...
For this discussion of "Which editor should be installed as default on`
the each Debian system?", I think more technical discussion should be
done. This is old topic. We can always install nano, nvi or vim-* later
as you wish by "sudo aptitude install <your-editor>" :-)
(Disclaimer: I use vim exclusively.)
> From: Stefano Zacchiroli <za...@debian.org>
> Hi Joey, vim-tiny is available in debian/unstable. There are still some
> minor bugs, but the package is fine. The installed-size of it and of
> vim-common are as I anticipated (776 + 232 on i386); the only additional
> dependencies are libc6 and libncurses5.
Well is this small? By the way, we should also check nano too.
Let me review some status of small editors. (Listed by the size)
Package: elvis-tiny
Priority: optional
Installed-Size: 148
Maintainer: Miquel van Smoornburg <miq...@cistron.nl>
Version: 1.4-20
Pre-Depends: libc6 (>= 2.3.2.ds1-21), libncurses5 (>= 5.4-1)
Size: 46090
Package: nano-tiny
Priority: optional
Installed-Size: 220
Source: nano
Version: 1.3.9-1
Depends: libc6 (>= 2.3.5-1), libslang2 (>= 2.0.1-1)
Size: 138512
Package: nvi
Priority: important
Installed-Size: 632
Version: 1.79-22
Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1)
Size: 288166
Package: vim-tiny
Priority: optional
Installed-Size: 776
Version: 1:6.4-006+1
Depends: vim-common (= 1:6.4-006+1), libc6 (>= 2.3.5-1), libncurses5 (>= 5.4-5)
Size: 377374
Package: vim-common
Priority: optional
Section: editors
Installed-Size: 228
Version: 1:6.4-006+1
Recommends: vim | vim-tiny
Size: 80504
--> This means vim-tiny, it took Installed-Size: 1004 and Size: 457878
Package: nano
Priority: important
Installed-Size: 1380
Version: 1.3.9-1
Depends: libc6 (>= 2.3.5-1), libncursesw5 (>= 5.4-5)
Size: 461694
So aside from vim-tiny, what we have in sid priority important, nvi and
nano, are not smallest editors for the job. From technical point, we
should chose elvis-tiny and nano-tiny. Both of these editor have
commands in /bin which is always with us. (What happens if you have NFS
mounted /usr ?)
In terms of updating editors which is installed as the default rescue
system, we should chose small ones: nano-tiny and elvis-tiny.
(elvis-tiny is another vi-clone.).
Sarge installer installs nano and nvi. I thought it was sort of
overlooked bug of installer. nano and nvi are in /usr/bin.
Cheers,
Osamu
Frans Pop
> Sarge installer installs nano and nvi. I thought it was sort of
> overlooked bug of installer. nano and nvi are in /usr/bin.
s/installer/debootstrap/
And debootstrap just installs the base system based on package
characteristics (mainly priority), so it all boils down again to the
definition of the base system.
Cheers,
FJP
Osamu Aoki
> On Saturday 24 December 2005 14:15, Osamu Aoki wrote:
> > Sarge installer installs nano and nvi. I thought it was sort of
> > overlooked bug of installer. nano and nvi are in /usr/bin.
>
> s/installer/debootstrap/
Yes, thast is more precise.
> And debootstrap just installs the base system based on package
> characteristics (mainly priority), so it all boils down again to the
> definition of the base system.
For things like editor, we can istill review priority based on the size
and technical merits.
This should lead us to make elvis-tiny and nano-tiny important while
others should stay as optional. We also have ed as important and cat is
always with us. (None of the editor need to be required either. So
removing them are also easy.)
We have system with mawk (Priority=required) but usually no gawk
(Priority=optional) nor original-awk(Priority=optional) installed. Out
of these awk variants, original-awk seems to be the smallest. Changing
this priority on awk just by size is something I do not want to see.
But we can still do that with editor.
So instead of adding more editor to our base by boosting packasge"s
priority, we should have priority set to optional for most editors exept
nano-tiny and elvis-tiny. (c)debootstrap should only install these 2
editors except talled otherwise. That is my observation.
Osamu
Thijs Kinkhorst
> Another good reason for doing this is that for basically every Linux
> user I've encountered, vi == vim. When I tell non-Debian users that Debian
> ships with something called nvi instead of vim by default, they shake
> their heads and disbelief and next words out of their mouths either make
> fun of Debian, or make fun of me (*snif*).
While I take making fun of Eric as a very serious issue, the underlying
argument is I think also an important one in this discussion: when given
the choice of compatibility with some UNIXes, or with many other Linux
distributions, it would make the most sense to me to be compatible with
the latter. Since people have installed Debian GNU/Linux, they're more
likely to expect it to be compatible with other Linuxes they've used than
with some UNIX they might have used.
Thijs
Steve Greenland
On 22-Dec-05, 12:33 (CST), Stefano Zacchiroli <za...@debian.org> wrote:
> On Wed, Dec 21, 2005 at 05:41:45PM -0600, Steve Greenland wrote:
> > > vim-tiny depends on the 200k-ish vim-common too, so nvi seems
> > > about half the total size of a vim-tiny today.
> > Okay, so that's not "about the same". Stefano? If the above numbers are
>
> If this is some kind of insinuation, ... well, I'm kind of pissed-off by
> it.
Sorry, no insinuation intended, although I see, in retrospect, how it
can be read that way; my apologies. I just used "Stefano?" to draw your
attention and ask for your comments. For all I knew, the versions being
compared were not the most current available to you.
To *me* "marginally larger" and "about the same" are pretty much
equivalent; neither applies to a 50% increase in size.
> I asked Joey, as one of the installer maintainer, and for him the size
> increase is not a problem. If it is a problem for the CD builders, they
> can speak in this thread. If it is not a problem for these people, why
> is it a problem for you?
It's not, *THAT'S WHY I ASKED!* You have to understand: I don't pay
a whole lot of attention to the who's who of Debian infrastructure
maintainers; "Joey says it's okay" simply doesn't mean as much to me
as "Joey, one of the major installer maintainers, says it's okay"
(Sorry, Joey, but there it is :-)). I am faintly aware that space
on the installer/rescue CD was precious; since vim-tiny *is* still
significantly bigger than nvi (percentage wise, at least), I wanted to
make sure that the appropriate people have been asked. Joey and you have
now said "Yes, it's fine." Terrific.
I don't care which one is in base, so long as I have a working,
non-colorized vi clone after a base install. Once I'm setup, I can
install nvi if I want.
>From this thread, I don't see any much of an argument one way or another.
Some people would rather have vim, some would rather have nvi. So long
as I can get the one I want, and remove the one I don't, it just doesn't
seem to be a big deal. Since the whole designation of "base" is basically
only useful for install/cd people, I'd let them make the decision.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Toni Mueller
Hello,
On Thu, 22.12.2005 at 17:20:42 +0100, Henning Makholm <hen...@makholm.net> wrote:
> Yes; therefore it is not bloat to have nvi and nano both in base; they
> satisfy different needs (having a vi because we're unix resp. having a
> non-modal editor for the rest of us).
I'm not used to nano, but the editor in base expected to be used for
working on system config files is imho required to respect tabs and eg.
*not* convert them to spaces unless told to do so, and also provide
means to enter new tabs.
Other than that, vim is much closer to non-modality than is nvi - you
can often stay in insert mode while using cursor and delete keys to
your heart's content.
Best,
--Toni++