Re: Please consider replace src/dist/nvi with nvi2

[Zhihao Yuan <lichray%gmail.com@localhost>]

On Mon, Oct 8, 2012 at 7:06 AM, matthew sporleder 
<msporleder%gmail.com@localhost> wrote:
> On Mon, Oct 8, 2012 at 7:28 AM, Zhihao Yuan <lichray%gmail.com@localhost> 
> wrote:
>> Hi, hackers:
>>
>> I'm maintaining another multibyte nvi fork, nvi2 
>> https://github.com/lichray/nvi2
>>
>> The project was written for FreeBSD GSoC 2011[1]. However, FreeBSD
>> requires code review before accepting the code, and I found no people
>> to help me yet. But NetBSD already accept nvi-1.81 in the base system,
>> so I come to here first to advise you to accept my version since it's
>> *much* *more* robust and trustful.
>>
>> Sven's nvi-1.8x has ton of bug and problems. Let me try to catalog some of 
>> them:
>>
>> 1. It does not work. Under a zh_CN.GB* locale, :se fe=utf-8, and input
>> Chinese, crashes. After I fixed the problem, try to pasting long text,
>> text longer than 256 becomes ^@ (NUL char in vi).
>> 2. Memory leaking. iconv_t are never free'd. Since int2char and
>> char2int share the same buffer, sometimes strdup is required, and
>> those are seldom free'd.
>> 3. Bugs caused by buffer sharing, like this
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664579 . I searches
>> the whole Internet for any nvi-1.8x bugs and fix them.
>> 4. Broken behaviors, incompatible with nvi-1.79/historical vi. The ^X
>> bug, #+/- bug, c$ on wide strings, isblank(3) (the upstream even uses
>> iswblank(3)... joking?), etc.
>> 5. Other logic glitches caused by the new screen layout.
>>
>> Since nvi2 is forked from nvi-1.79 and merged only nvi-1.8x's
>> iconv-related code, my version is free of problem 5 and the license
>> problem with DB3/4. And since I implemented the Unicode escape
>> sequence representation for non-print wide-chars, I fixed all of the
>> known bugs of type 1,3,4. All known memory leaking (except 2; I can
>> explain if you want a technical discuss) are also fixed with the help
>> of valgrind.
>>
>> I even fixed some broken stuff in nvi-1.79, like the cscope support.
>> It's marked as an feature of nvi but it never worked actually...
>>
>> If nvi2 is just a collection of patches, I'm not going to say
>> "replace". I also developed something new, something useful:
>>
>> 1. UTF-16 editing support.
>> 2. File encoding detection. Detects for UTF-16 (w BOM) and UTF-8, and
>> fallbacks to locale.
>> 3. Multibyte message. No more \x?? with printable wide strings in messages.
>> 4. Enhanced usability on BSDs. openpty(3), flock(2)-only locking, etc.
>> 5. Internal sendmail function. Nvi sends recovery notifications when
>> system start up, but /usr/sbin/sendmail is too slow.
>> 6. Recover files with arbitrary file name -- my version base64 them in
>> the recovery files.
>> 7. Full-featured file name completion. The completion accepts/yields
>> escaped path, like your bash/tcsh.
>>
>> So, in a word, if you are interesting in replacing your src/dist/nvi
>> with nvi2, please check here[2] first and I'm open to any questions.
>> Thanks.
>>
>> ..[1] Multibyte Encoding Support in Nvi
>> https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
>> ..[2] Porting Instructions https://github.com/lichray/nvi2/wiki/Porting
>>
>> --
>> Zhihao Yuan, nickname lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://4bsd.biz/
>
>
> Very cool.  Were you aware of Itojun's previous work?
>
> ftp://ftp.foretune.co.jp/pub/tools/nvi-m17n/
> (from http://www.itojun.org/itojun.html)

Yes. Before I submitted the GSoC proposal, I compared many known nvi
forks, vi clones. And nvi-m17n 's problem is that it uses a built-in
converter and limits its support to EUC family encodings. Such a
design is hard to support other encodings including UTF-8.

-- 
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/