From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.devel Subject: Re: enriched-mode and switching major modes. Date: Mon, 20 Sep 2004 13:35:27 +0200 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1095680155 11780 80.91.229.6 (20 Sep 2004 11:35:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Sep 2004 11:35:55 +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 13:35:46 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 1C9MSQ-0001cw-00 for ; Mon, 20 Sep 2004 13:35:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9MYI-00074V-QA for ged-emacs-devel@m.gmane.org; Mon, 20 Sep 2004 07:41:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9MY7-00072Y-QN for emacs-devel@gnu.org; Mon, 20 Sep 2004 07:41:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9MY7-00071e-3u for emacs-devel@gnu.org; Mon, 20 Sep 2004 07:41:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9MY7-00071Z-0R for emacs-devel@gnu.org; Mon, 20 Sep 2004 07:41:39 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1C9MS9-00089b-Uo for emacs-devel@gnu.org; Mon, 20 Sep 2004 07:35:30 -0400 Original-Received: (qmail 12313 invoked by uid 65534); 20 Sep 2004 11:35:28 -0000 Original-Received: from dsl-082-083-129-246.arcor-ip.net (EHLO USER-2MOEN8BWBA.gmx.de) (82.83.129.246) by mail.gmx.net (mp026) with SMTP; 20 Sep 2004 13:35:28 +0200 X-Authenticated: #1497658 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun, 19 Sep 2004 20:05:53 -0400") X-Attribution: os X-Face: "HgH2sgK|bfH$; PiOJI6|qUCf.ve<51_Od(%ynHr?=>znn#~#oS>",F%B8&\vus),2AsPYb -n>PgddtGEn}s7kH?7kH{P_~vu?]OvVN^qD(L)>G^gDCl(U9n{:d>'DkilN!_K"eNzjrtI4Ya6; Td% IZGMbJ{lawG+'J>QXPZD&TwWU@^~A}f^zAb[Ru;CT(UA]c& User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt) 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:27319 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27319 Richard Stallman writes: [...] > - 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. [...] I don't think that looking at indentation and newlines could at any rate be enough for something as complex as a WP document. Where word wrapping happens to take place is insignificant in WP documents. It might happen at very different places when I change the font or send the document to somebody else or even when I adjust only the size of the window. When writing Lisp functions to examine and change the text, then I have nothing gained here. On the contrary, I have to take extra care that my functions will ignore those characters. > 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. I agree wholeheartedly. And I have quite some ideas here, which are not fully worked out, though. We need something by which Lisp can access the content of such a document syntactically. For example: a Lisp program might have to access all paragraphs of the type "Headline" that contain the string "foobar" and make changes there. In short: I intend to make the whole /abstract/ document accessible as a Lisp object in a structured way. [...] > 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. I honestly can't think of any implementation---save the heuristical one---that could work with `fill-paragraph' (because whatever data structure we use, `fill-paragraph' will have to examine properties that belong to the whole paragraph). > This implementation makes all kinds of cursor motion commands, and > commands that only look at the buffer contents, do the right thing. In the implementation designs that I favour (for reasons we are currently discussing), only `next-line' and `previous-line' would continue to do the right thing. [...] > (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)))) Agreed. > 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. Ah, maybe I start to understand what you mean: depending on a minor mode, `fill-paragraph' would add that text property, when it determines that a paragraph should be indented. I agree that it would work, then, for that particular problem. I can't say that I like this UI, but it could work. I am not sure yet, though, whether it would scale well---or scale at all---to other paragraph formatting properties. But let's discuss that other problem first: > 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.) Consider this HTML fragment:

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

In RTF it is a bit more complicated. Each paragraph may specify a stylesheet that defines both character formatting properties (font, font size, colour ...) applying to the whole of the paragraph text, as well as paragraph formatting properties proper such as left/right indentation, first line indentation, line spacing, space before/after the paragraph ... In addition to that each paragraph may specify each single one of these properties directly, thus overriding the defaults of the stylesheet. This has to be resolved not only when encoding the file, but also at, so to say, editing time, when filling or applying faces. In XML it will get even more complicated, since we can have nested paragraphs (nested block boxes), which I can not express with hard newlines alone. In fact the whole document here is tree-like; I have to conserve this in the data structure. Oliver -- Oliver Scholz Jour des Récompenses de l'Année 212 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M.