[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs as word processor
From: |
Stephen J. Turnbull |
Subject: |
Re: Emacs as word processor |
Date: |
Fri, 22 Nov 2013 15:37:07 +0900 |
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.
> - 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.
> and with alternate versions for pages beginning chapters or
> sections.
-1. Way unnecessary for the first cut.
> 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.
> - define styles, apply styles to tags.
+1
> - assign parenthesized tags to text ranges (in a hierarchical structure
> similar to SGML).
??
> - 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.
> - 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).
> Scrolling and zooming would behave differently in those WISIWIG
> windows, since they're 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.
> 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.
> 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. 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
(Aside to Richard: the key sequence C-c C-f C-e is compatible with
AUCTeX, which uses C-c C-f as a common prefix for face-changing
commands: emphasize, italic, bold, typewriter, .... Perhaps it would
be nice to make the "M-@" implicit -> C-3 C-c C-f C-e.)
Next step would be continuous leading for full justification.
Probably after that add very simple header and footer capability, with
a fixed number of lines per page (possibly using a very simple
modeline-like format spec?) [Personally, I prefer to think of each
chapter as a long scroll, and editing doesn't care about headers/
footers. YMMV of course, but that point of view suggests that
headers, footers, and WYSIWYG pagination in general can come later
than the within-page stuff.]
The following step would be text that flows around objects (tables,
figures).
And all the while we think about how to add complex capability without
adding complex UI. :-)
All above is IMHO YMMV IANAL TINLA etc....
Steve
- Re: Emacs as word processor / Text Properties, (continued)
- Re: Emacs as word processor, Yuri Khan, 2013/11/24
- Re: Emacs as word processor, Richard Stallman, 2013/11/25
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/22
- Re: Emacs as word processor, Stefan Monnier, 2013/11/22
- Re: Emacs as word processor, Richard Stallman, 2013/11/23
- Re: Emacs as word processor, Richard Stallman, 2013/11/23
- Re: Emacs as word processor, Richard Stallman, 2013/11/23
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/21
- Re: Emacs as word processor,
Stephen J. Turnbull <=
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/22
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/22
- Re: Emacs as word processor, Davis Herring, 2013/11/22
- Re: Emacs as word processor, Lennart Borgman, 2013/11/22
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/22
- Re: Emacs as word processor, John Yates, 2013/11/22
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/22
- Message not available
- Message not available
- Re: Emacs as word processor, John Yates, 2013/11/23
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/23
- Re: Emacs as word processor, Lennart Borgman, 2013/11/23