Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 10:46 PM, Pan Tsu wrote: > Zhihao Yuan writes: > >> 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. > > ex-vi memory usage can be reduced a bit, e.g. by ~20% if you drop > -DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 > in particular multibyte support. > >> 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. > > If the intent is to make all interactive editors in base unicode aware > then I wonder if you can use similar excuse when window(1) was kicked > out but for missing features, i.e. use ports. If user accepts the window or even screen in ports, they can also accept ex-vi staying in ports. > > As for other editors, ed(1) seems to support editing UTF-8. I've used it > to read/edit cyrillic and CJK texts in single user mode before found out > about ex-vi. And ee(1)... why not add unicode support there as a GSoC? > ed seems works, but it's not either vi or ex. I'm not typically like ee... I sill wondering why we kept it in base system. It does not work when termcap is not correct, so I still need to use ed in such a case. Same thing happens to ex-vi. -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan writes: > 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. ex-vi memory usage can be reduced a bit, e.g. by ~20% if you drop -DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 in particular multibyte support. > 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. If the intent is to make all interactive editors in base unicode aware then I wonder if you can use similar excuse when window(1) was kicked out but for missing features, i.e. use ports. As for other editors, ed(1) seems to support editing UTF-8. I've used it to read/edit cyrillic and CJK texts in single user mode before found out about ex-vi. And ee(1)... why not add unicode support there as a GSoC? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan 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. > > 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. Please don't do this. I use nvi every day on FreeBSD. I use the multi-level undo daily, and the multiple window feature, if not daily, at least weekly. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan 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. 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. -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 4:50 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan wrote: >> On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: >>> Zhihao Yuan writes: I'm not sure whether the FreeBSD system administrators (who opens 100 ssh sessions) agree with that to replace the nvi in base system with this one. >>> >>> Do they expect more features beyond POSIX vi? >> >> Like multiple windows. This has been discussed y other BSDs before. >> > For the reference, on the Linux side, busybox do all what an admin > would reasonably expect (I mean _all_ the basic userland, not just > editing text) in a binary smaller than nvi. Now, it's true that _you_ > might not care about size/bloat, at least accept that some do. > > - Arnaud > 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. -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Hi, On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan wrote: > On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: >> Zhihao Yuan writes: >>> I'm not sure whether the FreeBSD system administrators (who opens 100 >>> ssh sessions) agree with that to replace the nvi in base system with >>> this one. >> >> Do they expect more features beyond POSIX vi? > > Like multiple windows. This has been discussed y other BSDs before. > For the reference, on the Linux side, busybox do all what an admin would reasonably expect (I mean _all_ the basic userland, not just editing text) in a binary smaller than nvi. Now, it's true that _you_ might not care about size/bloat, at least accept that some do. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu wrote: > Zhihao Yuan writes: > >>> Why not just use "traditional vi"? >>> >>> http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) >> >> This one lacks of many feature, compared with nvi. > > nvi also lacks some features, e.g. lisp, modelines, sourceany. > ex-vi is more lightweight > > # both built with DEBUG_FLAGS=-ggdb + mg(1) for reference > > $ du -Ah * > 1.9M nvi > 556K ex-vi > 505K mg > > $ size * > text data bss dec hex filename > 329080 1952 4528 335560 51ec8 nvi > 175675 5048 233024 413747 65033 ex-vi > 128570 9760 10184 148514 24422 mg nvi is a rewrite of the original vi, so this only shows that the new implementation uses more symbols. The actual binary results are just a 120K difference. > >> I'm not sure whether the FreeBSD system administrators (who opens 100 >> ssh sessions) agree with that to replace the nvi in base system with >> this one. > > Do they expect more features beyond POSIX vi? Like multiple windows. This has been discussed y other BSDs before. > >> However, it's source code can be a great reference for a mbyte-capable >> nvi. > -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan writes: >> Why not just use "traditional vi"? >> >> http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) > > This one lacks of many feature, compared with nvi. nvi also lacks some features, e.g. lisp, modelines, sourceany. ex-vi is more lightweight # both built with DEBUG_FLAGS=-ggdb + mg(1) for reference $ du -Ah * 1.9Mnvi 556Kex-vi 505Kmg $ size * textdata bss dec hex filename 32908019524528 335560 51ec8 nvi 1756755048 233024 413747 65033 ex-vi 1285709760 10184 148514 24422 mg > I'm not sure whether the FreeBSD system administrators (who opens 100 > ssh sessions) agree with that to replace the nvi in base system with > this one. Do they expect more features beyond POSIX vi? > However, it's source code can be a great reference for a mbyte-capable > nvi. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Am 23.03.2011 16:06, schrieb Alexey Shuvaev: > Yes, nvi-devel is not developed any more, but I was saying that nvi > in base is even older than nvi-devel, and it is worth looking at > it. At least for the iconv support. As for the BDB, maybe strip it just > out, if possible? I don't believe it's possible, because it uses a RECNO database that is backed by a text file, i. e. it crucially relies on it for data management apparently. But at least db51 and db42 work fine, apparently it was a db41-specific incompatibility that broke nvi-devel 1.81.6_4. Compiling WITH_BDB_HIGHEST=yes should help for the nonce. We're fixing the port to use 4.2 at least. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 02:38:20PM +0100, Matthias Andree wrote: > Am 23.03.2011 10:13, schrieb Alexey Shuvaev: > > On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > >> Hi, > >> > >> I'm a Computer Science student at Northern Illinois University, and I > >> used FreeBSD for a long time. I'm interested in the idea that to > >> improve the nvi in the base system. My proposal is slightly different: > >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > >> like tcsh), so that it can deal with more encodings. Can that be a > >> GSoC project proposal? > >> > > +1 here! > > > > ports/editors/nvi-devel is another starting point here. As far as I > > understand > > it is a further development of nvi which is in base. What I don't like > > about it is a dependency on databases/db3 and changed (worse, in my opinion) > > handling of keystrokes in 'insert' mode. But it is iconv-aware > > implementation > > already. > > nvi-devel is bit-rotten. Most releases date from 2004, and there was a > patchlevel-release in 2007 apparently, since then it's been left to bit rot. > > I'm thinking about just killing databases/db3 and see what happens with > nvi-devel. I tried convincing it to work with db41, and while it > compiles, it somehow abuses Berkeley DB in a way I don't see during > debugging and barfs with "Invalid argument" on a DB->open call on a > recovery file. > > Also, the documentation says it depends on 3.1, but then we've been > using 3.3 for ages, but even the first release of nvi-devel to use > Berkeley DB was released when 4.2 was already out. There seems to be > some code to make it work (which in itself is buggy it uses broken > comparisons for its version checks), but it doesn't work for reasons I > don't see with gdb. Berkeley DB doesn't like the way it's being used > and errors out with EINVAL. However, I don't care enough to build a > debug-enabled version of Berkeley DB to see where abandoned nvi-devel > might abuse bdb. > Yes, nvi-devel is not developed any more, but I was saying that nvi in base is even older than nvi-devel, and it is worth looking at it. At least for the iconv support. As for the BDB, maybe strip it just out, if possible? > vim works for me, supports Unicode, and for "fewer dependencies", we > have vim-lite. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Am 23.03.2011 10:13, schrieb Alexey Shuvaev: > On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: >> Hi, >> >> I'm a Computer Science student at Northern Illinois University, and I >> used FreeBSD for a long time. I'm interested in the idea that to >> improve the nvi in the base system. My proposal is slightly different: >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, >> like tcsh), so that it can deal with more encodings. Can that be a >> GSoC project proposal? >> > +1 here! > > ports/editors/nvi-devel is another starting point here. As far as I understand > it is a further development of nvi which is in base. What I don't like > about it is a dependency on databases/db3 and changed (worse, in my opinion) > handling of keystrokes in 'insert' mode. But it is iconv-aware implementation > already. nvi-devel is bit-rotten. Most releases date from 2004, and there was a patchlevel-release in 2007 apparently, since then it's been left to bit rot. I'm thinking about just killing databases/db3 and see what happens with nvi-devel. I tried convincing it to work with db41, and while it compiles, it somehow abuses Berkeley DB in a way I don't see during debugging and barfs with "Invalid argument" on a DB->open call on a recovery file. Also, the documentation says it depends on 3.1, but then we've been using 3.3 for ages, but even the first release of nvi-devel to use Berkeley DB was released when 4.2 was already out. There seems to be some code to make it work (which in itself is buggy it uses broken comparisons for its version checks), but it doesn't work for reasons I don't see with gdb. Berkeley DB doesn't like the way it's being used and errors out with EINVAL. However, I don't care enough to build a debug-enabled version of Berkeley DB to see where abandoned nvi-devel might abuse bdb. vim works for me, supports Unicode, and for "fewer dependencies", we have vim-lite. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan writes:
> Hi,
>
> I'm a Computer Science student at Northern Illinois University, and I
> used FreeBSD for a long time. I'm interested in the idea that to
> improve the nvi in the base system. My proposal is slightly different:
> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable,
> like tcsh), so that it can deal with more encodings. Can that be a
> GSoC project proposal?
Why not just use "traditional vi"?
http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi)
don't forget to extract sources into contrib/ex-vi
diff --git a/rescue/rescue/Makefile b/rescue/rescue/Makefile
index d62b6f4..e6d8686 100644
--- a/rescue/rescue/Makefile
+++ b/rescue/rescue/Makefile
@@ -218,7 +218,8 @@ CRUNCH_LIBS+= -larchive -lmd
CRUNCH_LIBS+= -lcrypto
.endif
-CRUNCH_PROGS_usr.bin+= vi
+CRUNCH_SRCDIRS+= usr.bin/ex-vi
+CRUNCH_PROGS_usr.bin/ex-vi+= vi
CRUNCH_ALIAS_vi= ex
CRUNCH_PROGS_usr.bin+= id
diff --git a/usr.bin/Makefile b/usr.bin/Makefile
index f7965f1..ffde23d 100644
--- a/usr.bin/Makefile
+++ b/usr.bin/Makefile
@@ -169,7 +174,7 @@ SUBDIR= alias \
users \
uudecode \
uuencode \
- vi \
+ ex-vi \
vis \
vmstat \
w \
diff --git a/usr.bin/ex-vi/Makefile b/usr.bin/ex-vi/Makefile
new file mode 100644
index 000..d4db4a5
--- /dev/null
+++ b/usr.bin/ex-vi/Makefile
@@ -0,0 +1,5 @@
+# $FreeBSD$
+
+SUBDIR= expreserve exrecover vi
+
+.include
diff --git a/usr.bin/ex-vi/Makefile.inc b/usr.bin/ex-vi/Makefile.inc
new file mode 100644
index 000..4b1eb39
--- /dev/null
+++ b/usr.bin/ex-vi/Makefile.inc
@@ -0,0 +1,11 @@
+# $FreeBSD$
+
+SRCDIR= ${.CURDIR}/../../../contrib/ex-vi
+.PATH: ${SRCDIR}
+
+LIBEXECDIR?=/usr/libexec
+CFLAGS+=-DVMUNIX
+
+WARNS?= 1
+
+.include "${.CURDIR}/../../Makefile.inc"
diff --git a/usr.bin/ex-vi/expreserve/Makefile b/usr.bin/ex-vi/expreserve/Makefile
new file mode 100644
index 000..ad1d953
--- /dev/null
+++ b/usr.bin/ex-vi/expreserve/Makefile
@@ -0,0 +1,7 @@
+# $FreeBSD$
+
+PROG= expreserve
+BINDIR= ${LIBEXECDIR}
+NO_MAN=
+
+.include
diff --git a/usr.bin/ex-vi/exrecover/Makefile b/usr.bin/ex-vi/exrecover/Makefile
new file mode 100644
index 000..e808926
--- /dev/null
+++ b/usr.bin/ex-vi/exrecover/Makefile
@@ -0,0 +1,9 @@
+# $FreeBSD$
+
+PROG= exrecover
+BINDIR= ${LIBEXECDIR}
+NO_MAN=
+
+SRCS= exrecover.c mapmalloc.c
+
+.include
diff --git a/usr.bin/ex-vi/vi/Makefile b/usr.bin/ex-vi/vi/Makefile
new file mode 100644
index 000..d974280
--- /dev/null
+++ b/usr.bin/ex-vi/vi/Makefile
@@ -0,0 +1,26 @@
+# $FreeBSD$
+
+PROG= vi
+MAN= ex.1 vi.1
+SRCS= ex.c ex_addr.c ex_cmds.c ex_cmds2.c ex_cmdsub.c \
+ ex_data.c ex_extern.c ex_get.c ex_io.c ex_put.c ex_re.c \
+ ex_set.c ex_subr.c ex_tagio.c ex_temp.c ex_tty.c ex_unix.c \
+ ex_v.c ex_vadj.c ex_vget.c ex_vmain.c ex_voper.c \
+ ex_vops.c ex_vops2.c ex_vops3.c ex_vput.c ex_vwind.c \
+ printf.c ex_version.c mapmalloc.c
+
+.for l in ex edit vedit view
+LINKS+= ${BINDIR}/vi ${BINDIR}/${l}
+.endfor
+MLINKS+=ex.1 edit.1 vi.1 vedit.1 vi.1 view.1
+
+CFLAGS+=-DUXRE -DREG_ANGLES=0 -DNO_BE_BACKSLASH
+CFLAGS+=-DEXPRESERVE=\"${LIBEXECDIR}/expreserve\" \
+ -DEXRECOVER=\"${LIBEXECDIR}/exrecover\"
+CFLAGS+=-DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8
+#CFLAGS+=-DLARGEF
+
+LDADD+= -lncurses
+DPADD+= ${LIBNCURSES}
+
+.include
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? > +1 here! ports/editors/nvi-devel is another starting point here. As far as I understand it is a further development of nvi which is in base. What I don't like about it is a dependency on databases/db3 and changed (worse, in my opinion) handling of keystrokes in 'insert' mode. But it is iconv-aware implementation already. My 0.02$, Alexey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? This is a very great idea. I'm missing this feature more and more. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: > Hi, > > I'm a Computer Science student at Northern Illinois University, and I > used FreeBSD for a long time. I'm interested in the idea that to > improve the nvi in the base system. My proposal is slightly different: > I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, > like tcsh), so that it can deal with more encodings. Can that be a > GSoC project proposal? > I'm only speaking for myself [obviously], but I think this would be an excellent idea. I'm using nvi on my FreeBSD server; works fine. But using it on my Ubuntu desktop dails because the "default vi" is vim. vim and nvi are incompat. Having using vi since the earth was formed, I am wy stuck with it. Please do keep me posted if you rxpand nvi. gary kline > -- > Zhihao Yuan > The best way to predict the future is to invent it. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 2:23 AM, Pan Tsu wrote: > Zhihao Yuan writes: > >> Hi, >> >> I'm a Computer Science student at Northern Illinois University, and I >> used FreeBSD for a long time. I'm interested in the idea that to >> improve the nvi in the base system. My proposal is slightly different: >> I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, >> like tcsh), so that it can deal with more encodings. Can that be a >> GSoC project proposal? > > Why not just use "traditional vi"? > > http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) > > This one lacks of many feature, compared with nvi. I'm not sure whether the FreeBSD system administrators (who opens 100 ssh sessions) agree with that to replace the nvi in base system with this one. However, it's source code can be a great reference for a mbyte-capable nvi. -- Zhihao Yuan The best way to predict the future is to invent it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
