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: Thu, 18 Dec 2014 17:50:07 +0200 Message-ID: <83d27hufdc.fsf@gnu.org> References: <20141205123549.GA29331@thyrsus.com> <2815659.zRQ0WWWeRr@descartes> <20141205175810.GD3120@thyrsus.com> <87wq66ufyt.fsf@wanadoo.es> <87zjb04tlw.fsf@gmx.us> <87bnnfve9c.fsf@dod.no> <871to5kt1a.fsf@newcastle.ac.uk> <87y4q8yi4j.fsf@newcastle.ac.uk> <871tnywkjt.fsf@newcastle.ac.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418917868 28661 80.91.229.3 (18 Dec 2014 15:51:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 15:51:08 +0000 (UTC) Cc: phillip.lord@newcastle.ac.uk, sb@dod.no, rms@gnu.org, kyle.c.andrews@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 18 16:51:00 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 1Y1dLw-0003iP-7z for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 16:51:00 +0100 Original-Received: from localhost ([::1]:54520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dLv-0003rI-Lt for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 10:50:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dLG-0003KI-V3 for emacs-devel@gnu.org; Thu, 18 Dec 2014 10:50:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1dLC-0002Y2-EN for emacs-devel@gnu.org; Thu, 18 Dec 2014 10:50:18 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:42882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1dLC-0002Xd-6E; Thu, 18 Dec 2014 10:50:14 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NGS00500BQ7NJ00@a-mtaout22.012.net.il>; Thu, 18 Dec 2014 17:50:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGS005FWBZN7XA0@a-mtaout22.012.net.il>; Thu, 18 Dec 2014 17:50:12 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:180280 Archived-At: > From: Stefan Monnier > Date: Thu, 18 Dec 2014 09:14:27 -0500 > Cc: emacs-devel@gnu.org, Phillip Lord , sb@dod.no, > kyle.c.andrews@gmail.com > > >> @node Abbrevs > >> @chapter Abbrevs > > Nodes and sections typically go together but not always. > > It is true we could make the usual case simpler by changing the > > defaults. > > Further than that I think it would be worth analyzing the cases where > the @nodes can't be automatically inferred from the @chapters/@sections, > and try and figure out how to handle them (or whether it's worth the > trouble) without using an explicit @node. We can do that by removing markup from the section names. > >> @menu > >> * Abbrev Concepts:: Fundamentals of defined abbrevs. > >> * Defining Abbrevs:: Defining an abbrev, so it will expand when typed. > >> @end menu > > This is like the above issue: in the usual case, the node names in the menu > > can be deduced from the rest of the document, but there are menus which > > differ from that. > > Here as well, I think it'd would be worthwhile to analyze the existing > cases where the node names in the menu can't be deduced from the rest of > the document You mean, like texinfo-make-menu? > and try to see how we could handle them without having to > have explicit menus or even if it's worth the trouble supporting those > at all. Having menus is not a requirement, you can do without them. > > However, the second part of each line (the text like "Fundamentals of > > defined abbrevs") can't be found anywhere else. > > Here, rather than suggest to analyze the existing cases, I'll just point > out that pretty much the rest of the world lives happily without being > able to use two different texts, so I'm not sure it's worth the trouble. Again, it's not a requirement. If you want to add descriptive text, you can; but you don't have to.