Re: Emacs as word processor

[Eli Zaretskii]

> Cc: address@hidden,
>     address@hidden
> From: address@hidden (Stephen J. Turnbull)
> Date: Mon, 25 Nov 2013 14:20:07 +0900
> 
> Eli Zaretskii writes:
> 
>  > I don't think I understand what you mean by "depth of the character
>  > box".  Emacs just computes the pixel y-coordinate of the next line
>  > differently when this property is used.
> 
> [I'm sorry, the word I wanted was "descent", not "depth".  I don't
> know if that helps, but it's more typographically precise.]
> 
> Sure, but where does the data for that computation come from?  It
> comes from the font's metadata for the character (ascent [above
> reference point], descent [below reference point], and offset [to next
> glyph's reference point].  What can be done per character without
> knowing *which* character is to set the descent to some value.  Then
> the line's descent is the maximum of all descents of characters on the
> line, as modified by the text property.

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, 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.  If
what you are saying is that this is hard in the general case because
of complications with some scripts, then I bet Emacs doesn't support
these scripts well anyway, so either we should add such support or
continue living without it.  It still doesn't mean we cannot have
WYSIWYG WP capabilities that don't blow Office out of the water, but
do allow decent word processing in, say, 90% of use cases.

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

> The point is that some properties should be specified per-character,
> and others should be specified for higher level text units.  For the
> latter, using a text property that covers a certain interval of
> characters that does not correspond to that unit is horrible because
> it's going to confuse users.  The UI should make that impossible.

OK, but I don't see any problem with that.

>  > No, the problem is that if you make changes in some part of text that
>  > modify its typeface or indentation or properties of the numbered list,
>  > these changes suddenly affect the entire document.
> 
> Really?  I've never seen that happen 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.

>  > > Concretely, if you edit a section heading's style (eg, changing
>  > > Helvetica to Times New Roman), Emacs could issue a query asking
>  > > 
>  > >     Do you want to edit just this instance?
>  > >     Change font family to /Times New Roman/ in section headings at:
>  > >     [All levels] [This level] [This heading only] [Cancel]
>  > >     [ ] Review exceptional headings at affected levels
>  > 
>  > Nuisance, if done by default.  When I edit a piece of text, I mean to
>  > edit only that piece of text.  If I want to edit all pieces of text
>  > that use some style, I should say-so in advance.
> 
> Of course if you edit *text*, either the content or by applying or
> removing a style, there should be no prompt, and I didn't propose that
> there be one.  Did you notice that?

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.