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: Wed, 15 Sep 2004 11:42:52 -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 1095263036 16016 80.91.229.6 (15 Sep 2004 15:43:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Sep 2004 15:43:56 +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 Wed Sep 15 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 1C7bwb-00018F-00 for ; Wed, 15 Sep 2004 17:43:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C7c2E-0001sE-Fo for ged-emacs-devel@m.gmane.org; Wed, 15 Sep 2004 11:49:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C7c1r-0001k5-H9 for emacs-devel@gnu.org; Wed, 15 Sep 2004 11:49:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C7c1q-0001jl-Oi for emacs-devel@gnu.org; Wed, 15 Sep 2004 11:49:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C7c1q-0001jU-Lr for emacs-devel@gnu.org; Wed, 15 Sep 2004 11:49:06 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C7bvq-0001Wj-1u for emacs-devel@gnu.org; Wed, 15 Sep 2004 11:42:54 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C7bvo-0001KU-0L; Wed, 15 Sep 2004 11:42:52 -0400 Original-To: Oliver Scholz In-reply-to: (message from Oliver Scholz on Tue, 14 Sep 2004 16:41:25 +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:27137 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27137 The hairy part is whitespace formatting. The problems arise from the fact that I can't tell Emacs: "Display this text from position POS1 to POS2 as a paragraph with a left margin of 20 pt and a right margin of 40 pt with 20 pt above and below -- *without* adding any character to the buffer." The idea of Emacs is that the appearance is represented by text in the buffer. We designed text properties so that the text in th ebuffer could be something more than a sequence of characters. Any extensions have to preserve this principle, or we will lose the benefits of Emacs. If Emacs' display engine would support this, e.g. as a `block' text property, then I could write: (progn (switch-to-buffer (generate-new-buffer "*tmp*")) (insert "Example text. Example paragraph. Example text.") (put-text-property 15 33 'block '(:margin (4 1 1 1) :border nil :padding nil))) If the block parameters are specified as a text property on the entire contents of the block, that might solve the problem. However, there are some details here that are nontrivial problems. 1. How to distinguish between two similar boxes with the same specs and a single longer box. 2. How to represent line breaks. Saying "break one long line at display time" would work ok for display, but all the commands that operate on lines would see just one long line there. 3. How to represent indentation. If the indentation appears only in redisplay, Lisp code that looks at the text will think it is not indented at all. I think we need to look for a hybrid solution where there could be a text property saying how this box is supposed to look, but that works by inserting newlines, indentation, etc., so that the text can be seen in Lisp without need to decode the box. If Emacs display engine would support a block model, we would just tell the display engine how to render the paragraphs. There is not a single newline chars and no space between paragraphs that would be part of the character data. I.e. `(buffer-substring-no-properties (point-min) (point-max))' would return: "Lirum larum (A headline)\"Mariage is the chief cause of divorce.\"\ This is just ordinary paragraph text. Nothing special here. This is\ a list item. It contains two subitems:One and Two This is another \ list item." This model fails to address those problems. It would work as a way of grafting a separate word processing facility into Emacs, but it would not integrate well with the existing Emacs Lisp world. However, later you talk about an implementation more like what I have in mind, where the boxes and lists would be rendered by changing the buffer text; therefore, the buffer text would show what's really there. I mean "the document's character data" here. The important point is that formats suitable for WP (RTF, HTML ...) separate character data from formatting information entirely. My point is that this is exactly what we must not do in Emacs, lest it ruin everything in a subtle way. However, about one thing I am positiv: there is absolutely no room for a minor mode here. That's why I say that enriched-mode (as a minor mode) is a dead end. I don't see that that follows from the rest of your points.