From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: karl@freefriends.org (Karl Berry) Newsgroups: gmane.emacs.devel Subject: Re: terminal escapes in Info files? Date: Tue, 28 Oct 2003 15:06:04 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310282006.h9SK64m06237@f7.net> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1067378634 6421 80.91.224.253 (28 Oct 2003 22:03:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2003 22:03:54 +0000 (UTC) Cc: eliz@elta.co.il, emacs-devel@gnu.org, rms@gnu.org, dirt@gtk.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Oct 28 23:03:50 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 1AEbwM-0005tr-00 for ; Tue, 28 Oct 2003 23:03:50 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEbwM-0000DI-00 for ; Tue, 28 Oct 2003 23:03:50 +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 1AEbYN-0001QV-O3 for emacs-devel@quimby.gnus.org; Tue, 28 Oct 2003 16:39:03 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AEbXz-0001PX-Ae for emacs-devel@gnu.org; Tue, 28 Oct 2003 16:38:39 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AEbXT-000181-E7 for emacs-devel@gnu.org; Tue, 28 Oct 2003 16:38:38 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AEbSL-0006In-Sc; Tue, 28 Oct 2003 16:32:49 -0500 Original-Received: from [209.61.216.22] (helo=f7.net) by mx20.gnu.org with esmtp (Exim 4.24) id 1AEbRP-0005Sx-HQ; Tue, 28 Oct 2003 16:31:51 -0500 Original-Received: (from karl@localhost) by f7.net (8.11.7-20030920/8.11.7) id h9SK64m06237; Tue, 28 Oct 2003 15:06:04 -0500 Original-To: monnier@IRO.UMontreal.CA 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:17526 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17526 But by switching to something like enriched-mode, After a bit thought, I think we can't "switch" to enriched mode, exactly, because of the compatibility problem. We could write enriched text as a new output format, and maybe in five years or so make it the default. I guess the question is: how much work would it require to take the subset of HTML generated by makeinfo and render it (both in M-x info and in the info program) ? As for the info program goes, it would be tantamount to writing a new program. I guess some of the screen display stuff could be reused. But in any case, I definitely wouldn't bother doing this. Instead, I'd just tell people to use lynx or emacs-w3 or whatever. I've never really seen the point of standalone info in the first place, as I've mentioned before. But some people like it, so fine. Also, makeinfo's html output is very very far from ideal. (texi2html does a better job, sadly.) So it wouldn't be a good design to implement only the html being output now. I suspect it would end up needing to be close to a full-fledged html interpreter, for the same reasons that you surmise enriched text would eventually not be enough. why enhance the Info format rather than change the readers (to use the HTML output of makeinfo rather than the Info output) ? 1) Because that is a huge change with many ramifications. 2) Because anyone who wants to can already do that. If you or anyone want to write or improve HTML readers for makeinfo's html output, great. That can be done independently of changing existing Info files. 3) [the main point] Because Info is terminal-based. Therefore, it makes sense to add capabilities to Info format which can be expressed on terminals -- namely, standard terminal escape sequences. This is where we came in. Inventing an entirely new output format, or using html as you suggest, may well be a worthwhile goal, but it is very long term and will take a lot of effort. By contrast, getting the principal two existing Info readers to understand ANSI escape sequences is very little work by comparison, has no compatibility issues, and could immediately improve the info-browsing experience. One more msg coming up ...