[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs as word processor

From: Pascal J. Bourguignon
Subject: Re: Emacs as word processor
Date: Sat, 23 Nov 2013 14:42:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: "Pascal J. Bourguignon" <address@hidden>
>> Date: Fri, 22 Nov 2013 23:53:40 +0100
>> Eli Zaretskii <address@hidden> writes:
>> >> From: "Pascal J. Bourguignon" <address@hidden>
>> >> Date: Fri, 22 Nov 2013 22:06:23 +0100
>> >> Cc: address@hidden
>> >> 
>> >> 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.
> The layout depends on the medium in very minor ways, as long as we are
> talking about the "usual" page sizes.  If what you have in mind is A3
> paper or greeting cards, then the layout is indeed greatly affected,
> but that's taking the issue to its extreme.
> IOW, WYSIWYG is much more than just layout.
>> So I persist, WYSIWIG = target medium representation.
> And I insist that this is a myopic view of WYSIWYG.
>> If you don't specify target medium representation, then you don't need
> Entirely wrong.
> You seem to think that visual appearance of the text itself is not an
> important part of WYSIWYG.  Nothing can be farther from truth.
>> 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?
> I have no idea what these are or why would the user need to edit them.

Exactly my point.

The user specified <xlorf> as a structuring element for his kind of
documents, and you and emacs don't know what it means, and how it should
represented in a WYSIWIG way and how it should be manipulated from a

Nonetheless, a structure editor can edit them, adding <xlorf> nodes and
childrens, as specified by the user-supplied DTD.

That's why it seems obvious to me, once we've specified that we allowed
users to supply their own DTD, that we need to provide an explicit set
of commands to edit the structure of the document, in additionnal to the
usual text editing command set translated to usual structure editing.

>> >> 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?
> "C-h v word-wrap RET" will tell you.

"This variable has no effect if long lines are truncated (see"

And this is not a WYSIWIG feature, since it changes the layout depending
on the width of the emacs window, instead of depending on the width of
the page set up.

>> - 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
>> With M-x visual-line-mode RET it's the same thing.
> So we need to add a feature whereby word-wrap happens at a fixed
> column.  That should be easy.

Yes, if you think that word-wrap can be safely integrated into a word
processor.  But this is an implementation detail, why do you discuss it

>> 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.
> Wrong.  Text can be laid out vertically as well (if we decide that's
> an important feature to have in Emacs) without treating it as a
> picture.

What about the drawing of the margins and other signs that don't occur
in character cells?

__Pascal Bourguignon__

reply via email to

[Prev in Thread] Current Thread [Next in Thread]