Re: enriched-mode and switching major modes.

[Oliver Scholz <alkibiades@gmx.de>]

Richard Stallman <rms@gnu.org> 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:

<h1>Some <i>meaningless</i> heading</h1>

The <i> 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:

<p><font size=7><b>Some <i>meaningless</i> heading</font></p>

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.