Date: Thu, 24 Mar 2011 06:49:24 -0500 From: Zhihao Yuan <lichray@gmail.com> To: ticso@cicely.de Cc: freebsd-hackers@freebsd.org, Bernd Walter <ticso@cicely7.cicely.de>, Pan Tsu <inyaoo@gmail.com>, Arnaud Lacombe <lacombar@gmail.com> Subject: Re: [GSoC] About the idea: Unicode support in vi Message-ID: <AANLkTikzpFAux=TX9n8bRgGW8CFT%2BBPfRe1JEEpwj26O@mail.gmail.com> In-Reply-To: <20110324111118.GF65750@cicely7.cicely.de> References: <AANLkTintkKzW=o%2B7Q53aMSpA1mmqC7aDF1wN8zHY_Wc%2B@mail.gmail.com> <86mxkm1erm.fsf@gmail.com> <AANLkTin3Wki6bnriNgWUy5JC68MDMVc4Y444tGWcKBQ7@mail.gmail.com> <86aaglx1ow.fsf@gmail.com> <AANLkTikLbU--J2aVa00tzxWb9GAvjfGnUGovwYaXXqhp@mail.gmail.com> <AANLkTimKzTrLA%2BW4a73D=aS8fy9npeqvrS8Ua3oNKrjf@mail.gmail.com> <AANLkTin=Y-z-Rt0cnd3MRg0JoSWJmhC3Uh2b32Bosgfi@mail.gmail.com> <AANLkTimDnA6jdj-MR7J2EGAQFn=%2BRrS9h32N5UWkaDUs@mail.gmail.com> <AANLkTinuQG2ew4R81861Ei7Czds0pGVFaD4ExheFpnnE@mail.gmail.com> <20110324111118.GF65750@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter <ticso@cicely7.cicely.de> wro= te: > 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@gmail.com> wro= te: >> > Hi, >> > >> > On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan <lichray@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 compare= d >> >> 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. >> > >> > =C2=A0- 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 reduce= d > 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 =C2=A0really need it for th= e > 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 constraine= d > 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@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? --=20 Zhihao Yuan The best way to predict the future is to invent it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikzpFAux=TX9n8bRgGW8CFT%2BBPfRe1JEEpwj26O>