Re: enriched-mode and switching major modes.

[Oliver Scholz]

address@hidden (Kim F. Storm) writes:

> Oliver Scholz <address@hidden> writes:
>
>> Consider this HTML fragment:
>>
>> <h1>Some <i>meaningless</i> heading</h1>
>>
>> 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:
>
> Maybe we can get some of the way with Emacs' category text properties?!
>
> In this case, you could put a 'category 'H1 text property on the heading.
[...]

<blush/> I have to admit that I have never thought of the `category'
property, instead I have always experimented with implementing its
functionality myself.  Thanks for the reminder.  This might indeed be
useful.

We still have have a problem if we mean to distinguish paragraphs by
hard newlines instead of a text property covering the region of
characters that make the content of the paragraph:

(progn (put 'h1 'face 'Info-title-1-face)
       (put 'h2 'face 'Info-title-2-face)
       (switch-to-buffer (generate-new-buffer "*tmp*"))
       (use-hard-newlines 1 'never)
       (insert (propertize "Lirum larum"
                           'category 'h1))
       (newline 1)
       (save-excursion
         (insert (propertize "lirum larum"
                             'category 'h2))))

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?  What about this:

(progn (put 'h1 'face 'Info-title-1-face)
       (switch-to-buffer (generate-new-buffer "*tmp*"))
       (use-hard-newlines 1 'never)
       (insert (propertize "lirum larum" 'category 'h1))
       (insert " lirum larum") ; no `category' property.
       (newline 1))

This might happen as the result of yanking something in.

To use the `category' property for paragraphs (blocks), we have to do
something like:

(progn (put 'h1 'block t)
       (put 'h1 'space-before XX)
       (put 'h1 'left-margin XX)
       etc. ...)

I can see four ways to deal with that.  The first two imply that we
ditch the semantics of hard newlines altogether in WP documents.
(`use-hard-newlines' would remain useful for text/plain;
format=flowed.)  In order of decreasing preference and in order of
increasing fragility:

1.  A box model supported by the display engine, of course.

2.  A special fill function that examines the properties and 
    DTRT.  This is basically how `epos-fill-paragraph' in
    wp-example.el works.

3.  Make sure that each region covered by a `category' property which
    identifies the text as content of a block is separeted by hard
    newlines.  For example by letting a function run by jit-lock,
    which updates that stuff constantly.  That would mean that in the
    first example hitting backspace would have this effect:
    `delete-char-backward' would remove the hard newline, but the
    updating function would insert it again immediately.

4.  Make every hard newline read-only, whenever the user says "this
    paragraph is of type h1".  Advice `yank' to DTRT.


I don't like 3. at all.  (I think that 4. is rather silly, mentioned
only for completeness.)  IMO it short circuits two different semantics
of distinguishing paragraphs.  And my gut feeling is that exactly this
is a potential source for a lot of subtle bugs.

The problem of XML's nested blocks is still another, unresolved issue.

    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.