Re: Emacs as word processor

[Eli Zaretskii]

> 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.

> - 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.

> - define styles, apply styles to tags.

Isn't a "style" just another word for a "face"?

> - assign parenthesized tags to text ranges (in a hierarchical structure
>   similar to SGML).

Not sure what for.  This is a solution to what problem?

> - 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.

>   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.  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.

>   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.

> 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.

> 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.