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: Fri, 17 Sep 2004 19:22:56 -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 1095463569 25873 80.91.229.6 (17 Sep 2004 23:26:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Sep 2004 23:26:09 +0000 (UTC) Cc: boris@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 18 01:26:00 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 1C8S76-0003id-00 for ; Sat, 18 Sep 2004 01:26:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8SCq-0003ol-Jb for ged-emacs-devel@m.gmane.org; Fri, 17 Sep 2004 19:31:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8SA1-0002TW-6W for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:29:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8S9y-0002S5-S2 for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:28:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8S9y-0002Ru-CN for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:28:58 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8S49-00084l-Lq for emacs-devel@gnu.org; Fri, 17 Sep 2004 19:22:57 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C8S48-0001Jf-Fq; Fri, 17 Sep 2004 19:22:56 -0400 Original-To: Oliver Scholz In-reply-to: (message from Oliver Scholz on Thu, 16 Sep 2004 19:04:53 +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:27208 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27208 The distinction between character data and formatting information, mentioned in the paragraph you quoted, is inherent in the type of documents we discuss here. You can enter as many newline characters in the source of an RTF document as you want, an RTF reader will simply remove them. That is not relevant to the issue, as it concerns the detailed specifications of RTF format, rather than the detailed specifications of Emacs' internal representation. We can easily implement this behavior in the format translators for RTF, but it doesn't really relate to the issue here. Instead the user says: "This piece of text is a paragraph, because I hit RET when I finished writing it. I want it to be a paragraph of the type "Standard Text". I want "Standard Text" paragraphs to be indented on the left by 1 cm and to have a font size of 10 pt. Exept here, I want this paragraph to have an indentation of 2 cm." Now you're talking about the user interface concepts. That too is distinct from the question of representing text inside Emacs. The Emacs text representation needs to include a representation of the specification of a type of paragraph, in order to implement this user interface. But it also needs to have spaces in the buffer where there is indentation, so as to be compatible with how the whole Emacs Lisp world understands indentation. a) For a given word processor application, two different documents could look exactly the same when rendered on the display. For instance, in the document there could be specified as a paragraph property that the first line of a paragraph should be indented by 1 cm. While in another document a user could get exactly the same visual effect by entering a number of space characters. It is probably inevitable that such indeterminacy will occur, but let's try to avoid it when we can. For instance, by keeping indentation expressed as paragraph style specifications in sync with indentation expressed as spaces in the buffer. b) For a given document, two different applications or the same application on two different machines/operating systems might render two different visual representations. This is not specifically a problem, and may even give us extra flexibility. This is very important: If a user enters space characters into an Emacs buffers, she wants there to be space characters. Those characters would have to become part of the character data in the encoded file. But if a user just specifies: I want this paragraph to be indented, then the space characters used to display the left margin _must_not_ become part of the encoded file. Why do you think so? It seems to me that these two different user actions should both produce spaces in the buffer--in one case, inserted manually, in the other, caused by the format specification. We can recompute line breaks automatically, and represent them by newline characters in the buffer, which will be removed and replaced by the next recomputation. In this mode, the user would not manually enter newline characters except to create breaks (hard newlines). Erm, what does the concept of "what's really there" in that context mean? In the buffer, or more generally spoken: in the data structure a containing block box, or a text property storing formatting information is, of course, no less there than any space or newline character added for whitespace formatting. Something is "really there" if other Lisp programs will see it in the way that they are written to look for it. It would be an heuristical approach. The encoding function (when saving to a file) could determin whether a paragraph (defined by its preceding and following newline characters) is indented by space characters. It could then write the nessary markup to the file accordingly. I agree with you there. I'm not suggesting anything like that.