Re: Emacs as word processor

[John Yates <john@yates-sheets.org>]

[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]

On Sat, Nov 23, 2013 at 10:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > On Fri, 22 Nov 2013 4:47:05 PM, John Yates <john@yates-sheets.org>
wrote:
> >
> > I want to be able to say "This is a chapter title" or "This is a step in
a
> > recipe" or - most commonly - "This is a top level paragraph with no
> > particular distinctive property".
>

> > On Sat, 23 Nov 2013 10:13:38 AM, John Yates <john@yates-sheets.org>
> wrote:
> >

> Are you saying that I can customize an emacs face to specify
> > inter-paragraph space? a bullet glyph or numbering style? first line and
> > subsequent line indentation?  That is definitely not the case with my
> > emacs, current as of Nov 8th.
>
> That's unfair: you said nothing about those features in the text to
> which I responded.  You just talked about the difference between
> imperative and declarative approaches to specifying attributes.  Now
> you've changed the subject, so I no longer understand what are we
> discussing.
>

This is a thread regarding adding a WYSIWYG capability to emacs.   I guess
I am guilty of silently assuming a vague shared sense of what a generic
contemporary WYSIWYG editor does in these sorts of situations:

Chapter title: probably force a new page, possibly number, larger possibly
bolded font, possibly centered, extra trailing vertical space.

Step in a recipe: increase indentation slightly, call out a list using
bullets or numbering

Top level paragraph with no particular distinctive property: revert to
defaults

If you are saying that these features don't exist in Emacs, I agree:
> they don't.  But I don't see the significance of that fact, since
> everybody agrees that Emacs is not a WYSIWYG word processor at this
> time.
>

I understood this thread to be - at least in part - about developing a
vision of how one _might_ move emacs from its current state to one offering
some kind of WYSIWYG capability.

If you are saying that these features could never be part of a face
> spec, then I don't think I agree; please explain why you think so.
>

I did not say that.  Quite the contrary.  In saying I would give the idea
thought I would have hoped that it was clear I felt the suggestion could
not be dismissed out of hand.

I now have given it a bit more thought.  Bottom line, I agree that one
probably _could_ implement paragraph styles using faces but I believe that
to do so would be a poor design.

A better design would provide s separate, easily navigable representation
of a document's (largely hierarchical) structural elements.  Such
structural element objects provides obvious sites to hang per element
"paragraph-oriented" formatting directives as well as a natural framework
for property inheritance.  Properties (many new) would be attached to these
elements  (e.g. indentation, inter-element vertical spacing, list
properties, face).  Then, just as a collection of text properties bundled
into a face and attached to a span of text does a good job of implementing
what some WYSIWYG editors call "character styles", so too a collection of
properties bundled into a face-like object and attached to a structural
element could do a good job of implementing "paragraph styles".  With such
bundles of properties attached to structural elements instead of spans of
text calling them simply "faces" would surely be confusing.  We might call
them "paragraph faces" or "structural faces" or "structural styles" or
whatever...

Finally a new text property would be needed to bind a span of text to the
most deeply nested structural element to which it belongs.  (Though I see
no technical difficulty including that property in a face I can see no
virtue in doing so.)

/john

[-- Attachment #2: Type: text/html, Size: 6474 bytes --]