[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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   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
       message?).                                                 (wishlist)

       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 <joey@kitenet.net>, "default editor" is
       now nano (not nano-tiny). My bf2.4 installed machine is a good
       example, too.

       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.

Reply to: