From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Sun, 19 Sep 2004 20:05:53 -0400 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> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1095638865 29728 80.91.229.6 (20 Sep 2004 00:07:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Sep 2004 00:07:45 +0000 (UTC) Cc: boris@gnu.org, emacs-devel@gnu.org, alex@emacswiki.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 20 02:07:39 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 1C9BiU-0005hT-00 for ; Mon, 20 Sep 2004 02:07:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9BoL-0005xH-Gb for ged-emacs-devel@m.gmane.org; Sun, 19 Sep 2004 20:13:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9Bmu-00054l-5t for emacs-devel@gnu.org; Sun, 19 Sep 2004 20:12:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9Bmo-000506-82 for emacs-devel@gnu.org; Sun, 19 Sep 2004 20:12:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9Bmo-0004za-5c for emacs-devel@gnu.org; Sun, 19 Sep 2004 20:12:06 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9Bgo-0007w0-GH for emacs-devel@gnu.org; Sun, 19 Sep 2004 20:05:54 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C9Bgn-0000GP-Mw; Sun, 19 Sep 2004 20:05:53 -0400 Original-To: Oliver Scholz In-reply-to: (message from Oliver Scholz on Sat, 18 Sep 2004 18:57:13 +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:27294 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27294 Exactly! However, it is important to discuss implementation issues together with the user interface concepts in order to account for the semantics of the representation. I agree we need to discuss them both; the point is, they are not the same question. They are related questions. - The semantics of space characters used to implement a box model and space chars used for indentation in a non-WP Emacs buffer (like in this message buffer in this paragraph) are different. The former don't belong to the abstract document, they are only a means of rendering it visually. I agree they would be a means of rendering the box, but not just a way of rendering it visually. They would be a way of rendering it for the Lisp world. Most programming languages have a textual representation and a behavior. Lisp is different: everything has a textual representation, a Lisp object representation, and a behavior. When designing a Lisp construct, or any Lisp data, one must think about all three levels. Because of Lisp, a similar thing happens for text in an Emacs buffer. In a typical word processor, text has a visual appearance and a way it is saved in a file, that's all. In Emacs, text has a visual appearance, a way it is saved in a file, and the way it appears as Lisp data. We have to design all three. The visual rendering of paragraph indentation on the screen could be the same, regardless of whether the buffer contains space characters. And the file representation can also be the same (no space characters for indentation there). Despite that, it makes a difference what the buffer contains. Because of this semantic difference, existing Emacs Lisp functions would not do the right thing when working on them. I wouldn't expect them either to do the right thing. `fill-paragraph' does not work well in a dired buffer. `query-replace' does not work in a Gnus *group* buffer. fill-paragraph would do exactly the right thing with these spaces. Of course, we would tell it to treat them as the fill prefix in such a paragraph. This feature *already* exists and works this way. This implementation makes all kinds of cursor motion commands, and commands that only look at the buffer contents, do the right thing. - Even when working with space characters for indentation, it would probably not be as you seem to expect. When working on a graphical user interface, we would have to deal with proportional fonts of varying sizes. Yes, this will make matters harder. We will need to use some spaces that have only partial width, or something like that. (progn (switch-to-buffer (generate-new-buffer "*tmp*")) (insert (propertize " " 'display '(space :align-to 20))) (insert (propertize "lirum larum" 'face '(face :height 140 :inherit variable-pitch)))) Why not this? (progn (switch-to-buffer (generate-new-buffer "*tmp*")) (insert-char ?\s 3) (insert (propertize " " 'display '(space :align-to 20))) (insert (propertize "lirum larum" 'face '(face :height 140 :inherit variable-pitch)))) supposing that aligning to pixel 20 means 3 and a fraction spaces? However, even having one very wide space to represent the indentation is better than having none at all. That one space will at least show Lisp code that some indentation is present. But if we want to implement XML/HTML + CSS (and I definitely want), then some nested boxes with borders and background colours are not possible to display, but it would be an understatement that implementing a way to let the user interact with them (for example by typing text) would be "difficult". I won't argue with this statement, but I don't know what cases you mean. How do you want to solve the problem of distinguishing manually inserted spaces from spaces added programatically for visual rendering when the document is encoded and written to a file? With text properties. That is how we distinguish hard and soft newlines now. Hard newlines represent user-specified breaks, and are saved as such; soft newlines are meant to be recomputed. We could have hard and soft spaces too. About newlines: I have thought about using hard newlines for paragraph separation. The problem is that I need a place to store properties belonging to the whole paragraph. Those should be stored on all the text of the paragraph, right? What are the jobs you want to do with these properties? What is the semantics? (One example may be enough.)