[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: |
Fri, 17 Sep 2004 19:22:56 -0400 |
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.
- Re: enriched-mode and switching major modes., (continued)
- Re: enriched-mode and switching major modes., Stefan Monnier, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Stefan Monnier, 2004/09/20
- Re: enriched-mode and switching major modes., David Kastrup, 2004/09/20
- Re: enriched-mode and switching major modes., Stefan Monnier, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Stefan Monnier, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/21
- Re: enriched-mode and switching major modes., Robert J. Chassell, 2004/09/21
- Re: enriched-mode and switching major modes., Robert J. Chassell, 2004/09/20
- Re: enriched-mode and switching major modes.,
Richard Stallman <=
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/18
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/18
- Re: enriched-mode and switching major modes., Richard Stallman, 2004/09/19
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Kim F. Storm, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Kim F. Storm, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Oliver Scholz, 2004/09/20
- Re: enriched-mode and switching major modes., Kim F. Storm, 2004/09/20