Re: enriched-mode and switching major modes.

[Oliver Scholz]

Stefan Monnier <address@hidden> writes:

>> I don't talk about WYSIWYG.  I abhor the very concept of it in the
>> context of word processing.  "WYSIWYG" means to say something about
>> the relationship between the rendering of the document on screen and
>> on printed paper.
>
> My understanding of WYSIWYG is not really that "the printer version is equal
> to the screen version"
[...]

Well, we are trying to make sense of a marketing term here.  My
understanding is that the "what you see" refers to the computer
display and the "what you get" refers to the printed paper.
Otherwise, I think, it should be called "what you see is what you
already have, of course, because that is what you see."
(WYSIWYAHOCBTIWYS).

I'd rather avoid the term "WYSIWYG" in this discussion altogether and
talk about clearer concepts.

[different printed output when Emacs is started on a tty]
> No: most WYSIWYG word-processors will happily accept (and print) colors in
> your document, even when your screen is black&white.  I.e. the way it
> typically works is that there *is* a deep representation but it can only be
> manipulated implicitly through the superficial representation which is
> displayed with "the best possible rendering on the current output device".

I meant the tty example as a reductio ad absurdum of the idea that the
printed output should resemble the rendering on screen.  I do think
that each visual (aural) represantation of an abstract document should
make the best use of the rendering device.

For example on a tty a user might specify: "If somebody displays this
document on a GUI, then display every 'Headline 1' paragraph in bold
with a size of 36pt.  But since I am editing on a tty, display it in
blue instead, so that I can distinguish it from a normal paragraph."

And on a GUI, on a low resolution computer screen, somebody might
prefer a sans serif font, while for the higher resolution printed
output the same person might prefer a font with serifes.

HTML/XML + CSS 2 already supports this in the document encoding.  For
RTF I still have to design a good solution.

>>> the deep representation (which, AFAIC, is not "just the disk format"
>>> but is the format where I can expresss my *intents*, i.e. where I
>>> can distinguish between two concepts even if they happen to be
>>> rendered identically on the currently used output mode)
>> [...]
>
>> Yes, that's a different editing model.
>
> I guess I still don't understand the model you're thinking of, which doesn't
> involve an explicit deep representation and yet isn't WYSIWYG either.

It is basically as you said: you express your intents.  But rather
than doing this via a command or markup language, you do it by
interacting with a UI.  This abstracts your intent from a specific
file format ("deep representation").  That is why I talk about
"abstract documents".

The benefit is that you do this while looking at the "surface
expression".  When I am working on a document this is the time where I
specially /want/ the additional visual clues provided by fonts, font
sizes, whitespace formatting ... whatever.  I do not want to edit a
representation (the deep one) that differs from the representation
that is meant for reading (the surface expression).  Your mileage may
vary; for either editing models there are people who prefer it.

[When the time is ripe, I'd like to think about different means to
make that as compatible as possible with a POV where emphasis is on
the "deep representation".  That would, for instance, involve clever
pretty printers that produce clean, human readable encoded document
files.]


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