From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 24 11:49:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56FC1106566B for ; Thu, 24 Mar 2011 11:49:25 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0126E8FC15 for ; Thu, 24 Mar 2011 11:49:24 +0000 (UTC) Received: by qwc9 with SMTP id 9so7310615qwc.13 for ; Thu, 24 Mar 2011 04:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X30GkmKTNB1TGUxIFcvNunHFSUNZ6zsEyKsoHk6ljYQ=; b=XyAsap5vvNWMtiVb8RiA73BXKdC3xQk5FvzFzRTyO7Fdt8OivQgYvSTUOwq2QiXbBa kpYLZmSWV6pe/M/b0XGvkE3gR3AObmRPpAxcTkcxkpY6hbfjE2LR8oSmP118OrIQfgSI H+Ie+M8ei57ajRxUsvMiAHFu9VvaOKhyPm/jY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R/nVZldRt6ZIPhfgYGbEFhEpVz1NV0gKU3xzgPVVd+EFyqhBHkpQ2A20V/42N18uX0 FBXfqnlH4XUo1cbIjXKV4BEWNJSOpFgugij8oHuXEEOuxL3nLmQgaAKcHfb+g+MNJe/P p9bOYRWJdS4Eqy8Oq1Z+e+dRjRZ5DLqvfRAA0= MIME-Version: 1.0 Received: by 10.224.138.16 with SMTP id y16mr6947142qat.255.1300967364087; Thu, 24 Mar 2011 04:49:24 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 24 Mar 2011 04:49:24 -0700 (PDT) In-Reply-To: <20110324111118.GF65750@cicely7.cicely.de> References: <86mxkm1erm.fsf@gmail.com> <86aaglx1ow.fsf@gmail.com> <20110324111118.GF65750@cicely7.cicely.de> Date: Thu, 24 Mar 2011 06:49:24 -0500 Message-ID: From: Zhihao Yuan To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Bernd Walter , Pan Tsu , Arnaud Lacombe Subject: Re: [GSoC] About the idea: Unicode support in vi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 11:49:25 -0000 On Thu, Mar 24, 2011 at 6:11 AM, Bernd Walter 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 wro= te: >> > 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 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 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.