From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alper Ersoy Newsgroups: gmane.emacs.devel Subject: Re: terminal escapes in Info files? Date: Thu, 30 Oct 2003 12:42:38 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20031030104238.GA11503@dirtyweb.penguinpowered.com> References: <200310280126.h9S1Q9N16202@f7.net> <20031028105102.GA7330@dirtyweb.penguinpowered.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067510698 24454 80.91.224.253 (30 Oct 2003 10:44:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Oct 2003 10:44:58 +0000 (UTC) Cc: eliz@elta.co.il, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Oct 30 11:44:55 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AFAIR-0000lE-00 for ; Thu, 30 Oct 2003 11:44:55 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AFAIR-0002Qj-00 for ; Thu, 30 Oct 2003 11:44:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AFAI9-0007EI-Q1 for emacs-devel@quimby.gnus.org; Thu, 30 Oct 2003 05:44:37 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AFAI3-0007Du-SD for emacs-devel@gnu.org; Thu, 30 Oct 2003 05:44:31 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AFAHX-00071N-Lb for emacs-devel@gnu.org; Thu, 30 Oct 2003 05:44:30 -0500 Original-Received: from [212.253.50.183] (helo=dirtyweb.penguinpowered.com) by monty-python.gnu.org with smtp (Exim 4.24) id 1AFAHV-0006zO-1u for emacs-devel@gnu.org; Thu, 30 Oct 2003 05:43:58 -0500 Original-Received: (qmail 12193 invoked by uid 500); 30 Oct 2003 10:42:38 -0000 Original-To: Oliver Scholz Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17612 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17612 Hi! Oliver Scholz: > Most notably the markup could be syntactical rather than specifying > the colours to use. I *hate* it, if a document tells me the best > colour for me to read a certain syntactic element. Let the document > specify the syntactical element and let me customize the colour. Ok. If we lean towards a syntactical markup, it should _also_ specify the best colour, typeface, etc. too. We must do this, otherwise whenever there's a new command in Texinfo, readers will be unaware of how to handle it. Something like (notation aside): ^H^[var bi^H^]Variable^H^[/var^H^] So it's bold-italic. But you (info reader) know it's a var, so you can use whatever style you want. Sometime in the future, when we have this @funky command: ^H^[funky sb,red^H^]Art Vandelay^H^[/funky^H^] You don't know what a funky text is, but you can use the style provided there. However, I suggested ANSI escapes in the first place because of the star characters around strong text. One can use @strong only, and still get a flowing text in display environments supporting bold typeface. Not with Info though. Introducing syntactical markup elements is IMHO burning your blanket because of one flea. The only way to justify changes this level is to also identify the other problems in Info, and to address them all at once, then declare it as Info2. After all, we are breaking compatibility here, so it _must_ have to offer more. Currently though, Info serves as the 'final destionation of documents.' So what's wrong with using a widely adopted and frozen standard? (ECMA-48) > Another old wish of mine is that the info format could specify the > type of code, for example (I am using an XML-like notation here, > because I am not familiar with the info file format): This has to be addressed in Texinfo first. Admittedly, I could never understand @lisp. Why not @example lisp ... @end example @example C++ ... @end example Like @itemize, @example can accept an optional parameter. @lisp can be an alias to ``@example lisp'' internally. What do you think? Info doesn't have to format each of these differently, so makeinfo can omit the rest of @example lines. However, HTML and XML backends can clearly make use of this information. -- Alper Ersoy