Re: enriched-mode and switching major modes.

[Richard Stallman <rms@gnu.org>]

    Exactly!  However, it is important to discuss implementation issues
    together with the user interface concepts in order to account for the
    semantics of the representation.

I agree we need to discuss them both; the point is, they are not the
same question.  They are related questions.

    -  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.

Most programming languages have a textual representation and a
behavior.  Lisp is different: everything has a textual representation,
a Lisp object representation, and a behavior.  When designing a Lisp
construct, or any Lisp data, one must think about all three levels.

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.

The visual rendering of paragraph indentation on the screen could be
the same, regardless of whether the buffer contains space characters.
And the file representation can also be the same (no space characters
for indentation there).  Despite that, it makes a difference what the
buffer contains.

       Because of this semantic difference, existing Emacs Lisp functions
       would not do the right thing when working on them.  I wouldn't
       expect them either to do the right thing.  `fill-paragraph' does
       not work well in a dired buffer.  `query-replace' does not work in
       a Gnus *group* buffer.

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.

This implementation makes all kinds of cursor motion commands, and
commands that only look at the buffer contents, do the right thing.

    -  Even when working with space characters for indentation, it would
       probably not be as you seem to expect.  When working on a
       graphical user interface, we would have to deal with proportional
       fonts of varying sizes.

Yes, this will make matters harder.  We will need to use some
spaces that have only partial width, or something like that.

       (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))))

supposing that aligning to pixel 20 means 3 and a fraction spaces?

However, even having one very wide space to represent the indentation
is better than having none at all.  That one space will at least
show Lisp code that some indentation is present.

      But if we want to implement XML/HTML + CSS
       (and I definitely want), then some nested boxes with borders and
       background colours are not possible to display, but it would be an
       understatement that implementing a way to let the user interact
       with them (for example by typing text) would be "difficult".

I won't argue with this statement, but I don't know what cases you
mean.

    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.

    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.)