Re: enriched-mode and switching major modes.

[Richard Stallman]

    The distinction between character data and formatting information,
    mentioned in the paragraph you quoted, is inherent in the type of
    documents we discuss here.  You can enter as many newline characters
    in the source of an RTF document as you want, an RTF reader will
    simply remove them.

That is not relevant to the issue, as it concerns the detailed
specifications of RTF format, rather than the detailed specifications
of Emacs' internal representation.  We can easily implement this
behavior in the format translators for RTF, but it doesn't really
relate to the issue here.

       Instead the user says: "This piece of text is a paragraph, because
       I hit RET when I finished writing it.  I want it to be a paragraph
       of the type "Standard Text".  I want "Standard Text" paragraphs to
       be indented on the left by 1 cm and to have a font size of 10 pt.
       Exept here, I want this paragraph to have an indentation of 2 cm."

Now you're talking about the user interface concepts.  That too is
distinct from the question of representing text inside Emacs.  The
Emacs text representation needs to include a representation of the
specification of a type of paragraph, in order to implement this user
interface.  But it also needs to have spaces in the buffer where there
is indentation, so as to be compatible with how the whole Emacs Lisp
world understands indentation.

           a) For a given word processor application, two different
              documents could look exactly the same when rendered on the
              display.

              For instance, in the document there could be specified as a
              paragraph property that the first line of a paragraph should
              be indented by 1 cm.  While in another document a user could
              get exactly the same visual effect by entering a number of
              space characters.

It is probably inevitable that such indeterminacy will occur,
but let's try to avoid it when we can.  For instance, by keeping
indentation expressed as paragraph style specifications in sync
with indentation expressed as spaces in the buffer.

           b) For a given document, two different applications or the
              same application on two different machines/operating
              systems might render two different visual representations.

This is not specifically a problem, and may even give us extra
flexibility.

    This is very important: If a user enters space characters into an
    Emacs buffers, she wants there to be space characters.  Those
    characters would have to become part of the character data in the
    encoded file.  But if a user just specifies: I want this paragraph to
    be indented, then the space characters used to display the left
    margin _must_not_ become part of the encoded file.

Why do you think so?  It seems to me that these two different user actions
should both produce spaces in the buffer--in one case, inserted manually,
in the other, caused by the format specification.

We can recompute line breaks automatically, and represent them by
newline characters in the buffer, which will be removed and replaced
by the next recomputation.  In this mode, the user would not manually
enter newline characters except to create breaks (hard newlines).

    Erm, what does the concept of "what's really there" in that context
    mean?  In the buffer, or more generally spoken: in the data structure
    a containing block box, or a text property storing formatting
    information is, of course, no less there than any space or newline
    character added for whitespace formatting.

Something is "really there" if other Lisp programs will see it in the
way that they are written to look for it.

    It would be an heuristical approach.  The encoding function (when
    saving to a file) could determin whether a paragraph (defined by its
    preceding and following newline characters) is indented by space
    characters.  It could then write the nessary markup to the file
    accordingly.

I agree with you there.  I'm not suggesting anything like that.