Re: Emacs as word processor

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

The structure of the document doesn't change (it's mostly unrelated to
the presentation or layout).  But the layout of the document depends
obviously on the target medium.  And the user of a WYSIWIG word
processor uses the information provided by the layout output graphic
view, to edit the text and structure of its document so it presents
well.

For example, if you have small sections that fit several on a page, you
would use a style where they flow on a page.  But if you have some
bigger sections, you may rather choose a style where each section starts
on its own page.  And in both cases, you may have exceptions, and bad
cases, such as the section that takes exactly one page and one line on
the following page, followed by another section started on the next
page.  If that other section is bigger than one page, you may want to
keep it starting on its own page, so you'll edit the first section so
that it takes one line less and fit on one page.

Switching to legal paper size is not an option, here all the paper pages
are A4 size, this is the norm. :-)

(Ok, an alternative would be to reduce the vertical margin, but this may
open a can of worm in the rest of the document).


So I persist, WYSIWIG = target medium representation.


If you don't specify target medium representation, then you don't need
WYSIWIG.  You may just use a structure editor (perhaps enriched with
fonts, bold and italic), and have a batch layout processor, eg. a web
browser (modulo my remarks concerning the common use of fixed size web
pages).




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

That's exactly what I've described above.  

What I'm asking, is what you do once the user specified a DTD containing
elements such as: <xlorf>, <grlyb> and <ashur>?  How do you edit them?


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

Because otherwise it's not WYSIWIG anymore: without truncate-lines, the
lines are flowed and are not displayed anymore like they appear on the
printed page.


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

I'm not sure what you mean by word-wrap exactly?

- open some text file.
- M-x set-fill-column RET 40 RET  -- characters not 12.5 cm!
- C-x h M-x set-justification-left RET
- reduce the width of the frame or window to 30 characters wide.

Without truncate-line mode, each line is wrapped over, which is not
WYSIWIG.

With M-x visual-line-mode RET it's the same thing.


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

Well, of course.  We ALREADY have a WYSIWIG editor!
Just M-x ps-print-buffer RET and see how the printed page is exactly
like the screen.  So we have it without that.  Sure.

We even have a WYSIWIG web renderer with M-x htmlize-buffer RET.


But this is not with that that we want to attract new users, and that
is not this kind of text files document that we want to present to our
co-workers who are expecting word processed documents.



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

Type: M-x shell RET libreoffice RET 
Click on: Text document
Type: Hello world!
Select the paragraph, 
Click on the left margin knob above and move it 0.5 inch to the right.

Notice how the page is represented, as a white rectangle, how the
margins are represented as L shapes offset from the four corners, how
rules are graphical representations with graphical graduations,
unrelated to the font sizes, notice how scrolling occurs pixel by pixel, graphically.

Select the word Hello, click on the style popup menu, select More…,
scroll down and click on Vertical Numbering Symbols.

Notice  how the word Hello is rotated 90 degree counter clock wise.

All those representations could not occur no a normal textual terminal:
they are in essence graphical.



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

I won't deny that some pieces are already implemented.  Happily!
Again, for now, let's concentrate on specifications and see if that
makes something that would be worth implementing.

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