From: Richard Stallman <rms@gnu.org>
Cc: boris@gnu.org, alex@emacswiki.org, emacs-devel@gnu.org
Subject: Re: enriched-mode and switching major modes.
Date: Fri, 17 Sep 2004 19:22:56 -0400 [thread overview]
Message-ID: <E1C8S48-0001Jf-Fq@fencepost.gnu.org> (raw)
In-Reply-To: <uwtyurvpm.fsf@ID-87814.user.uni-berlin.de> (message from Oliver Scholz on Thu, 16 Sep 2004 19:04:53 +0200)
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.
next prev parent reply other threads:[~2004-09-17 23:22 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 23:58 enriched-mode and switching major modes Luc Teirlinck
2004-09-05 17:25 ` Richard Stallman
2004-09-06 0:59 ` Luc Teirlinck
2004-09-06 16:42 ` Stefan
2004-09-06 16:53 ` Luc Teirlinck
2004-09-10 17:40 ` Richard Stallman
2004-09-11 2:14 ` Luc Teirlinck
2004-09-11 16:56 ` Stefan
2004-09-11 21:51 ` Luc Teirlinck
2004-09-11 22:55 ` Stefan
2004-09-12 1:46 ` Luc Teirlinck
2004-09-12 18:18 ` Stefan
2004-09-12 2:50 ` Luc Teirlinck
2004-09-13 7:00 ` Richard Stallman
2004-09-12 9:10 ` Richard Stallman
2004-09-12 16:51 ` Luc Teirlinck
2004-09-12 17:08 ` Oliver Scholz
2004-09-12 18:36 ` Kim F. Storm
2004-09-12 20:01 ` Luc Teirlinck
2004-09-13 7:32 ` Kim F. Storm
2004-09-13 23:03 ` Richard Stallman
2004-09-14 3:46 ` Luc Teirlinck
2004-09-14 12:26 ` Stefan Monnier
2004-09-14 22:12 ` Luc Teirlinck
2004-09-15 9:32 ` Richard Stallman
2004-09-17 9:36 ` Richard Stallman
2004-09-19 20:07 ` Luc Teirlinck
2004-09-06 7:36 ` Oliver Scholz
2004-09-06 19:01 ` Alex Schroeder
2004-09-10 17:40 ` Richard Stallman
2004-09-10 19:30 ` Oliver Scholz
2004-09-13 23:04 ` Richard Stallman
2004-09-14 14:41 ` Oliver Scholz
2004-09-14 16:31 ` Oliver Scholz
2004-09-15 1:39 ` Luc Teirlinck
2004-09-15 1:47 ` Luc Teirlinck
2004-09-15 8:06 ` Oliver Scholz
2004-09-15 15:42 ` Richard Stallman
2004-09-16 13:20 ` Kai Grossjohann
2004-09-17 23:22 ` Richard Stallman
2004-09-16 17:04 ` Oliver Scholz
2004-09-17 5:15 ` Eli Zaretskii
2004-09-17 14:34 ` Oliver Scholz
2004-09-17 20:43 ` Kai Grossjohann
2004-09-17 22:05 ` Kim F. Storm
2004-09-18 19:07 ` Richard Stallman
2004-09-18 15:37 ` Robert J. Chassell
2004-09-18 11:14 ` Eli Zaretskii
2004-09-18 12:04 ` David Kastrup
2004-09-18 13:32 ` Eli Zaretskii
2004-09-18 13:46 ` David Kastrup
2004-09-18 15:57 ` Eli Zaretskii
2004-09-19 17:19 ` Kai Grossjohann
2004-09-18 22:55 ` Richard Stallman
2004-09-18 17:08 ` Oliver Scholz
2004-09-18 17:48 ` Eli Zaretskii
2004-09-18 20:02 ` Oliver Scholz
2004-09-18 21:25 ` Eli Zaretskii
2004-09-18 21:54 ` Oliver Scholz
2004-09-20 0:06 ` Richard Stallman
2004-09-20 11:48 ` Oliver Scholz
2004-09-21 18:30 ` Richard Stallman
2004-09-21 19:08 ` Eli Zaretskii
2004-09-21 20:06 ` Stefan Monnier
2004-09-22 4:54 ` Eli Zaretskii
2004-09-22 18:20 ` Richard Stallman
2004-09-22 18:39 ` Eli Zaretskii
2004-09-23 16:44 ` Richard Stallman
2004-09-22 10:01 ` Oliver Scholz
2004-09-22 13:08 ` Stefan Monnier
2004-09-22 13:11 ` Stefan Monnier
2004-09-22 13:14 ` Oliver Scholz
2004-09-22 16:27 ` Stefan Monnier
2004-09-23 1:48 ` Luc Teirlinck
2004-09-23 9:29 ` Richard Stallman
2004-09-23 9:48 ` David Kastrup
2004-09-23 16:44 ` Richard Stallman
2004-09-23 11:35 ` Stefan
2004-09-23 12:46 ` David Kastrup
2004-09-23 12:59 ` Oliver Scholz
2004-09-24 12:08 ` Richard Stallman
2004-09-24 12:50 ` Stefan
2004-09-25 15:34 ` Richard Stallman
2004-09-24 10:59 ` Eli Zaretskii
2004-09-24 11:53 ` Oliver Scholz
2004-09-24 15:51 ` Oliver Scholz
2004-09-24 20:55 ` Alex Schroeder
2004-09-24 21:11 ` Oliver Scholz
2004-09-25 16:36 ` Eli Zaretskii
2004-09-22 10:35 ` Oliver Scholz
2004-09-22 18:21 ` Richard Stallman
2004-09-20 0:05 ` Richard Stallman
2004-09-18 22:11 ` Kim F. Storm
2004-09-19 3:47 ` Eli Zaretskii
2004-09-20 0:05 ` Richard Stallman
2004-09-20 11:07 ` Oliver Scholz
2004-09-20 11:55 ` Kim F. Storm
2004-09-21 18:30 ` Richard Stallman
2004-09-22 7:44 ` Kim F. Storm
2004-09-22 18:14 ` Eli Zaretskii
2004-09-22 21:53 ` Kim F. Storm
2004-09-23 4:47 ` Eli Zaretskii
2004-09-23 7:13 ` Kim F. Storm
2004-09-22 18:20 ` Richard Stallman
2004-09-22 21:58 ` Kim F. Storm
2004-09-20 12:47 ` Kai Grossjohann
2004-09-17 15:08 ` Robert J. Chassell
2004-09-18 17:34 ` Oliver Scholz
2004-09-18 23:05 ` Robert J. Chassell
2004-09-19 11:07 ` Oliver Scholz
2004-09-19 11:24 ` David Kastrup
2004-09-19 13:14 ` Robert J. Chassell
2004-09-20 5:49 ` Stefan
2004-09-20 6:17 ` David Kastrup
2004-09-20 6:26 ` Stefan
2004-09-20 11:00 ` Oliver Scholz
2004-09-20 13:24 ` Stefan Monnier
2004-09-20 14:17 ` Oliver Scholz
2004-09-20 14:55 ` Stefan Monnier
2004-09-20 19:18 ` David Kastrup
2004-09-20 19:49 ` Stefan Monnier
2004-09-20 19:37 ` Oliver Scholz
2004-09-20 20:04 ` Stefan Monnier
2004-09-21 9:07 ` Oliver Scholz
2004-09-21 14:43 ` Robert J. Chassell
2004-09-20 21:44 ` Robert J. Chassell
2004-09-17 23:22 ` Richard Stallman [this message]
2004-09-18 16:57 ` Oliver Scholz
2004-09-18 17:12 ` Oliver Scholz
2004-09-20 0:05 ` Richard Stallman
2004-09-20 11:35 ` Oliver Scholz
2004-09-20 11:47 ` Kim F. Storm
2004-09-20 13:27 ` Oliver Scholz
2004-09-20 14:23 ` Kim F. Storm
2004-09-20 19:35 ` Oliver Scholz
2004-09-20 19:35 ` Oliver Scholz
2004-09-20 20:21 ` Kim F. Storm
2004-09-21 9:07 ` Oliver Scholz
2004-09-21 11:20 ` Kim F. Storm
2004-09-22 7:11 ` Richard Stallman
2004-09-21 18:30 ` Richard Stallman
2004-09-21 20:31 ` Miles Bader
2004-09-22 3:20 ` James Clark
2004-09-23 9:30 ` Richard Stallman
2004-09-21 9:53 ` Kai Grossjohann
2004-09-21 11:32 ` Kim F. Storm
2004-09-21 18:53 ` Eli Zaretskii
2004-09-21 20:34 ` Miles Bader
2004-09-22 0:31 ` David Kastrup
2004-09-22 14:00 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1C8S48-0001Jf-Fq@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=alex@emacswiki.org \
--cc=boris@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.