Re: Emacs as word processor

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > OK, but I still don't see what are you arguing.  We already have in
 > Emacs text properties that specify pixel-level alignment of a
 > character,

That's reasonable.

 > text properties that specify prefix generated out of thin air for
 > each line, properties that display text in the margins instead in
 > the text area, etc. etc.  They are all considered by the display
 > engine as it lays out the text.  I see no reason why the same
 > technology with only minor tweaks couldn't support specifications
 > of indentation, justification, or even automatic paragraph
 > numbering.

Of course it *can*.  But these all make me gag (one of the famous
"technical differences" -- they're implemented as extents in XEmacs,
often zero-length extents for paragraph-level things and line-level
things like marginal annotations).  I don't suppose whether my stomach
is doing flip-flops matters to emacs-devel, of course. :-)

For example, normally text properties are carried with the text if
cut/copied.  That sucks for paragraph-level things.  If it's a
document-level style, there's no need, it will be in effect at the
target point, too.  If you're moving the text between documents, it's
reasonably likely you *don't* want that stuff at the target point.
N.B. This is the behavior of Excel that I hate most: it defaults to
carrying cell formatting with the contents when pasting -- I almost
*never* want that, and there's no way I know of to change the default
paste style in any *Office spreadsheet.

Of course you can write code that discards those properties, but
really, that's not what you want.  Some properties should never be
copied (and for the exceptions, it's not that burdensome to query and
reapply those properties).  That should be an attribute of the
property itself, not the code that copies or moves text.

 > If what you are saying is that this is hard in the general case
 > because of complications with some scripts,

No, I'm saying getting this stuff right depends on either the user
doing the right thing, or Emacs doing a lot of guessing as to what the
user meant.  IMO, this is going to make it hard to support WYSIWYG
well enough to attract new users.  (I guess that is not your reason
for taking an interest in this thread, but several people, including
RMS repeatedly, have mentioned it.)  For example:

 > > Another way to look at this is "what happens if *two* intervals
 > > completely contained in the same line have *different* line-separation
 > > properties?"
 > 
 > They cannot overlap in Emacs.  If they are disjoint, then the result
 > will be the maximum spacing specified by any one of them.

Which is not necessarily what the user wants.  When I specify
something like that in TeX, I almost always want the *minimum* because
it looks better.  YMMV, but it proves the point that users want
different things.

 > > Really?  I've never seen [the whole document change based on
 > > changing local indentation etc] in any of Word, OpenOffice, or
 > > LibreOffice.
 > 
 > Happens to me and my colleagues every day.  The longer the document
 > and the more styles it uses, the higher the risk of hitting this.

OK, I guess I'm just fortunate to have an environment where I don't
have to use WYSIWYG crap very often on documents longer than two
pages.  (I also suspect that most of those documents are composed by
people who don't grok styles, so there's not very much to go wrong.)

 > Well, "edit section heading's style" is ambiguous.  And if by that you
 > meant edit the style, not the text that uses the style, then the
 > question is still redundant, because it should be clear that I want
 > all the headings using this style to change.

Maybe that's true of *you*.  It's definitely not true for me -- I
rarely change pre-defined styles of document components *except* for
exceptional cases.  The point of "software for the rest of us" (and
Emacs, for that matter) is to accomodate as many possible "clear
wants" that *differ* from person to person as possible.  But software
for the rest of us and Emacs have very different philosophies.  SFTROU
puts the options in your face on the assumption that you're too busy
(or otherwise incapacitated ;-) to read a manual.  Emacs assumes that
you know how to efficiently discover how to invoke behavior you want,
and maybe even create it if it doesn't exist already.[1]

If you want a certain amount of WYSIWYG in a form that is very
compatible with traditional Emacs philosophy, I think that's very
do-able, with a reasonable amount of effort (none of which am I going
to supply, though, not even to port it to XEmacs -- I really don't
think it's worth it, better to teach people to AUCTeX and preview).

But if you (FVO of you = "any of the folks who have participated in
this thread") want something that will attract new users to the Emacs
fold, that is going to be a *ton* of drudgery.  On the level of
"friends don't let friends drink and drive."  Trying to "make Emacs a
plausible alternative to *Office for non-Emacs users" is the kind of
self-destructive behavior I hope my friends will avoid.  :-)


Footnotes: 
[1]  Writing code is by no means a *requirement* for using Emacs, and
Emacs doesn't assume that just because you're smart enough to do so
that you will.  It does pay you the respect of assuming you're smart. :-)