Re: Emacs as word processor

[Pascal J. Bourguignon]

On 2013/11/22, at 16:04 , Eli Zaretskii wrote:

>> From: "Pascal J. Bourguignon" <address@hidden>
>> Date: Fri, 22 Nov 2013 01:51:37 +0100
>> 
>> - define a page size + page margins for the document.
> 
> IMO, this is more important for printing.  For display, it's enough to
> start with the locale's defaults.

My point is that WYSIWIG doesn't mean anything when you don't consider an 
"external" medium.

Paper, PDF file, web page.

Paper and PDF files are mostly the same, rendering on a web page is different 
(the pagination differs).

Page size is important to a document, because unfortunately, automatic layout 
cannot take decisions like reordering paragraphs or figures, and editing 
paragraphs so that they fit on a page.

And again, THIS is the only reason why WYSIWIG as some value.


If you want to consider webpages, I'd say that nowadays you would still have to 
consider the size of the area where the document is to be rendered, since web 
designers tend to enforce fixed frames, instead of letting the browser flow the 
text to the random window size.  This is a fact of life.  So you may also have 
to set at least a page width to edit WYSIWIGLY a web page.



>> - define header, body and footer areas of the pages.  They can be
>>  specified with versions for odd and even pages, and with alternate
>>  versions for pages beginning chapters or sections.  They can also
>>  contain dynamic parts (eg. foot notes from text laid out on a page may
>>  be inserted in the footer of the page).
>> 
>>  Since headers and footers can be edited with styles too, editing them
>>  would have to call up secondary WYSIWIG windows.
> 
> Separate windows could be a solution, but it would be much more cool
> to do what the word processors do: make the rest of the page
> un-editable, and dim it to make that apparent, then let you edit only
> the header/footer part.

Possibly.  This is a user interface question that can be solved later.  What I 
wanted to point out, is that headers and footers, like styles, are a-priori 
independent of the page or even the document they appear in.


>> - define styles, apply styles to tags.
> 
> Isn't a "style" just another word for a "face"?

For a character, perhaps.  For higher level nodes, a style may be more complex, 
up to procedural styles, were you call up a lisp function to "font-lock" and 
justify the node (paragraph, chapter, etc).  For paragraphs you would have 
margins and indentations and perhaps drop cap styles, etc.


>> - assign parenthesized tags to text ranges (in a hierarchical structure
>>  similar to SGML).
> 
> Not sure what for.  This is a solution to what problem?

What I mean here is some kind of structured editing.

To split a paragraph in two, we can admit the usual RET key.

To split a section in two, we can admit the usual insertion of a section title.
But already here, most probably the user will enter a new paragraph containing 
the section title, and then select it and apply a header "style".  Well, it's 
not style, it's the specification of a section header tag to this text, and by 
inference, the spitting of the current section in two.

Those two examples have conventional "width of the ass of the horse" user 
interfaces, for conventional pre-defined tags: <section> <title> <para>.

But with the introduction of XSL and DTD, the user can be allowed to edit 
documents with a structure not pre-wired, with tags having now pre-defined 
conventional user interface.  

Therefore we need a standard way to edit the document tree.

In case of sexps, we use paredit.  What do we use to edit a tree that is 
invisible, but thru its typographied and laid yout leaves?





>> - then for the WYSIWIG aspect, we'd need to implement a rendering
>>  engine.  We have the basis with font faces, but more work is needed to
>>  give a WISIWIG representation of the page, and its computed layout.
> 
> I think you underestimate the power and feature-richness of the
> current Emacs display engine.  We should try using it first, before we
> decide that it is inadequate and should be replaced or significantly
> changed.

Perhaps.  It's true that with truncate-lines mode, we'd get a a homothetic 
space, but can we adjust the height of the lines, can we adjust margins (to 
subpixel sizes). We'd have to disable removing truncate-lines mode, and we'd 
have to ensure that changing the line count or line height doesn't change the 
page height.

I've not read the source, perhaps it's already implemented, but I've never seen 
in the behavior of emacs display engine indications that it's able to change 
characters in a page without shifting everything beyond them.


>>  Scrolling and zooming would behave differently in those WISIWIG
>>  windows, since they're would contain essentially a graphic
>>  representation of the page, like when we render PDF files.
> 
> I see no need for abandoning graphical text display we use now.

WYSIWIG.

What we have now is not.


> None of the leading word processors does, AFAIK.  Switching to displaying
> pictures has many drawbacks; e.g., you cannot easily copy/paste with
> it, and the display complexities will grow by orders of magnitude, for
> now good reason.

Any WYSIWIG word processor displays a picture on the screen, and let you edit 
the underlying text data structure.  Even emacs does just that, only it has a 
more direct correspondance between character cells on screens and character 
slots in the buffer.

For example, in scrolling a word processor let you scroll pixel by pixel, while 
emacs let you only scroll line by line, even in the splash window.

Just take a good look at any WYSIWIG word processor window, and count the 
character pixels vs. the graphic pixels.  There's a lot of graphics on them: 
rulers, margins, 


>>  Page margins, paragraph margins (set in the paragraph style), and
>>  other elements could have graphical controllers overlaid for GUI
>>  interaction, as well as being editable with normal keyboard commands,
>>  like the scroll-bar, menu-bar and tool-bar options.
> 
> We have the fringes and the display margins for that, we just need to
> use them.

WYSIWIG.


I wouldn't mind a text editor that would let us edit enriched text. 
But strangely, I doubt that would attract new users.



>> One problem is that there are parts that have a lot of editable
>> metadata, but which are not represented at all in a WYSIWIG document.
>> That's the reason why people have so much a hard time to use and apply
>> styles with word processors: they presence and definition is hidden,
>> since they're not "printed out", only their effect is visible.
>> 
>> A solution in emacs could be to use a second window, a metadata window
>> (a little like a minibuffer, but probably bigger), that would appear
>> automatically when editing a WYSIWIG window, so that when moving the
>> cursor on a cell in the WYSIWIG window, style and other metadata can be
>> displayed in the metadata window, and editing commands can then be given
>> that modify the metadata and are reflected WYSIWIGLY in the WYSIWYG
>> window.
> 
> The leading word processors have this feature, so we should have that
> as well.  It doesn't have to be another window, though: we could show
> the meta-data and control codes as part of the text.

Well, not part of the text, that would defeat the WYSIWIG aspect, but they may 
be represented graphically, overlaid on or around the text.  There may be tip 
tool boxes, and stuff.

Now, some web editors provide three views of the document:

- WYSIWIG web page, rendered just like in a browser, but editable as in any 
word processor.

- tagged document, where the web page is still rendered like in a browser, but 
each element is adorned with a graphic tag that can be manipulated (selected, 
edited, moved around, etc).

- plain text editor of the HTML.


I would say that this solution works well enough, you can switch easily from 
one view to another depending on the kind of editing action you want to perform 
at the moment, and you have full access to all the levels.

But in a way, it represents the failure of the WYSIWIG word processor, since as 
soon as you have something more complex than MacWrite, basically, you have to 
revert to a structured editor, or to a plain text editor.

For us programmers it would be a good and nice solution.

But users can't deal with the structured view and much less with the "code" of 
the HTML text view.

So I think we should try to find a solution to let plain users perform 
structural editing of their documents and style sheets easily, in a WYSIWIG 
editor.  But indeed perhaps there's no other solution than to present 
alternative, lower level  and non WYSIWIG views.



>> In terms of user interface this kind of word processor also has this
>> problem: you have to have a duplicate set of commands for the metadata
>> than for the data.
>> 
>> When you edit plain text, or plain text with markup (either "implicit"
>> thru formating like in reStructured Text or markdown, or tagged text in
>> the SGML family), you use the same command set to edit both the data and
>> the metadata.  Even to edit both at the same time!  
>> 
>>    M-x replace-string RET <p>The RET <br>And the RET
>> 
>> But in the case if a WYSIWIG word processor, as long as we don't provide
>> a plain text data+metadata buffer to be edited in emacs as plain text,
>> we need to define two sets of commands, since basically we have in the
>> WYSIWIG window only the data (which can edited with usual emacs text
>> editing commands), and in the metadata window, only the metadata of the
>> current cell (or the current path of metadata nodes from the root of the
>> document down to the current cell, in the document structural
>> hierarchy).
> 
> It's much better to have the same command do both.  We could implement
> heuristics that would guess the user intent most of the time, with
> user options to override that as needed.  Most users will not need nor
> want to edit the formal description of the style, be it XML or
> whatever.  They will settle for a Customize way of personalizing the
> styles.

Yes, or use predefined style sheets and document structures.


-- 
__Pascal Bourguignon__
http://www.informatimago.com