Re: Emacs as word processor

[Eli Zaretskii <eliz@gnu.org>]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Fri, 22 Nov 2013 22:06:23 +0100
> Cc: emacs-devel@gnu.org
> 
> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.

I cannot disagree more.  The main features of a document change very
little with paper size changes.

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

I see no reason for these features to be connected to a style.  They
can easily be separate; keeping them separate will make it easier for
users to specify arbitrary combinations of them.

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

I think you confuse user interface with implementation.  I can easily
envision commands that insert a section header that don't need any
idea about the document tree.

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

The former is possible today, the latter can be added (but I really
don't see a need).

> We'd have to disable removing truncate-lines mode

What? why??

And why are you talking about truncate-lines, when Emacs has word-wrap
for quite some time now?

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

But we can have WYSIWIG without that.

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

Of course, a character on glass is just a bunch of pixels.  But if
that is what you are talking about, then what exactly are you saying
that we need to change from what we have today?

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

Emacs has pixel-level scrolling for a long time, it just is activated
in very rare cases, so you perhaps don't know it exists.

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

Emacs can display images as well, you know.  We just need to use that.

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

Let's care about the features first, and talk about attractors later.