Re: [GSoC] About the idea: Unicode support in vi
On Fri, Mar 25, 2011 at 1:39 PM, Zhihao Yuan lich...@gmail.com wrote: On Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl l...@pix.net wrote: On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: Zhihao Yuan wrote: Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I have checked that. It's just a latest nvi 1.85. I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -Kurt -- Zhihao Yuan The best way to predict the future is to invent it. Sorry to spam in the group... Since the application time is coming, I do need a possible mentor. I was told that nvi in the base system was not managed by a dedicated people. So I hope I can talk with someone who is free during the summer, and has some interests to help me :) -- 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
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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. 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. I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I think it makes more sense to grow a WITHOUT_NVI knob in buildworld so that people building for embedded systems can exclude nvi and include another version of vi when really pressed for space, like we can replace the base systems sendmail by sendmail from ports or another MTA. Regards, Paul Schenkeveld ___ 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 Sat, Mar 26, 2011 at 3:45 AM, Paul Schenkeveld free...@psconsult.nl 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 lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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. 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. I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I will improve nvi only, and I won't break the traditional functions. But your words reminds me that, perhaps the move of cursor is a problem for a mbytes-enabled vi. We will see. I think it makes more sense to grow a WITHOUT_NVI knob in buildworld so that people building for embedded systems can exclude nvi and include another version of vi when really pressed for space, like we can replace the base systems sendmail by sendmail from ports or another MTA. Regards, Paul Schenkeveld ___ 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 -- 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
On Sat, Mar 26, 2011 at 03:55:12AM -0500, Zhihao Yuan wrote: On Sat, Mar 26, 2011 at 3:45 AM, Paul Schenkeveld free...@psconsult.nl 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 lacom...@gmail.com wrote: I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I will improve nvi only, and I won't break the traditional functions. But your words reminds me that, perhaps the move of cursor is a problem for a mbytes-enabled vi. We will see. It especially is if characters are double wide on output, which happens at least with some chinese ones. I really hope you will find a mentor soon enough. -- B.Walter be...@bwct.de 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
Zhihao Yuan wrote: Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Johan pgpdrm84mqX2I.pgp Description: PGP signature
Re: [GSoC] About the idea: Unicode support in vi
On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: Zhihao Yuan wrote: Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -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 Fri, Mar 25, 2011 at 8:45 AM, Kurt Lidl l...@pix.net wrote: On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: Zhihao Yuan wrote: Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I have checked that. It's just a latest nvi 1.85. I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -Kurt -- 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
On Wed, Mar 23, 2011 at 10:46 PM, Pan Tsu iny...@gmail.com wrote: Zhihao Yuan lich...@gmail.com 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
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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 be...@bwct.de 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 Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter ti...@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 lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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 be...@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. ___ 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 Thu, Mar 24, 2011 at 06:49:24AM -0500, Zhihao Yuan wrote: On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter ti...@cicely7.cicely.de wrote: 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. it makes sense to upgrade nvi rather that ex-vi ... for reasons prev'ly mentioned. talking about space/memory and even processor speed seems like a non-issue. i would like to be able to be editing a file with vim [[ for WHATEVER reason ]] and pick up or resume editing the same file with nvi. Of course there are dozens of alley-ways and twists and turns we all can get into is arguing this-and-that about the fine-grained details. It boils down to an issue of usefulness-- as i see it. be nice to have a feature for feature, bug for bug clone of vi that nvi used to claim to be. again: have nvi and vim be interchangable. oh: and then give the new nvi to the linux guys and let then deal with any port or build issues. -- 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
Zhihao Yuan lich...@gmail.com wrote: 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. History: ee was added long ago by emacs afficionado jkh@ for the sys installer eg /etc/inetd.conf Small vi clones in source were available then too, on DOS 3.2 Minix, One was called Stevie, I can't remember the others. Replacing ee with a mini vi clone would be a return to Unix. One would need to co-ordinate on sysinst...@freebsd.org Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ 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 Thu, Mar 24, 2011 at 5:07 PM, Julian H. Stacey j...@berklix.com wrote: Zhihao Yuan lich...@gmail.com wrote: 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. History: ee was added long ago by emacs afficionado jkh@ for the sys installer eg /etc/inetd.conf Small vi clones in source were available then too, on DOS 3.2 Minix, One was called Stevie, I can't remember the others. Replacing ee with a mini vi clone would be a return to Unix. One would need to co-ordinate on sysinst...@freebsd.org O-O-Ok... Let emacs guys do emacs stuff. I need to go looking for a possible mentor on nvi... Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. -- 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 wrote: 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; Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. nvi-devel does have proper UTF-8 support via libiconv. It is based on the nvi version we currently have in base and much of the code base is still identical. Johan pgpEar3ZsAfUZ.pgp Description: PGP signature
Re: [GSoC] About the idea: Unicode support in vi
On Thu, Mar 24, 2011 at 5:17 PM, Johan van Selst joh...@stack.nl wrote: Zhihao Yuan wrote: 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; Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. nvi-devel does have proper UTF-8 support via libiconv. It is based on the nvi version we currently have in base and much of the code base is still identical. Johan 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. -- 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
[GSoC] About the idea: Unicode support in vi
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? -- 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
On Wed, Mar 23, 2011 at 2:23 AM, Pan Tsu iny...@gmail.com wrote: Zhihao Yuan lich...@gmail.com 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
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 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 be...@bwct.de 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? +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
Zhihao Yuan lich...@gmail.com 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 bsd.subdir.mk
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 bsd.prog.mk
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 bsd.prog.mk
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 bsd.prog.mk
___
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
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 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
Zhihao Yuan lich...@gmail.com 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
On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu iny...@gmail.com wrote: Zhihao Yuan lich...@gmail.com 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
Hi, On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan lich...@gmail.com wrote: On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu iny...@gmail.com wrote: Zhihao Yuan lich...@gmail.com 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 4:50 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 4:36 PM, Zhihao Yuan lich...@gmail.com wrote: On Wed, Mar 23, 2011 at 11:05 AM, Pan Tsu iny...@gmail.com wrote: Zhihao Yuan lich...@gmail.com 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 7:32 PM, Zhihao Yuan lich...@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 ___ 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 lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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. 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
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@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. 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
Zhihao Yuan lich...@gmail.com 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
