Re: Bug#155376: what is default editor in /bin
Folks, thanks for the comment. Let me refocus by saying:
I retract request for "required" but insist on some non-"ed" full screen
editor in /bin should be "important". nano-tiny is a good candidate.
I will re-summarize situation and express my thought in 6 point
questions and 5 action requests. Action request (A2) is the most
important and I have not got an answer.
Background: I read:
1) This thread starting:
2) A thread about "Editor Priorities" starting: (**1)
3) A thread about "'editor' alternative policy?" ending: (**2)
Disclaimer: I am vim user.
Facts: (bs=base, ed=editors, alt#=priority for editor)
alt# program location
ed Req ae(potato) 962-26 Anthony's Editor /bin
ed 0 Opt nano-tiny 1.1.9-2 free Pico clone /bin
bs 10 Opt elvis-tiny 1.4-18 Tiny vi (provide vi) /bin
bs -100 Imp ed 0.2-19 The classic unix ed /bin
ed 40 Imp nano 1.1.10-1 free Pico clone /usr/bin
ed 19 Imp nvi 1.79-20 4.4BSD re-imple. /usr/bin
ed 120 Opt vim 6.1.048-1 Vi IMproved /usr/bin
ed 60 Opt jove 184.108.40.206-1 J's ... Emacs /usr/bin
ed 70 Opt joe 2.8-21 Joe's Own Editor /usr/bin
ed 50 Opt ee 1:1.4.2-4 easy editor /usr/bin
ed xxx Opt aee 2.2.7-2 advanced easy editor /usr/bin
ed xxx Opt emacs20 (big) 20.7-13.1 The GNU Emacs editor /usr/bin
ed -100 Opt xemacs21 21.4.8-1 Editor and ... /usr/bin
(nano-tiny-utf8 conflict with nano-tiny)
Let me itemize issues in question and put my thought on them.
Q1: Is vi (nvi|vim|..) good enough for editor in /bin?
=> It is never ending story. I am happy having elvis-tiny. But
forcing this sends wrong message as a distribution. So something
like nano which is acceptable by any vi-phobic person should be
there as a default choice during install.
Q2: Is a reasonable editor *always* available in /bin?
=> So some virtual package for editor in /bin should be available at
least as "Important" which depends on "nano-tiny|elvis-tiny|
...". (See Q4 and Q5 for case studies)
(The virtual package argument is just a indication of my
intent. I care less for how it is implemented.)
** Action request (A1): Please propose and implement a sound
technical solution. (important)
Q3: How should we ensure normal command name to invoke some reasonable
editor in /bin when /usr is not available? elvis-tiny and nano-tiny
is too much to type :)
=> This problem is solved by Miquel van Smoorenburg for elvis-tiny:
* make symlink from corresponding normal command in /bin.
/bin/vi -->/bin/elvis-tiny (normal vi is in /usr/bin )
** Action request (A2): next nano-tiny package update to create
/bin/nano --> /bin/nano-tiny (wishlist)
** Action request (A3): I will appreciate if nano-tiny-utf8 and
nano-tiny should play nice (dpkg-divert script with dhelp
This approach requires no new name to remember. Also having low
priority for "editor" for these special editors in /bin will not
affect recovery and daily editor use. We do not need it usually
when we have /usr.
Q4: How transition from ae(potato) should have happened?
=> Since "ae" was not available in woody, some smooth transition
mechanism should have been there for editor in /bin. I care less
for "Required" priority but something of this kind (nano-tiny,
elvis-tiny) should have been noticed by the sysadmin as
"Important". (It is hard to decide which one is the right one
for /bin and should be left to sysadmin's choice. Thus I
proposed virtual package idea as above). Most, including myself,
purged "ae" assuming something in "Important" replaced "ae" in
its functionality for /bin.
nvi and nano are "Important" but they could have been "Optional".
Request for "required" was not my main point and I am not pushing
for it. (responding to Santiago Vila)
Q5: What is the right "default editor on newly installed Debian"?
=> If I believe in Joey Hess <firstname.lastname@example.org>, "default editor" is
now nano (not nano-tiny). My bf2.4 installed machine is a good
I see no reason to use normal nano package which creates nano in
/usr/bin as the "default editor". It should have been nano-tiny
with symlink trick mentioned above so command is still nano for
lazy people like me.
(Possible peripheral benefits: nano may be compiled wrap line
enabled for e-mails while nano-tiny should be compiled without
wrap line. See Bug#127634, #135978, #141763, #148494. This is
just a thought and I know this may cause other problems. If top
line indicate using nano-tiny, first time install user will not
be confused .)
** Action request (A4): next 3.0r1 should use nano-tiny for
(for d-i &pgi, please consider along same line.) (normal)
** Action request (A5): next version of nano-tiny should change
title bar display from "nano" to "nano-tiny". (wishlist)
Q6: Should not (ee|aee|...) be the editor for /bin?
=> Please save this discussion for some other time :).
**1, ***2) I am happy with priorities given to editors. Anyway priority
numberfor alternative system is not issue here. That is good for
/usr/bin/???? but I am talking about /bin/???.
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki @ Cupertino CA USA
See "User's Guide": http://www.debian.org/doc/manuals/users-guide/
See "Debian reference": http://www.debian.org/doc/manuals/debian-reference/
"Debian reference" Project at: http://qref.sf.net
I welcome your constructive criticisms and corrections.