Re: Emacs as word processor

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

On 2013/11/22, at 07:37 , Stephen J. Turnbull wrote:

> Pascal J. Bourguignon writes:
> 
>> - define a page size + page margins for the document.
> 
> -1.  That should a function of printing (including previewing final
> copy).  Just text width.  The interaction between page sizes and
> margins is quite complex if you want a good-looking and readable page.


See my answer to Eli, this is on the contrary an essential element of a WYSIWIG word processor.


>> - define header, body and footer areas of the pages.
> 
> +1.  But see below for comments on how that would be done.
> 
>>  They can be specified with versions for odd and even pages,
> 
> -0.5.  Just mirror the format for odd pages if you want the even pages
> to be different.

That's the point of having a word processor in emacs: you can program this kind of rules.  But I assure you that I have much more books and documents that don't have symetrical headers or footers.



>>  and with alternate versions for pages beginning chapters or
>>  sections.
> 
> -1.  Way unnecessary for the first cut.

Hey!  The first cut should implement MY use case! :-)


>>  Since headers and footers can be edited with styles too, editing them
>>  would have to call up secondary WYSIWIG windows.
> 
> -1.  Just edit them in-place, and when leaving that area prompt for
> whether it's that page only, or change the style for all pages.

Possibly.


>> - define styles, apply styles to tags.
> 
> +1
> 
>> - assign parenthesized tags to text ranges (in a hierarchical structure
>>  similar to SGML).
> 
> ??

Cf. my answer to Eli.


>> - define a file format.  I'd propose SGML with a DTD usable by docbook
>>  for the data, extended with as metadata a description of the document
>>  layout (page size, styles, etc).  Perhaps DocBook XSL (style sheets)
>>  could be used for the metadata.
> 
> You're proposing yet another file format that would be useless for
> exchange with non-Emacs users?  I don't see the point.

DocBook DTD are rather de-facto standards, and is based on standard SGML/XML, DTD, and XSL.  I've not proposed to create a new file format, but to specify what _standard_ file format will be used for our word processor documents.  What may be non-standard, is the way we package the data and metadata.  Microsoft products and LibreOffice use zip archives of files in standard formats including XML.  There's nothing bad with that.



>> - 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.
> 
> -0.5.  All you really need is leading for the interword spaces when
> presenting fully justified text.  I don't think Richard is thinking
> about photorealistic display (which you can't get anyway, even Word
> sometimes prints differently from what you see on screen).

When you have 227 dpi screens?  To print on a 400 dpi printer?
I doubt a lot of people would see the difference!



> 
>>  Scrolling and zooming would behave differently in those WISIWIG
>>  windows, since they would contain essentially a graphic
>>  representation of the page, like when we render PDF files.
> 
> -1.  No, PDF is static, not editable.  If there's reason do movement
> differently in WYSIWYG editing buffers, probably the option should be
> available in all editing buffers.  But I don't really see this as
> necessary at first.
> 
>>  Page margins, paragraph margins (set in the paragraph style), and
>>  other elements could have graphical controllers overlaid for GUI
>>  interaction, as well as being editable with normal keyboard commands,
>>  like the scroll-bar, menu-bar and tool-bar options.
> 
> -1.  Way unnecessary for the first cut.

I'm not discussing Agile project management methodology.  I'm considering the specifications of the FINAL product.

I'm tring to imagine what could be the objective, to see if it would be worth the effort.


A "first cut" as you're cutting it, doesn't interest me, it's not worth the effort.  That's probably why nobody worked on it for 25 years.



>> The reason why people have so much a hard time to use and apply
>> styles with word processors: they presence and definition is
>> hidden, since they're not "printed out", only their effect is
>> visible.
> 
> This is a Microsoft conspiracy to sell classes in Word use, I think.
> The things that regular people need to do with styles in a simple
> wordprocessor are relatively few.
> 
>> A solution in emacs could be to use a second window, a metadata window
>> (a little like a minibuffer, but probably bigger), that would appear
>> automatically when editing a WYSIWIG window, so that when moving the
>> cursor on a cell in the WYSIWIG window, style and other metadata can be
>> displayed in the metadata window, and editing commands can then be given
>> that modify the metadata and are reflected WYSIWIGLY in the WYSIWYG
>> window.
> 
> -100 (maybe more).  Either you want to edit a markup language (a la
> CSS) "out of band", or make changes GUI-ly.  Either way, we don' need
> no steenkin' metadata windows getting in the way of a bigger picture
> for the document we actually care about.

Already, while editing pure text programs, I find the display in the minibuffer of the syntactic information very useful.  If I was editing a document with a structure hidden, I would find it even more useful.

(setq c-echo-syntactic-information-p t)

>> When you edit plain text, or plain text with markup (either "implicit"
>> thru formating like in reStructured Text or markdown, or tagged text in
>> the SGML family), you use the same command set to edit both the data and
>> the metadata.  Even to edit both at the same time!  
>> 
>>    M-x replace-string RET <p>The RET <br>And the RET
>> 
>> But in the case if a WYSIWIG word processor, as long as we don't provide
>> a plain text data+metadata buffer to be edited in emacs as plain text,
>> we need to define two sets of commands,
> 
> I really don't see this.  When you're in a "cell" (header, footer,
> body, object == table, figure), you should be able to edit that cell
> directly, and have it reflected in the stylesheet without special
> commands.

Why?  Why should it be the modification of the global style rather than just the creation of a new style just for this character?  Or this word? Or this paragraph? etc.

Think also about the notion of cascading in cascading style sheets.  What level of the cascade do you want to edit anyways?




>  Yes, there will be special commands because the _content_
> of specials is different (instead of a literal numeral, there will be
> a "page_number" object in headers and footers, for example, and
> selecting from the available objects -- including the non-portable
> "sexp" of course!!).  So we will require a special insert command, but
> not much more, I suspect.
> 
>> And this is the fundamental problem with word processors and WYSIWIG
>> editors.  Since data and metadata is separated, a text editor becomes
>> useless to work on them.
> 
> Metadata will be applied via text properties and overlays, no?  I
> don't see a real difference between that aspect of the current Emacs
> buffer/redisplay model, and what you're talking about here.
> 
>> So the bet here is that adding a new set of commands to edit the
>> metadata could be done in a way that's sufficiently practical and usable
>> to make editing WYSIWIG document a little more agreable than editing
>> plain tagged text (SGML, reStructuredText, LaTeX, etc).
> 
> I suspect all this is quite far from what Richard is thinking about at
> this point.  I understand what he wants (as a first cut) to be
> something like
> 
>    position cursor before the words "emphasize this text"
>    type M-3 M-@ C-c C-f C-e
>    see "emphasize this text" in italics

Richard  said word processor, not enriched-text-mode.


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