From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Tue, 16 Dec 2014 11:34:26 +0000 Message-ID: <87ppbjg75p.fsf@newcastle.ac.uk> References: <20141205123549.GA29331@thyrsus.com> <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> <5488C710.3000209@cs.ucla.edu> <871to7ayv9.fsf@wanadoo.es> <5488DC0C.2070402@cs.ucla.edu> <837fxyt78a.fsf@gnu.org> <87iohiujcy.fsf@Gertrud.fritz.box> <8761dg1ykk.fsf@Gertrud.fritz.box> <87388jz1ss.fsf@Gertrud.fritz.box> <87oar4x0ac.fsf@Gertrud.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418729706 25728 80.91.229.3 (16 Dec 2014 11:35:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Dec 2014 11:35:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 16 12:34:59 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 1Y0qP2-0007Wd-6b for ged-emacs-devel@m.gmane.org; Tue, 16 Dec 2014 12:34:56 +0100 Original-Received: from localhost ([::1]:44179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0qP1-0006ou-Pz for ged-emacs-devel@m.gmane.org; Tue, 16 Dec 2014 06:34:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0qOf-0006od-PS for emacs-devel@gnu.org; Tue, 16 Dec 2014 06:34:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0qOa-0000eH-GM for emacs-devel@gnu.org; Tue, 16 Dec 2014 06:34:33 -0500 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:54230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0qOa-0000dM-B0 for emacs-devel@gnu.org; Tue, 16 Dec 2014 06:34:28 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1Y0qOZ-0004ib-EX; Tue, 16 Dec 2014 11:34:27 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Y0qOZ-0005OK-CR; Tue, 16 Dec 2014 11:34:27 +0000 In-Reply-To: <87oar4x0ac.fsf@Gertrud.fritz.box> (Achim Gratz's message of "Mon, 15 Dec 2014 18:58:35 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.22 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:180196 Archived-At: Achim Gratz writes: > Richard Stallman writes: >> > Yes, but turning the tables: what exactly are the requirements for a GNU >> > documentation format? >> >> It has to have all the features offered by Texinfo, except that if you >> can show a certain Texinfo feature is hardly ever used by GNU manuals, >> maybe it can be omitted. > > So in essence you're saying that the requirement is semantic markup, but > you don't care about the syntax. This actually rules out quite a few of > the contenders discussed in this thread. Indeed by its very ature > semantic markup is intrusive as it often re-states something that is > obvious from context to the reader, for the sole purpose of making that > context explicit to some processing step later on. In that case, our > efforts might be better spent in developing ways to recognize such > context and injecting the semantic markup automatically. That makes sense. An org-mode based solution would be able to distinguish (and check) function names, so could add this semantics easily; a fall-back macro would probably still be needed for those cases where a function and variable name clash.