From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Fri, 05 Dec 2014 14:47:51 -0800 Organization: UCLA Computer Science Department Message-ID: <54823617.4000406@cs.ucla.edu> References: <20141205123549.GA29331@thyrsus.com> <2815659.zRQ0WWWeRr@descartes> <20141205175810.GD3120@thyrsus.com> <87lhmlncb1.fsf@earlgrey.lan> <20141205193643.GB5067@thyrsus.com> <87tx19rd1b.fsf@fencepost.gnu.org> <20141205215138.GF7784@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1417819710 24367 80.91.229.3 (5 Dec 2014 22:48:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2014 22:48:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 05 23:48:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xx1fj-0001GE-7r for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 23:48:23 +0100 Original-Received: from localhost ([::1]:52773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx1fi-00049Z-QU for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 17:48:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx1fZ-00049M-S4 for emacs-devel@gnu.org; Fri, 05 Dec 2014 17:48:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xx1fT-0004WW-5j for emacs-devel@gnu.org; Fri, 05 Dec 2014 17:48:13 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx1fS-0004UL-W6 for emacs-devel@gnu.org; Fri, 05 Dec 2014 17:48:07 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 15640A6016E; Fri, 5 Dec 2014 14:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qydCYpav0Uzv; Fri, 5 Dec 2014 14:47:52 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1FD44A60168; Fri, 5 Dec 2014 14:47:52 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <20141205215138.GF7784@thyrsus.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179057 Archived-At: On 12/05/2014 01:51 PM, Eric S. Raymond wrote: >> So if we don't have better alternatives, why not stick with what we >> >have? > Because it's ugly, heavyweight, and a barrier to entry. Although I know Texinfo well and asciidoc poorly and so am naturally biased in favor of Texinfo, I can certainly attest to Texinfo being heavyweight and having significant problems. My 3-year-old desktop at work currently takes over a minute to create info/elisp.info from Emacs's Texinfo sources, and this is so annoyingly slow that it discourages me from checking my work when I edit the Elisp manual. I know some Emacs developers purposely run older versions of Texinfo (which are faster) because of this performance problem, and this means we can't assume reasonably modern Texinfo features, e.g., good support for Unicode characters. Even though Texinfo made a lot of sense for many years and we should not switch lightly, it may now be time to think of switching. It'd be a win if we could use a format with a decently-fast support.