From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Wed, 10 Dec 2014 22:51:35 +0200 Message-ID: <83wq5ztei0.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1418244752 23981 80.91.229.3 (10 Dec 2014 20:52:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Dec 2014 20:52:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 10 21:52:25 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 1XyoFE-0002ih-Pp for ged-emacs-devel@m.gmane.org; Wed, 10 Dec 2014 21:52:24 +0100 Original-Received: from localhost ([::1]:47905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyoFE-0000WD-FM for ged-emacs-devel@m.gmane.org; Wed, 10 Dec 2014 15:52:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyoEc-0008UO-PX for emacs-devel@gnu.org; Wed, 10 Dec 2014 15:51:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyoEW-0004yU-54 for emacs-devel@gnu.org; Wed, 10 Dec 2014 15:51:46 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:33546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyoEV-0004yK-TV for emacs-devel@gnu.org; Wed, 10 Dec 2014 15:51:40 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NGD00K00W40JJ00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 10 Dec 2014 22:47:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGD00BSXWEYZ180@mtaout25.012.net.il>; Wed, 10 Dec 2014 22:47:22 +0200 (IST) In-reply-to: <87r3w7b83a.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:179703 Archived-At: > From: =D3scar Fuentes > Date: Wed, 10 Dec 2014 20:47:21 +0100 >=20 > > Problems with looks often include > > fairly-mundane things like a capitalized word at sentence end whi= ch > > messes up later spacing, things which one can easily see when loo= king > > at the info output, but which one can't easily expect a text edit= or to > > catch. >=20 > Isn't it possible to defer those issues to an advanced stage where = the > areas with documentation changes are checked ``en-masse'' instead o= f > checking one change at a time? If you push unchecked changes, and they cause errors, you might confuse people or even break the build. So I always generate the doc= s before committing any documentation changes, even the smallest ones.