From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: Changes to Texinfo DTD Date: Sun, 23 Nov 2003 12:14:10 -0500 (EST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <8765heixvu.fsf@kanga.tapsellferrier.co.uk> <87ptfkdqss.fsf@kanga.tapsellferrier.co.uk> <20031122214251.GA14680@fencepost> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1069607972 20929 80.91.224.253 (23 Nov 2003 17:19:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2003 17:19:32 +0000 (UTC) Cc: bob@rattlesnake.com Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Nov 23 18:19:28 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 1ANxtQ-0000Nj-00 for ; Sun, 23 Nov 2003 18:19:28 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ANxtQ-0001fV-00 for ; Sun, 23 Nov 2003 18:19:28 +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 1ANypA-0000uy-Jh for emacs-devel@quimby.gnus.org; Sun, 23 Nov 2003 13:19:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ANyp3-0000us-IQ for emacs-devel@gnu.org; Sun, 23 Nov 2003 13:19:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ANyoW-0000cg-83 for emacs-devel@gnu.org; Sun, 23 Nov 2003 13:18:59 -0500 Original-Received: from [140.186.114.245] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ANyoN-0000JX-LQ for emacs-devel@gnu.org; Sun, 23 Nov 2003 13:18:20 -0500 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 23 Nov 2003 12:14:10 -0500 (EST) Original-To: emacs-devel@gnu.org In-reply-to: <20031122214251.GA14680@fencepost> (message from Miles Bader on Sat, 22 Nov 2003 16:42:51 -0500) 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:18058 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18058 Miles Bader wrote The main question in my mind is whether this would be fast enough -- the current info mechanism, though it has its problems, can display info pages very quickly. Yes, you are right. The goal is to provide an alternative to Info that is as efficient as Info and as fast. This will help both those who prefer the markup they see in Web browsers to what they get in Info, and those who use Web browsers, such as Mozilla, for reading documentation. (And as a side effect, it may inspire people to improve W3 mode or another Web browser for Emacs.) Right now, it is impossible for any HTML mechanism to be as efficient as Info, since (as a practical matter) HTML lacks the concept of `one document in many files'. HTML runs via a `one document in one file' schema. (I am told that in theory a hypertext link can point to one document that is spread over several files, but I have never seen this.) Moreover, a browser, such as Mozilla 1.0, lacks even a regexp search mechanism for navigating within one page! However, HTML does have a great advantage over Info: HTML is designed for the situation in which the rendering computer is separated from the server by a slow connection. Info depends on a fast connection between the rendering machine and the source of the Info file. Indeed the Info file is often on a disk on the rendering machine; if not, it is connected via a fast NFS or similar link. Here are the two topologies: Info: fast rendering fast terminal/display --- or --- computer --- connection --- Info source slow only connection \________ often one computer __________/ HTML: fast fast rendering or terminal/display --- connection --- computer ---- slow ---- Web server connection \____________ often one computer __________/ \______ often two computers ______/ connected over the Internet On my current connection, it takes 17 minutes to download the Emacs Lisp Reference Manual. There is no way I would wait that long before beginning to browse the manual remotely. For remote use, the manual needs to be divided into smaller files, as Texinfo files are now when converted to HTML. Moreover, even with splitting, a search will take too long, unless the search regexp is sent to the remote site. I mention search because `Info-search' is still the most efficient way to navigate through a GNU manual. String searches through a complete document (and indices) are very helpful, but simply not good enough. Consequently, both to help documentation readers who want the kind of markup they see in a Web browser, and also to help those who want to read their documentation over the Internet via a slow connection, current HTML needs to be improved in two ways: 1. The Texinfo to HTML conversion process needs to ensure that key bindings as well as mouse bindings exist for moving from one node to another, for index lookups, etc., for a document that is spread over several files. Without keybindings, you have to move the mouse, which is fine for novices or those who don't mind spending their time doing so, but which is not as efficient as simply pressing the spacebar or other key, regardless where point is. This can be done by providing the document as one or more HTML pages, appropriately chunked and formatted and with Javascript for the keybindings. Nothing need be done to the Web server. 2. The Web server needs a CGI that enables regular expression searches/navigation through a single document split among several files. Info has the wonderful `Info-search' command, usually bound to `M-s'. This feature provides the equivalent. Since whole documents are often large -- as I said, the Emacs Lisp Reference Manual takes me 17 minutes to download -- and HTML works by downloading files that are then rendered, the only way to provide quick regular expression search and navigation is by sending only a search command, such as an `s', to the Web server, and having the Web server run the search itself. This feature does require adding a module to the Web server. This is difficult, since only some Web masters will provide the added convenience. However, it is easy to install CGI scripts on Apache. If the master of the Web server has not installed the CGI script, then the Javascript in the Texinfo HTML file tell the user that the Web server to which he or she is connected is lacking. And perhaps, eventually, the people who distribute Apache will be persuaded to include this module with the others, as part of their standard distribution. I think the far more difficult issue is learning by people who want to make use of efficient searches and navigation. Partly, the difference is preference; but partly the difference is learning. The kind of efficiency provided by Info is beyond most people's dreams -- they do not even imagine that an equivalent of `Info-search' could be useful. It does not occur them to learn. Consquently, for many of the people who want to take advantage of their computer, fundamental relearning is required. (For others it is preference, as I said. Indeed, some people who use Info do not much use `Info-search'.) On the other hand, Info was not designed for the kind of network we now have, in which people have their own rendering machines, but download files from a Web server over a slow connection. Info was designed for a network in which the connection between a display or terminal and the rendering machine may be over a slow connection, but the connection between the rendering machine and the disk providing the Info files is fast. Put another way, both Info and HTML have deficiencies. The goal here is make use of HTML's features and add those needed to match Info. Next, the problem will be to encourage writers to write for all potential users, not only those who look at documentation on a high resolution/fast redisplay screen: to write for people driving cars or otherwise blind, to write for those working over a really slow connection, to write for those using limited equipment. For example, people are going to listen to documents spoken to them over a cell phone while they drive a car. Currently, Texinfo files tend to be written for such people, but I see more and more use of @image without an alternative for those who do not want images. But that is a problem for another day. -- Robert J. Chassell Rattlesnake Enterprises http://www.rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.teak.cc bob@rattlesnake.com