[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: Mon, 20 Sep 2004 21:35:55 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt)

address@hidden (Kim F. Storm) writes:

> Some of the existing hook properties may also be used to handle
> "delete hard newline betwee paragraphs with different categories" in
> some sensible way.
> If nothing else, such hooks could set some global value which causes a
> post-command-hook to fix whatever conflicts are created by the last
> modification -- at least I think that would be more efficient that
> relying on jit-lock to run "all the time".

I agree that it would work.  But why is it better than the solution
that I listed as #2, i.e. letting a special fill-function handle all
whitespace formatting issues?  I have experimented with this and it
works nicely.  It can also handle the problem of putting whitespace of
a specific height before and after a paragraph rather elegantly.

The way I see it we first create two different semantics for
paragraphs: one via the `category' property, one via hard new lines.
And then we take special pain to keep both representations in sync.
To me this seems like asking for trouble.

The only benefit I can see, is that `forward-paragraph' and its like
would DTRT.  But writing a version that works correctly for the other
solution and binding it to the appropriate keys is rather trivial.


Oh, no!  I see now, this is a way to make a slightly modified
`fill-paragraph' work.  Some of my major concerns could be adressed
this way and /technically/ it could be handled by a minor mode.
(Though I don't see what good that should be.  How a paragraph should
be indented in an RTF document depends on its properties, not on
paragraph-indent-text-mode nor on paragraph-indent-minor-mode.)  It
could be a way to provide a user interface for RTF where I can type
four spaces to indent a paragraph like in text mode.

I don't like the resulting user interface.  I don't like it at all.
In fact I find it really, really horrible.

Would it be possible to handle XML with its tree-like structure this
way?  My own thoughts have let into an entirely different direction
(not explained in this thread); offhand I don't see how nested block
boxes would be possible with hard newline semantics.

Oliver Scholz               Jour des Récompenses 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]