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: enriched-mode and switching major modes. Date: Sat, 18 Sep 2004 11:37:43 -0400 (EDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409042358.i84Nwjt19152@raven.dms.auburn.edu> <87llfn5ihw.fsf@emacswiki.org> <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> <86vfec4ofc.fsf@ketchup.de.uu.net> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1095522233 32093 80.91.229.6 (18 Sep 2004 15:43:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2004 15:43:53 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 18 17:43:42 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C8hNG-000286-00 for ; Sat, 18 Sep 2004 17:43:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8hT2-00086j-HD for ged-emacs-devel@m.gmane.org; Sat, 18 Sep 2004 11:49:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8hSv-00086e-Rx for emacs-devel@gnu.org; Sat, 18 Sep 2004 11:49:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8hSv-00086S-4E for emacs-devel@gnu.org; Sat, 18 Sep 2004 11:49:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8hSv-00086P-0e for emacs-devel@gnu.org; Sat, 18 Sep 2004 11:49:33 -0400 Original-Received: from [69.168.110.189] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8hM7-0006b6-W4 for emacs-devel@gnu.org; Sat, 18 Sep 2004 11:42:32 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Sat, 18 Sep 2004 11:37:43 -0400 (EDT) Original-To: emacs-devel@gnu.org In-reply-to: <86vfec4ofc.fsf@ketchup.de.uu.net> (message from Kai Grossjohann on Fri, 17 Sep 2004 22:43:03 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:27229 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27229 As Kai Grossjohann said, Emacs already displays something that's different than what is present in the file Yes, indeed. For a high resolution, word-processor-style display, two questions arise. But first, a look at the past. Version 18 Emacs had: * the same rendering device (a character-only display screen) that used different Emacs rendering programs to produce differently displayed expressions of the same info formatted file; for example: in Emacs, find-file in Emacs, Info * different rendering devices (a character-only display screen, paper) that used different rendering programs, some not Emacs, to produce differently displayed expressions of the same DVI formatted file; for example: in Emacs, find-file not in Emacs, xdvi in X not in Emacs, printer * different conversion programs, some not Emacs, to produce different files from the same Texinfo formatted file; for example: in Emacs, texinfo-format-* to convert Texinfo to Info not in Emacs, tex to convert Texinfo to DVI Version 21 Emacs supports three rendering devices: * character-only display screen * bit-mapped display screen, as in X * sound device Two questions arise. In Emacs, in a bit-mapped display screen, as in X, should a future Emacs support a high resolution, word-processor-style display 1. by breaking current, basic Emacs design assumptions? This would require a different display engine, as `xdvi' or `mozilla' now are, but integrated within Emacs. Or, 2. by using current, basic Emacs design assumptions? This might mean using two new modules (which are perhaps seen by a novice user as making up one program, evoked as one Emacs command): * a module to convert from the deep representation or `encoded document file' to an intermediate representation containing, as Eli Zaretskii suggested, "a combination of characters and text properties, such that Lisp programs and C code that look at the buffer text could extract the layout information from that text alone" (This is similar to what `makeinfo --html' now does, with two exceptions: -- `makeinfo' is not part of Emacs, although two rendering programs, `find-file' and `w3' are a part; and, -- `makeinfo' creates a stand-alone output file rather than a temporary file used within Emacs.) * a module to render from the intermediate representation to the display, as `find-file' with Enriched mode or `w3' or Info now do, but with a more word-processor-like look. For read-only displays, either solution fits the single-deep-representation-input/multiple-surface-expression-outputs model I discussed on this list some time ago. However, people like to edit the various different surface expressions for paper, for a graphic display, and for a sound device, as well as the deep representation that holds them. So people prefer read-write capability. (A long time ago, I proposed a user interface design to handle the display of the results of a slow, asynchronous conversion program within Emacs without requiring the Emacs display to halt. For example, this design -- showing a moving `wave of change' in a scroll bar -- would enable an Emacs user both to view two parts of a long file, one near its beginning and the other near its end, and to edit them even after starting a `tex' update near the beginning and not have its changes progress to the end for many seconds.) -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc