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: Tue, 21 Sep 2004 14:30: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> <01c49c75$Blat.v2.2.2$7a37cb00@zahav.net.il> <01c49d70$Blat.v2.2.2$f7cfb860@zahav.net.il> <01c49da7$Blat.v2.2.2$cd5f7160@zahav.net.il> <01c49dc6$Blat.v2.2.2$3b624d40@zahav.net.il> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1095791653 17440 80.91.229.6 (21 Sep 2004 18:34:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Sep 2004 18:34:13 +0000 (UTC) Cc: boris@gnu.org, eliz@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 21 20:34:03 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 1C9pSl-0001jq-00 for ; Tue, 21 Sep 2004 20:34:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9pYh-0006pT-EB for ged-emacs-devel@m.gmane.org; Tue, 21 Sep 2004 14:40:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9pWc-0005lh-IR for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:38:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9pWY-0005jO-G2 for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:37:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9pWW-0005gA-Mo for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:37:56 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9pPi-00041q-4U for emacs-devel@gnu.org; Tue, 21 Sep 2004 14:30:54 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1C9pPh-0005DY-Gz; Tue, 21 Sep 2004 14:30:53 -0400 Original-To: Oliver Scholz In-reply-to: (message from Oliver Scholz on Mon, 20 Sep 2004 13:48:05 +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:27382 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27382 When rendered by a graphical, CSS2-enabled browser, you'll see two paragraphs on a gray background sourounded by a dashed border. Those two paragraphs are again contained in a larger paragraph on a purple background surounded by a solid border. It will be very hard to implement this in a way that fits in with Emacs. The text property feature has been designed to work well with all kinds of commands that copy text. What makes it work well is that text properties are per character. So if you copy each character with its properties, everything works ok. Emacs primitives that copy text all do this. I am not sure how to represent nested blocks with per-character text properties. In principle we could have other kinds of data associated with the text to supplement text properties, but what could we design that would fit in properly with cut and paste? What does it *mean* to copy a character from inside environment `larum' which is inside environment `lirum' and insert it somewere else? What should that character look like in its new location? One possible approach is to use markup characters, put the properties on the markup characters (or express them in the text), and make these markup characters more or less invisible in formatted display mode. Then we would use text props only for fontification, etc., within a paragraph. However, it is worth doing this only if the result is an improvement. I'm not sure of that. For instance:

Some meaningless heading

The element maps directly to text properties, of course. But the h1 element both demands that its contents be rendered as a paragraph (a block) /and/ specifies certain character formatting properties for the whole of it, e.g. a large bold font. When encoding a buffer, I need to identify the whole paragraph as being of the type "h1". I.e. I have to distinguish it from:

Some meaningless heading

Why do you have to distinguish them? Why wouldn't it work simply to put these properties on the whole text of the paragraph? What aspect would work differently as a result of doing one or the other, and why is it better if the properties are attached to paragraphs? We have to deal with the case that a user deletes the hard newline (if you evaluate the code above: just hit backspace). Is the resulting paragraph of type `h1' or of type `h2'? Why ask the question? Why not just accept that it's a paragraph of partly h1 text and partly h2 text? I don't think that looking at indentation and newlines could at any rate be enough for something as complex as a WP document. It's a matter of what the specific command does. We're talking about commands not written specifically for word-processing documents, general-purpose code.