From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Thu, 18 Dec 2014 09:14:27 -0500 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418912105 26748 80.91.229.3 (18 Dec 2014 14:15:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 14:15:05 +0000 (UTC) Cc: emacs-devel@gnu.org, Phillip Lord , sb@dod.no, kyle.c.andrews@gmail.com To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 18 15:14:57 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 1Y1bqz-0003bP-2H for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 15:14:57 +0100 Original-Received: from localhost ([::1]:54111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1bqy-0002XV-5A for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 09:14:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1bqe-0002XC-Ri for emacs-devel@gnu.org; Thu, 18 Dec 2014 09:14:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1bqX-0003HL-Az for emacs-devel@gnu.org; Thu, 18 Dec 2014 09:14:36 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1bqX-0003GY-7P; Thu, 18 Dec 2014 09:14:29 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskIAOwQflTO+ILA/2dsb2JhbABbgweDYMp3BAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLDiYSFBgNJIhKCdZZAQEBBwEBAQEBHZBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IPAS-Result: AskIAOwQflTO+ILA/2dsb2JhbABbgweDYMp3BAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLDiYSFBgNJIhKCdZZAQEBBwEBAQEBHZBvB4RIBYsBpC6BeIQZIYJ3AQEB X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="102885132" Original-Received: from 206-248-130-192.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Dec 2014 09:14:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B97112D79; Thu, 18 Dec 2014 09:14:27 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Thu, 18 Dec 2014 06:24:11 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.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:180271 Archived-At: >> @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. >> @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, 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. > 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. > section structure. But where would it get that added text from? If we really want to have 2 different ways to describe the node in the menu, we could use "the node name" and "the section title". Currently, Texinfo has typically 3 different descriptions for every node: @menu * :: @end menu ... @node @section in 99% of the cases, we could use the exact same text for , , and . But in 100% of the cases, we could at least drop one of the three. Stefan