On Mon, 8 May 2006, Keith M Wesolowski wrote:
On Mon, May 08, 2006 at 02:06:54PM +0300, Cyril Plisko wrote:

On 5/8/06, Brian Nitz <[EMAIL PROTECTED]> wrote:
No, it looks like I missed the obvious.  Does anyone know if there is a
reason why we can't do this?
Cyril, do you want to reopen RFE 6422494 with this proposal or should I?

Brian, please do so !

Thanks.  BTW, although the evaluation field isn't shown ([EMAIL PROTECTED]
b.o.o!), this is what I put there when closing the RFE:

---
While adding VIM to Solaris is a fine idea, replacing /usr/bin/vi with
it is not.  Also, since VIM is not GNU software, it does not belong
in /usr/gnu.  Please do re-open this bug with a synopsis and
description that more accurately reflect the true scope of the RFE:
you want VIM in the WOS.  This absolutely is a worthwhile goal.

If the current synopsis is an accurate reflection of the RFE,
there is no reasonable way this RFE can be implemented: vim is
incompatible with vi, and has other characteristics (such as
a huge memory footprint relative to vi) that may make it unsuitable
or undesirable for many current vi users.
---

I want to make it absolutely clear that putting VIM in /usr/bin sounds
to me like a fine plan.  But I'll be very interested to hear how you
plan to deliver VIM's 'view' binary, since its name conflicts with
that of the existing program.

I'm going to start drafting a proposal for this. (Bug ID 6422494)

Cyril had a good question that nobody replied to: Is it feasible to
deliver only part of the vim package?

A typical vim build installs the following in /usr/bin:

- 3 regular files:  vim, vimtutor, and xxd[1]

- 11 files sym-linked to vim: evim, ex, gview, gvim, gvimdiff, rgview,
  rgvim, rview, rvim, view, vimdiff. Two of these -- view and ex --
  collide with existing files.

Here are some possibilities that I can think of:

1. Include vim (and its supporting files), but omit everything else (the
   11 sym-links, xxd, and vimtutor).

2. Include vim, vimtutor, and the 11 sym-links, but omit
   ex and view.

3. Include everything, renaming view and ex (viewm/exm?
   vimview/vimex?)

4. Other...?

If we went by the usage patterns of a lot of vim users (me included),
option #1 seems to make a lot of sense. But my take is that #3 is best --
mostly because implementations of the vim package are already in
widespread use on other popular platforms, and it'd be best to be as
compatible as possible with those.

Eric

[1]: xxd is a hex dumper/undumper
_______________________________________________
tools-discuss mailing list
[email protected]

Reply via email to