[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: Tue, 21 Sep 2004 11:07:23 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt)

Stefan Monnier <address@hidden> writes:

>> The point is that you express your intent while
>> not caring about the particular encoding.
> But getting the intent from the user to the data is "easy".  It's getting it
> the other way around which is the harder part (unless you display the deep
> representation, that is).

Ah, yes, I see.  Yeah, the editing model where display the deep
representation has its undeniable strengths.

I have a few ideas how to improve a word processing UI a little bit.
>From putting additional (optional) constraints on it ("I don't want to
format my text by means of literal space characters.  Stop me from
accidentally inserting more than one, except at the end of a sentence.
I don't want to use explicit formatting properties, let me use
stylsheets only.")  up to displaying additional information in the
margin.  It would not be the same as when editing the deep
representation directly, but it could help.

> I don't think it's the one true way.  I just think it's an
> interesting point in the design space, like preview-latex, tex-mode,
> Lyx, TeXmacs, FrameMaker, OpenOffice, ...

I agree.

Word processing functionality would require a lot of code for parsing
and rendering.  If the architecture is modular enough, that same code
base could be used to implement something like preview-latex for HTML
and XML as well, or to implement WhizzyHTML, where you can edit both
the deep representation and the displayed surface expression.  If done
well, you can users can switch between several editing models at their
leisure.  It is all blue sky, though, but it is worth keeping such
things in mind, anyways.

I really like the word processing model, but even I could imagine that
I sometimes would want to frob the encoded HTML markup of a table
directly.  That's why I would like the WP to provide a means to
"unfold" the visual rendering of a block and edit its markup encoding
directly.  The problematic spot in this model, unlike in preview-latex
or WhizzyTeX, is source preservation.  Source preservation is probably
the spot where both fundamental models ("deep representation" <->
"surface expression" vs. "encoded document file" <-> "abstract
document" <-> "visual (aural) appearance") are not 100% compatible.

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

reply via email to

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