[Top][All Lists]

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

Re: enriched-mode and switching major modes.

From: Oliver Scholz
Subject: Re: enriched-mode and switching major modes.
Date: Sat, 18 Sep 2004 19:08:17 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt)

"Eli Zaretskii" <address@hidden> writes:

> It is possible that what I wrote was misunderstood to mean that
> there's nothing in the buffer but plain text.

O.k. my mistake then.  I misunderstood you as saying that we should not
build more complex data structures than buffer-text and faces and at
the very most a `left-margin' text property.

> FWIW, I think there _is_ a way to add sophisticated word-processing
> capabilities to Emacs without breaking the basic Emacs design
> assumptions.  One good idea was already suggested in this thread: when
> Emacs decodes a file which has embedded information about the text
> layout, it should convert that information into a combination of
> characters and text properties, such that Lisp programs and C code
> that look at the buffer text could extract the layout information from
> that text alone.  In other words, convert indentation to the
> appropriate amount of whitespace, add newlines where line-wraps are
> required (and put some text properties on those added characters to be
> able to treat them specially, e.g. at save-file time), add text
> properties for paragraph-level style information, etc.
> If you think that this approach will not work, can you tell why?

It works to some extend, as long as you are able to identify those
newlines and space characters when the document is encoded again and
written to a file.  I mentioned this in one of my other longish mails
(sorry for this) as a possible approach for the time that the display
engine does not provide support for block boxes.

This has some limitations.  David already mentioned one problem.  You
are right, of course, that `next-line' & Co. would need to be changed
to DTRT on screen lines rather than what you called physical lines.
But I really think that this is the least of all problems.  Kai
mentioned that cua.el provides such functionality; I counted three
other packages that implement this.

And then there is also the point that this approach fails for the more
complicated things: tables with different font heights, paragraphs
with background colours and borders ...

Oliver Scholz               Jour du Travail de l'Année 212 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

reply via email to

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