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: Wed, 10 Dec 2014 14:20:00 -0800 Organization: UCLA Computer Science Department Message-ID: <5488C710.3000209@cs.ucla.edu> References: <20141205123549.GA29331@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> <871to9lw6g.fsf@fencepost.gnu.org> <5486A704.6090305@cs.ucla.edu> <87k321jj4e.fsf@fencepost.gnu.org> <54876F7F.9000607@cs.ucla.edu> <87y4qfj2u9.fsf@fencepost.gnu.org> <54889A57.5060905@cs.ucla.edu> <87vbljb9f4.fsf@wanadoo.es> <54889F6D.6060408@cs.ucla.edu> <87r3w7b83a.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1418250610 22488 80.91.229.3 (10 Dec 2014 22:30:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Dec 2014 22:30:10 +0000 (UTC) To: =?UTF-8?B?w5NzY2FyIEZ1ZW50ZXM=?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 10 23:30:03 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 1Xyplg-0004lt-LH for ged-emacs-devel@m.gmane.org; Wed, 10 Dec 2014 23:30:00 +0100 Original-Received: from localhost ([::1]:48285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyplf-0000gg-SC for ged-emacs-devel@m.gmane.org; Wed, 10 Dec 2014 17:29:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyplI-0000ft-9J for emacs-devel@gnu.org; Wed, 10 Dec 2014 17:29:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyplC-0006V8-M7 for emacs-devel@gnu.org; Wed, 10 Dec 2014 17:29:36 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:37481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyplC-0006V4-Dw for emacs-devel@gnu.org; Wed, 10 Dec 2014 17:29:30 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B3C0DA60074; Wed, 10 Dec 2014 14:20:05 -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 e-axj9uQFfsT; Wed, 10 Dec 2014 14:20:01 -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 27FCCA60020; Wed, 10 Dec 2014 14:20:01 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <87r3w7b83a.fsf@wanadoo.es> 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:179712 Archived-At: On 12/10/2014 11:47 AM, =C3=93scar Fuentes wrote: > Paul Eggert writes: > >> Typically I >> focus on that editing the .texi file first to get the content right. >> Then, I want to make sure the result is readable so I generate the >> output and look at it. > I reckon that those issues are related to the texinfo format, > specifically. Other formats can be checked for readability without > exporting them first. Sorry, I'm lost. To me, "texinfo format" is the format of (say)=20 doc/lispref/intro.texi. But I can check that for readability as I edit=20 it. The problem is that I also need to check the info-format output,=20 which is in info/elisp.info. To do that, I need to run 'makeinfo',=20 which takes over a minute on my machine. True, I can often just as easily check the HTML output of 'makeinfo'=20 instead. But the HTML takes even longer to generate than the info=20 output does (78 seconds as opposed to 64 seconds on my machine), so=20 that's not a realistic alternative. > Isn't it possible to defer those issues to an advanced stage where the=20 > areas with documentation changes are checked ``en-masse'' instead of=20 > checking one change at a time?=20 That's less efficient. When I'm making a change I'm conscious of it and=20 can check it easily. If I (or worse, someone else) checks it several=20 months later, it'll take them more time to get into the swing of things. More generally, it's not good practice for Emacs developers to check in=20 poorly-documented changes, and expect this to get fixed en masse later=20 in a documentation pass. It's better if a change results in a coherent=20 Emacs (code, documentation, tests, etc.) and is installed all at once=20 (perhaps as a merge commit). I realize this isn't always possible, but=20 still it's a good goal. Also, I realize that this policy hasn't always=20 been a goal in Emacs development, but that's something I'd like to see=20 changed as we move forward.