Re: Fun with nvi
Hm, do we disable building the base with ICONV support in -HEAD? I'd like to trim it out so I can slim down embedded builds. Thanks! -adrian On 10 August 2013 10:33, Peter Wemm pe...@wemm.org wrote: I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 https://github.com/lichray/nvi2 The goal was to update the multibyte handling in nvi-1.79 (the one we have in our tree) in such a way we could import it. Anyway.. an early WIP: http://people.freebsd.org/~peter/nvi2.tgz peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643 echo $LANG en_US.UTF-8 peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644 vi -c 'set fileencoding=GB2312' zh_CN.GB2312.base .. leads to fun things like: http://people.freebsd.org/~peter/nvi2-transcoding.png that's editing the file in GB2312 format, but converting to utf-8 on the fly for my terminal. This is with the WITH_ICONV=yes in make.conf. nvi2 will build without it but obviously won't be able to work with non-default encoding methods. In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png How to use the tarball.. 1) rm -rf contrib/nvi usr.bin/vi 2) extract tarball into src tree 3) patch -p0 nvi.diff (this adds a built-tool to world) Note that I haven't actually done a buildworld yet. I've just been building it directly from src/usr.bin/vi with make obj make depend make all make install .. to save time. But you'll need to have WITH_ICONV=yes in make.conf to do the fancy stuff. Note that the ports tree is a long way from being WITH_ICONV=yes safe, so don't do this on an important machine. An example of the tweaks to make ports happier: http://people.freebsd.org/~peter/iconv.diff - that's not complete. Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's still some oddballs scattered around in weird places. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. brueffer ZFS must be the bacon of file systems. everything's better with ZFS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fun with nvi
On Sat, Aug 10, 2013 at 10:33:20AM -0700, Peter Wemm wrote: I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 https://github.com/lichray/nvi2 The goal was to update the multibyte handling in nvi-1.79 (the one we have in our tree) in such a way we could import it. Yes, please do something about our base(1) being unable to talk in anything non-ASCII. I'm using editors/nvi-devel now, which was WIDECHAR option, and was wondering why those changes were never imported into the base. How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw? ./danfe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fun with nvi
On Sun, Aug 11, 2013 at 1:35 AM, Alexey Dokuchaev da...@freebsd.org wrote:
On Sat, Aug 10, 2013 at 10:33:20AM -0700, Peter Wemm wrote:
I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2.
https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
https://github.com/lichray/nvi2
The goal was to update the multibyte handling in nvi-1.79 (the one we
have in our tree) in such a way we could import it.
Yes, please do something about our base(1) being unable to talk in anything
non-ASCII. I'm using editors/nvi-devel now, which was WIDECHAR option, and
was wondering why those changes were never imported into the base.
How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw?
The original reason was that nvi-devel switched from the db-1.x API to
db-3/db-4 which were sleepycat licensed, and are now Oracle. It was a
big chunk of code at the time. eg:
USE_BDB=42+
CONFIGURE_ARGS+=--with-db-prefix=${LOCALBASE}
nvi2 is nvi-1.79 from base with a serious cleanup pass. The
iconv/multibyte code will look quite familiar if you've looked at the
nvi-devel code, along with a cherry-picking of additions from nvi-m17n
for better CJK/non-utf8 support.
nvi2 does not have the same level of sophisticated encoding detection
that nvi-m17n has.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems. everything's better with ZFS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fun with nvi
On Sun, Aug 11, 2013 at 02:15:15AM -0700, Peter Wemm wrote:
On Sun, Aug 11, 2013 at 1:35 AM, Alexey Dokuchaev da...@freebsd.org wrote:
Yes, please do something about our base(1) being unable to talk in anything
non-ASCII. I'm using editors/nvi-devel now, which was WIDECHAR option, and
was wondering why those changes were never imported into the base.
Yuck, pardon my typos: it should read base vi(1) and has WIDECHAR option.
How is nvi 1.81.6 (per editors/nvi-devel) is different from nvi2, btw?
The original reason was that nvi-devel switched from the db-1.x API to
db-3/db-4 which were sleepycat licensed, and are now Oracle. It was a
big chunk of code at the time. eg:
USE_BDB=42+
CONFIGURE_ARGS+=--with-db-prefix=${LOCALBASE}
nvi2 is nvi-1.79 from base with a serious cleanup pass. The
iconv/multibyte code will look quite familiar if you've looked at the
nvi-devel code, along with a cherry-picking of additions from nvi-m17n
for better CJK/non-utf8 support.
Understood, thanks for the insight.
nvi2 does not have the same level of sophisticated encoding detection
that nvi-m17n has.
I don't care too much about encoding detection since all sane parts of the
world would have switched to UTF-8 by now. ;-)
./danfe
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Fun with nvi
I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 https://github.com/lichray/nvi2 The goal was to update the multibyte handling in nvi-1.79 (the one we have in our tree) in such a way we could import it. Anyway.. an early WIP: http://people.freebsd.org/~peter/nvi2.tgz peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643 echo $LANG en_US.UTF-8 peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644 vi -c 'set fileencoding=GB2312' zh_CN.GB2312.base .. leads to fun things like: http://people.freebsd.org/~peter/nvi2-transcoding.png that's editing the file in GB2312 format, but converting to utf-8 on the fly for my terminal. This is with the WITH_ICONV=yes in make.conf. nvi2 will build without it but obviously won't be able to work with non-default encoding methods. In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png How to use the tarball.. 1) rm -rf contrib/nvi usr.bin/vi 2) extract tarball into src tree 3) patch -p0 nvi.diff (this adds a built-tool to world) Note that I haven't actually done a buildworld yet. I've just been building it directly from src/usr.bin/vi with make obj make depend make all make install .. to save time. But you'll need to have WITH_ICONV=yes in make.conf to do the fancy stuff. Note that the ports tree is a long way from being WITH_ICONV=yes safe, so don't do this on an important machine. An example of the tweaks to make ports happier: http://people.freebsd.org/~peter/iconv.diff - that's not complete. Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's still some oddballs scattered around in weird places. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. brueffer ZFS must be the bacon of file systems. everything's better with ZFS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
