[GSoC] About the idea: Unicode support in vi

[Zhihao Yuan]

On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter <ticso at cicely7.cicely.de> wrote:
> On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote:
>> On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
>> > Hi,
>> >
>> > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan <lichray at gmail.com> wrote:
>> >> Among *all* the GNU/Linux distributions I used, they include a vim
>> >> compiled in tiny mode (ln -s it to vi), which doubles the size of nvi,
>> >> in their base systems. A vim.tiny contains much more features compared
>> >> with nvi, but it's not compatible with POSIX vi.
>> >>
>> > Let's compare the comparable, I don't really care if PCbsd ship vim as
>> > its default, but FreeBSD as the base is not only aimed at desktop
>> > specifically. So you should take into account that I may want to run
>> > FreeBSD on an adm5120 board with 32MB of RAM, without having a text
>> > editor consuming too much disk-space/ram.
>> >
>> >  - Arnaud
>> >
>>
>> If you really want to use vi in a 32MB mem environment, the ex-vi may
>> make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note
>> that the ee editor uses same amount memory as ex-vi.
>
> If you really want to save memory - RAM and filesystem - in such a reduced
> way, then you need something else.
> /bin/sh without history, reduced termcap, sparsed rc.d and you should
> also consider static linked crunchgen binaries.
> This has nothing to do with any other typical installation.
> Also Linux doesn't do this - there are Linux distributions using bloated
> featured binaries and there are tiny distributions with low footprint
> tools such as busybox.
>
>> So basically, if no one disagree that we can drop the infinite undo,
>> multiple buffer, multiple window and some other potential missing
>> features, we can replace the nvi in the base system with ex-vi.
>
> Of course people will disagree.
> The thread is about adding unicode support this means they want to stay
> with the features of our current editor.
> I like the window feature of nvi, but I don't  really need it for the
> system editor, but having Unicode support would be a big win and multiple
> undo is very valueable for a system editor.
> Of course this isn't one of the must have features on a memory constrained
> box, but only because you have a higher pressure.
> It is true that you can easily add your favourite editor from ports,
> but it is also true that I often get phone calls to help them with their
> systems and in this case you want a useable editor, which is just there
> for sure.
> If a machine isn't online, e.g. because of a trashed filesystem you can't
> install a random editor and must live with what's there to fix the
> situation.
> And yes - I also often use ed in many crashed situations, because it
> is easier to fix e.g. an fstab with ed and reboot than to setup your
> terminal environment.
>
> --
> B.Walter <bernd at bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>

Let clean up the my points:
1. ex-vi is POSIX vi compatible, and it supports mbyte encodings. But
there are lots of work need to be done if we want to use it to replace
the current nvi in the base system;
2. nvi does not use iconv, nvi-m17n only supports limited non-Unicode
mbyte encodings, nvi-devel has too many problems. So we don't have a
nvi which comes with fully mbyte enconding support;
3. Since other textproc tools, even include ed, support mbyte
encodings, we do need a improved nvi;
4. Maybe compared with other kernel related GSoC proposals, this one
seems to be easier. But on the other hand, the goal is useful, and the
scale of the goal gives it more chance to become really useful.

It that reasonable?

-- 
Zhihao Yuan
The best way to predict the future is to invent it.