From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Mon, 08 Dec 2014 21:32:23 +0100 Organization: Organization?!? Message-ID: <871to9lw6g.fsf@fencepost.gnu.org> 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> <54823617.4000406@cs.ucla.edu> <83k325195l.fsf@gnu.org> <5482D94B.2070102@cs.ucla.edu> <5484FF31.5010808@cs.ucla.edu> <5485FC59.5030700@cs.ucla.edu> <87388p6glt.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418070929 18370 80.91.229.3 (8 Dec 2014 20:35:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 20:35:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 08 21:35:22 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 1Xy51d-0002zr-Sx for ged-emacs-devel@m.gmane.org; Mon, 08 Dec 2014 21:35:22 +0100 Original-Received: from localhost ([::1]:36026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy51d-0003ke-FP for ged-emacs-devel@m.gmane.org; Mon, 08 Dec 2014 15:35:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy51T-0003kA-0i for emacs-devel@gnu.org; Mon, 08 Dec 2014 15:35:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xy51M-0000h0-VG for emacs-devel@gnu.org; Mon, 08 Dec 2014 15:35:10 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:43737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy51M-0000f0-PD for emacs-devel@gnu.org; Mon, 08 Dec 2014 15:35:04 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xy51L-0002qo-Qd for emacs-devel@gnu.org; Mon, 08 Dec 2014 21:35:03 +0100 Original-Received: from x2f4aa58.dyn.telefonica.de ([2.244.170.88]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Dec 2014 21:35:03 +0100 Original-Received: from dak by x2f4aa58.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Dec 2014 21:35:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f4aa58.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:n3ZlUbFS/x43MzvkJez+wHYePkw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:179460 Archived-At: David Engster writes: > Paul Eggert writes: >> On 12/07/2014 06:30 PM, Stefan Monnier wrote: >>> I think I understand why they don't want to fix the processing speed. >>> But we should still push them to provide workarounds. "Separate >>> compilation" would solve this problem >> >> It might, yes. But that sounds like more work than switching input >> formats would be, if some other input format already has good support >> for most of what we want. >> >>> Indeed the slowdown (factor 100 IIRC last time I measured it) is >>> a serious problem. >> >> Absolutely. Texinfo's performance is a real turnoff for me, and it >> can't be encouraging potential contributors. > > ~/git-2.2.0/Documentation> time asciidoc -b html user-manual.txt > asciidoc -b html user-manual.txt 7.26s user 0.02s system 90% cpu 8.068 total > > That's for 4.5k lines. > > ~/emacs/doc/misc> time makeinfo --html gnus.texi > makeinfo --html gnus.texi 2.00s user 0.04s system 85% cpu 2.385 total > > That's for 30k lines. Yes, that's texinfo4, of course, but I hear it > still compiles. > > I doubt we will be happy with anything that's considerably slower than > texinfo4, which means that whatever we might switch to, it better be > written in something that's fast. That already rules out asciidoc and > Org. I don't actually see the big deal in compilation times for a full compilation. It's not like one does it all the time. If we are talking about proofreading, then it might be worth investigating how we can get partial compilation better to work in Texinfo editing modes. -- David Kastrup