[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enriched-mode and switching major modes.

From: Richard Stallman
Subject: Re: enriched-mode and switching major modes.
Date: Wed, 15 Sep 2004 11:42:52 -0400

    The hairy part is whitespace formatting. The problems arise from the
    fact that I can't tell Emacs: "Display this text from position POS1 to
    POS2 as a paragraph with a left margin of 20 pt and a right margin of
    40 pt with 20 pt above and below -- *without* adding any character to
    the buffer."

The idea of Emacs is that the appearance is represented by text in the
buffer.  We designed text properties so that the text in th ebuffer
could be something more than a sequence of characters.

Any extensions have to preserve this principle, or we will lose
the benefits of Emacs.

    If Emacs' display engine would support this, e.g. as a `block' text
    property, then I could write:

    (progn (switch-to-buffer (generate-new-buffer "*tmp*"))
           (insert "Example text. Example paragraph. Example text.")
           (put-text-property 15 33
                              '(:margin (4 1 1 1) :border nil :padding nil)))

If the block parameters are specified as a text property on the entire
contents of the block, that might solve the problem.  However, there
are some details here that are nontrivial problems.

1. How to distinguish between two similar boxes with the same specs
and a single longer box.

2. How to represent line breaks.  Saying "break one long line at
display time" would work ok for display, but all the commands that
operate on lines would see just one long line there.

3. How to represent indentation.  If the indentation appears only
in redisplay, Lisp code that looks at the text will think it is not
indented at all.

I think we need to look for a hybrid solution where there could be a
text property saying how this box is supposed to look, but that works
by inserting newlines, indentation, etc., so that the text can be seen
in Lisp without need to decode the box.

    If Emacs display engine would support a block model, we would just
    tell the display engine how to render the paragraphs. There is not a
    single newline chars and no space between paragraphs that would be
    part of the character data.  I.e.
    `(buffer-substring-no-properties (point-min) (point-max))' would

    "Lirum larum (A headline)\"Mariage is the chief cause of divorce.\"\
    This is just ordinary paragraph text. Nothing special here. This is\
     a list item. It contains two subitems:One and Two This is another \
    list item."

This model fails to address those problems.  It would work as a way
of grafting a separate word processing facility into Emacs, but it
would not integrate well with the existing Emacs Lisp world.

However, later you talk about an implementation more like what I have
in mind, where the boxes and lists would be rendered by changing the
buffer text; therefore, the buffer text would show what's really

    I mean "the document's character data" here.  The important point is
    that formats suitable for WP (RTF, HTML ...) separate character data
    from formatting information entirely.

My point is that this is exactly what we must not do in Emacs, lest it
ruin everything in a subtle way.

    However, about one thing I am positiv: there is absolutely no room
    for a minor mode here.  That's why I say that enriched-mode (as a
    minor mode) is a dead end.

I don't see that that follows from the rest of your points.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]