Emacs as word processor

Emacs as word processor

[Richard Stallman]

25 years ago I hoped we would extend Emacs to do WYSIWG word
processing.  That is why we added text properties and variable width
fonts.  However, more features are still needed to achieve this.

Could people please start working on the features that are needed?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Jambunathan K]

Richard Stallman <rms@gnu.org> writes:

> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.
>
> Could people please start working on the features that are needed?

1. What would you recommend as the backend format?

2. Do you consider Orgmode - a text markup format - as a "Word Processor"?

3. Can someone more familiar with internals of Emacs write-up a
   statement or two on what *specific* features are needed to move
   towards the "Word Processor" world.

ps: I like editing and modifying text with Emacs.  For reading text or
viewing, I feel Emacs falls way short.

Re: Emacs as word processor

[Daniel Colascione]

On 11/16/2013 11:28 PM, Richard Stallman wrote:
> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.

Text properties are very useful on their own.

> Could people please start working on the features that are needed?

I don't think that would be a productive use limited resources. Emacs' 
feature set is either already at a place suitable for "word processing" 
or astronomically distant depending on how you think about the problem: 
Emacs already works _very_ well for document preparation using auctex, 
nxml-mode, and so on. LibreOffice already covers the more conventional 
WYSIWYG space and is free software.

Re: Emacs as word processor

[Nic Ferrier]

Daniel Colascione <dancol@dancol.org> writes:

>> Could people please start working on the features that are needed?
>
> I don't think that would be a productive use limited resources. Emacs' 
> feature set is either already at a place suitable for "word processing" 
> or astronomically distant depending on how you think about the problem: 
> Emacs already works _very_ well for document preparation using auctex, 
> nxml-mode, and so on. LibreOffice already covers the more conventional 
> WYSIWYG space and is free software.

I agree with this. I don't know anyone who makes documents that I
respect who thinks that WYSIWYG features are a good thing.


Nic Ferrier

Re: Emacs as word processor

[Lennart Borgman]

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

On Sun, Nov 17, 2013 at 2:02 PM, Nic Ferrier <nferrier@ferrier.me.uk> wrote:

> Daniel Colascione <dancol@dancol.org> writes:
>
> >> Could people please start working on the features that are needed?
> >
> > I don't think that would be a productive use limited resources. Emacs'
> > feature set is either already at a place suitable for "word processing"
> > or astronomically distant depending on how you think about the problem:
> > Emacs already works _very_ well for document preparation using auctex,
> > nxml-mode, and so on. LibreOffice already covers the more conventional
> > WYSIWYG space and is free software.
>
> I agree with this. I don't know anyone who makes documents that I
> respect who thinks that WYSIWYG features are a good thing.
>
> That must be a misunderstanding. Of course WYSIWYS is a good feature for
many people. It is just that document structure must be uncoupled from
layout.

And LibreOffice etc has focused on this.

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

Re: Emacs as word processor

[Juergen Fenn]

2013/11/17 Lennart Borgman <lennart.borgman@gmail.com>:

> That must be a misunderstanding. Of course WYSIWYS is a good feature for
> many people. It is just that document structure must be uncoupled from
> layout.
>
> And LibreOffice etc has focused on this.

Please do not forget about the LaTeX frontend LyX which allows for
"what you see is what you mean" editing and layout.

However, I agree the word processor world is something different from Emacs.

Regards,
Jürgen.

Re: Emacs as word processor

[Andreas Röhler]

Am 17.11.2013 08:28, schrieb Richard Stallman:
> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.
>
> Could people please start working on the features that are needed?
>

Welcome any further enhancement of Emacs as an editor.
However don't think WYSIWG is the right way.

The focus at edit times IMO is quite different from that of final readers.
For example I'd like to see footnotes-anchors better than in document than.

But why not have an  ODF-backend for text-modes, so formats might be stored across sessions?

Best regards,

Andreas

Re: Emacs as word processor

[chad]

On 17 Nov 2013, at 06:15, Juergen Fenn <schneeschmelze@googlemail.com> wrote:

> Please do not forget about the LaTeX frontend LyX which allows for
> "what you see is what you mean" editing and layout.

There is also TeXmacs, which is a GNU project.

Dipping into personal priorities, I'd like to see Emacs' layout
engine expand, but I'd prefer HTML-/CSS-/DOM-like layout improvements.
I imagine that there's considerable overlap between the two.

~Chad

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

I have occasionally used LibreOffice, and that sort fo WYSIWYG editing
is very convenient for things that don't need the power of TeX.

However, every time I am unhappy that (1) it is missing all the other
capabilities of Emacs and (2) it is incompatible with Emacs.  I would
really like to be able to use Emacs to do this WYSIWYG editing.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Stephen J. Turnbull]

Richard Stallman writes:

 > I have occasionally used LibreOffice, and that sort fo WYSIWYG
 > editing is very convenient for things that don't need the power of
 > TeX.

Richard, you really need to specify what features "that sort of WYSIWYG"
is composed of.

The issue is that most people want something like LibreOffice so that
they can do what other people do with Microsoft Word, including exchange
files.  That level of compatibility is a boatload of work.  On the other
hand, everybody I know who uses Emacs at least once a day prefers AUCTeX
+ LaTeX (with appropriate styles) for one-off documents like simple
letters.  LaTeX simply does a far better job of formatting without fear
of having the program take away your options than any WYSIWYG I've ever
seen, and AUCTeX takes almost all the pain out of entering TeX format
macros, while offering reasonably nice previews with preview-latex.  (If
you use an older TeX-mode it may be more painful.)

So I suspect that (a) the number of people who want this and (b) the
number of actual use-cases are quite small.

 > However, every time I am unhappy that (1) it is missing all the other
 > capabilities of Emacs and (2) it is incompatible with Emacs.  I would
 > really like to be able to use Emacs to do this WYSIWYG editing.

You may be the only one....

Finally, those who hate WYSIWYG on principle have a point.  In this day
and age, "accessibility" is not merely politically correct, it's both
achievable and beautiful (at least in the hands of the kind of artisan
who contributes to CSS Zen Garden).  What it isn't is WYSIWYG whenever
the two Ys refer to different yous (author vs. viewer).

Regards,

Steve

Re: Emacs as word processor

[Rasmus]

Richard Stallman <rms@gnu.org> writes:

> I have occasionally used LibreOffice, and that sort fo WYSIWYG editing
> is very convenient for things that don't need the power of TeX.
>
> However, every time I am unhappy that (1) it is missing all the other
> capabilities of Emacs and (2) it is incompatible with Emacs.  I would
> really like to be able to use Emacs to do this WYSIWYG editing.

How about Org-mode?  It's distributed with Emacs; it uses simple
markup, e.g. "*bold*, /italic/", it has footnotes, headings, itemize
etc., and exports to ODT, LaTeX, etc.

It's not quite WYSIWYG, but it's pretty close.

–Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: Emacs as word processor

[Christopher Allan Webber]

rms@gnu.org writes:

> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.
>
> Could people please start working on the features that are needed?

I'd love to have this also, for two different reasons.

 - It would be nice to be able to open and edit LibreOffice ODT
   files in emacs.  I collaborate with people who are not programmers;
   this would allow us to collaborate more easily.
 - The set of features that would actually be required to be introduced
   could possibly lower the barrier to entry for getting into emacs that
   many run into (myself included, years ago)

In that sense, from a technical level, it looks like there are two
directions, which mostly map to the above:

1) an editing mode for ODT files that is mostly "ODT editing in emacs so
   existing emacs users can enjoy that".

   This feels like we have already a lot of the technology for; surely a
   major mode could be possible?  We already have the ability to control
   font display, we have visual-line-mode...)

   It would possibly be a lot of work to write the parser and writer for
   ODT in emacs, but probably possible.

   In a sense, this is "word processing/ODT for emacs users."

2) The other route of things is kind of more "emacs for word processing
   users", or the technical side of building user interface elements
   that emacs simply does not have.  For example, emacs users are
   probably happy to bind a key so that they can set the font size, make
   it bold, or set the color.  That's not true for many
   not-already-emacs users.  We would probably need a menu bar for such
   user interface elements similar to what libreoffice has.  Is this
   possible to do in emacs?  Maybe using the "embed GTK widgets" branch?
   Maybe these tools could only be exposed in GUI mode, and we assume
   that people using the terminal version are the users who do not
   need/want it.

#2 seems like it would take a lot more work to get to, and would involve
thinking about adding some tooling that emacs does not yet have.  #1
seems fairly possible though... and why not have it if someone is
willing to build it?  We have tetris, IRC clients, video editing, and
even opening PDF files (read-only).  It would be interesting to have ODT
support at least for emacs users' own needs.  And probably we could work
from that direction and gradually migrate to addressing #2 also.

There are a lot of reactions on this thread that seem somewhat hesitant
about emacs adding WYSIWIG support, but I suspect it's fear that #2 will
corrupt the lisp machine interfaces that we already know and
enjoy... but I doubt that the emacs community would let that happen
anyway.  But we can probably add some tooling that will make emacs more
friendly and accessible to newcomers without hurting the things we
already have.

That all said, sounds like a crazy huge project.  I guess someone would
have to step up to adding ODT support, and given the number of projects
on my plate, I cannot volunteer.  :)

 - Chris

PS: As much as I love to use org-mode to generate ODTs, it's not the
same thing.  I still get ODTs from people, and I have no way of editing
those without converting it back... I'd like just a way to collaborate
there in emacs :)

Re: Emacs as word processor

[Tom Tromey]

>>>>> "Christopher" == Christopher Allan Webber <cwebber@dustycloud.org> writes:

Christopher>  - It would be nice to be able to open and edit LibreOffice
Christopher>  ODT files in emacs.

I think it's pretty hard to do this well.  ODF is quite a large spec.

However, there's also the fun:

    http://www.cb1.com/~john/computing/emacs/lisp/editing/odf-mode.el

Found from

    http://www.emacswiki.org/OpenDocumentText

Tom

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > 25 years ago I hoped we would extend Emacs to do WYSIWG word
    > processing.  That is why we added text properties and variable width
    > fonts.  However, more features are still needed to achieve this.
    >
    > Could people please start working on the features that are needed?

    1. What would you recommend as the backend format?

It would be good to support several, including some use of HTML, ODF, and
maybe Texinfo.

    2. Do you consider Orgmode - a text markup format - as a "Word Processor"?

I don't know how to use Org mode, and don't know what it does (it
seems to do so many things), but if it displays through Emacs then
there are many formatting features that it can't display in a WYSIWYG
fashion like Libre Office.

    3. Can someone more familiar with internals of Emacs write-up a
       statement or two on what *specific* features are needed to move
       towards the "Word Processor" world.

It would be useful to make a list of them.  Would someone like to?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    The issue is that most people want something like LibreOffice so that
    they can do what other people do with Microsoft Word, including exchange
    files.  That level of compatibility is a boatload of work.

Yup.  But that is what is needed.

    So I suspect that (a) the number of people who want this and (b) the
    number of actual use-cases are quite small.

Perhaps most current Emacs users use TeX when they want to format something.
I use TeX to write a manual, and also when I want to send a nicely formatted
letter; but I wish I could do the latter WYSIWYG in Emacs.

But there are so many people who don't use Emacs or TeX.  They use
WYSIWYG word processors only.  I wish we could make Emacs easy for
them to use, so they could get the benefit of Emacs's other advantages
while doing their word processing.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Sean Sieger]

Richard Stallman <rms@gnu.org> writes:

> Perhaps most current Emacs users use TeX when they want to format something.
> I use TeX to write a manual, and also when I want to send a nicely formatted
> letter; but I wish I could do the latter WYSIWYG in Emacs.

It surprises me that you say that, and with all do respect, that I found
a mail with the subject line.  Doing, C-c C-c in AUCTeX has always
seemed WYSIWYG-enough for me ... especially with a quick letter or some
such.  The confidence, bang, ``It's gonna look perfect,'' not the, ``Hm,
what's the word processor gonna produce??''

You really want GNU Emacs to produce files replete with the metadata
that screws that very same file up at some later date?  The day that
happened to me fifteen years ago was that last time I ever used
Microsoft Word---or any other `word processor'.

Re: Emacs as word processor

[Sean Sieger]

Sean Sieger <sean.sieger@gmail.com> writes:
>
> It surprises me that you say that, and with all do respect,

Sorry, ``... due ...''.

Re: Emacs as word processor

[Allen S. Rout]

On 11/18/2013 01:44 PM, Richard Stallman wrote:

> 
> But there are so many people who don't use Emacs or TeX.  They use
> WYSIWYG word processors only.  I wish we could make Emacs easy for
> them to use, so they could get the benefit of Emacs's other advantages
> while doing their word processing.
> 


I think Emacs could not be 'like' Microsoft Word in this way, without
introducing a crushing maintenance load.  WYSIAIG-alike behavior would
involve imitating whatever UI elements are popular this decade;  ribbon?
 flat design?  Whatever.    These are just as important to making it
"easy for them to use" as any nuance of rendering;  but if the rendering
is not exactly correct too, people are alienated.


- Allen S. Rout
- Peanut gallery.

Re: Emacs as word processor

[Rasmus]

Hi,

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> PS: As much as I love to use org-mode to generate ODTs, it's not the
> same thing.  I still get ODTs from people, and I have no way of editing
> those without converting it back... I'd like just a way to collaborate
> there in emacs :)

What if you could import ODT as Org?

Richard Stallman <rms@gnu.org> writes:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
>     > 25 years ago I hoped we would extend Emacs to do WYSIWG word
>     > processing.  That is why we added text properties and variable width
>     > fonts.  However, more features are still needed to achieve this.
>     >
>     > Could people please start working on the features that are needed?
>
>     1. What would you recommend as the backend format?
>
> It would be good to support several, including some use of HTML, ODF, and
> maybe Texinfo.

On the *export side* these are all supported by Org.  There's no
import though. 

Converting from, say, odt to Org might be more effectively implemented
on the Libreoffice side though that would add extra dependencies.

> I don't know how to use Org mode, and don't know what it does (it
> seems to do so many things),

Here's a simple document with *bold* and /italic/.

#+TITLE: Doc-0
#+AUTHOR: Rasmus
* section
  my *first* /document/

which can be exported to html, LaTeX, odt, texinfo, groff, . . ..

> but if it displays through Emacs then
> there are many formatting features that it can't display in a WYSIWYG
> fashion like Libre Office.

It does support tables, images, LaTeX equations, Greek letters,
different faces for headings/bold/.../ etc.

Richard Stallman <rms@gnu.org> writes:


> I use TeX to write a manual, and also when I want to send a nicely formatted
> letter; but I wish I could do the latter WYSIWYG in Emacs.

Personally, I would have a hard time typesetting a letter in
Libreoffice.  How do I get the address in the right spot, and how do I
typeset my own address above and in a smaller type?

This is how you'd typeset a letter in Org using ox-koma-letter.el ¹.
A letter typeset with Groff would be very similar though the tags
(e.g. :from:) are slightly different.

#+DATE: <2013-06-01 Sat>
#+AUTHOR: Rasmus
* this is my SUBJECT
  here's the contents

* FROM					       :from:
  Rasmus
  in Org-mode
  Emacs

* PS						 :ps:
  here's a PS
* ENCL					       :encl:
  these documents are included
  1. doc1
  2. doc2
* CC						 :cc:
  who will be informed
  - Marie
  - Peter

> But there are so many people who don't use Emacs or TeX.  They use
> WYSIWYG word processors only.  I wish we could make Emacs easy for
> them to use, so they could get the benefit of Emacs's other advantages
> while doing their word processing.

This is a valid point and goal.  The reason why my coauthors tolerate
the initial weirdness of Emacs *is* that we work in Org.

–Rasmus

Footnotes: 
¹   http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/ox-koma-letter.el

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    There are a lot of reactions on this thread that seem somewhat hesitant
    about emacs adding WYSIWIG support, but I suspect it's fear that #2 will
    corrupt the lisp machine interfaces that we already know and
    enjoy... but I doubt that the emacs community would let that happen
    anyway.

Lisp is one of the benefits of Emacs that I wish I had when doing
WYSIWIG word processing.  To abandon that would defeat the whole point
of this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    You really want GNU Emacs to produce files replete with the metadata
    that screws that very same file up at some later date?

That is a strange assumption to make.

Anyway, what I'd do today is edit it with LibreOffice
and wish it were Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

      WYSIAIG-alike behavior would
    involve imitating whatever UI elements are popular this decade;  ribbon?
     flat design?

Does LibreOffice do that?  If not, I guess it isn't really necessary
for the job.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

Would it make sense to add display features so that Org mode
could display more like LibreOffice?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Stephen J. Turnbull]

Christopher Allan Webber writes:

 > There are a lot of reactions on this thread that seem somewhat hesitant
 > about emacs adding WYSIWIG support, but I suspect it's fear that #2 will
 > corrupt the lisp machine interfaces that we already know and
 > enjoy...

No, it's not.  I doubt anybody on this list fears that a processor to
import, edit, and export ODF text documents would be written in
anything but well-styled Emacs Lisp, or perhaps some primitives
wrapping appropriate libraries with an idiomatic Lisp API.  Nor need
anybody fear that our much-loved two-handed six-finger CC mode chords
will be replaced with four Alt-keys, 3 fixed toolbars, and a plethora
of popup context menus and floating toolboxes (that always seem to
hide the cursor).  None of the people whose cooperation in installing
such code would stand for it.

The objections I've seen are (1) pragmatic: it's a huge amount of work
to support enough ODF to be able to turn to Emacs *first* when you
need to edit documents created by office suites and (2) principled:
WYSIWYG is the antithesis of accessible.

 > But we can probably add some tooling that will make emacs more
 > friendly and accessible to newcomers without hurting the things we
 > already have.

Been there, done that, failed so dismally they took back the T-shirt. :-)

Try grepping the archives for "make cua(-mode)? the default". :-/

Re: Emacs as word processor

[Andreas Röhler]

Am 19.11.2013 07:01, schrieb Richard Stallman:
>          [ To any NSA and FBI agents reading my email: please consider
>          [ whether defending the US Constitution against all enemies,
>          [ foreign or domestic, requires you to follow Snowden's example.
>
>      You really want GNU Emacs to produce files replete with the metadata
>      that screws that very same file up at some later date?
>
> That is a strange assumption to make.
>
> Anyway, what I'd do today is edit it with LibreOffice
> and wish it were Emacs.
>

Even plain text edits, formatting etc. are much faster with Emacs than you could do with LibreOffice.
Either to start from LaTex, which takes the need of formatting largely, or from org-mode.

Also edits are much better to read from Emacs, as the formatting is separated.

Plain text mode, that's right, doesn't deliver things it could nowadays.
Here it's to combine the tools written already, ODF-storage etc.

Best,

Andreas

Re: Emacs as word processor

[Andreas Röhler]

Am 19.11.2013 07:01, schrieb Richard Stallman:
>          [ To any NSA and FBI agents reading my email: please consider
>          [ whether defending the US Constitution against all enemies,
>          [ foreign or domestic, requires you to follow Snowden's example.
>
>      There are a lot of reactions on this thread that seem somewhat hesitant
>      about emacs adding WYSIWIG support, but I suspect it's fear that #2 will
>      corrupt the lisp machine interfaces that we already know and
>      enjoy...


Don't think so. WYSIWIG might be useful for Emacs beginners and also in some circumstances,
for example when you can't customize your common environment somewhere, don't have the time etc.

However, several aspects are in the way.

First of all the display engine.
WYSIWIG means to write things back from display. The latter must provide a fairly realistic view of layout.
It's far from this.

OTOH the exporting- and recording-tools --ODF, HTML, PDF etc.-- seem to exist in that or other form already.

But there is another obstacle: AFAIS the Emacs development is done  to a certain extend by people sharing code and tools they use themselves.
Can't see a person, who is capable of writing this and also would need and use WYSIWIG.

Re: Emacs as word processor

[joakim]

Richard Stallman <rms@gnu.org> writes:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
> Would it make sense to add display features so that Org mode
> could display more like LibreOffice?

I still find it unclear what you want to achieve.

Would it be okay, for instance, to edit with Emacs in one buffer and
have a separate libreoffice window update at the same time?

There are several tools that works like this, and it can be done with
varying degrees of finesse.

I have used the approach on several occasions;

- A publisher wanted a Libreoffice compatible document, but I prefered
  to work in org-mode in Emacs.

- My own experimental "Inkmacs" integration between the graphics editor
  Inkscape and Emacs.  

And just to repeat, it's not a novel idea, and many tools work like this.
  
-- 
Joakim Verona

Re: Emacs as word processor

[Stephen J. Turnbull]

Richard Stallman writes:

 > I use TeX to write a manual, and also when I want to send a nicely
 > formatted letter; but I wish I could do the latter WYSIWYG in Emacs.

OK.  But I don't think that's a very big benefit compared to the
amount of work entailed.  It will be much easier (as somebody suggested
already) to produce a variant set of keybindings for LibreOffice that
more closely approximates Emacs bindings.

As for accessing the power of Emacs from your wordprocessor, most
office suites nowadays understand embedded URIs and/or MIME types, and
can bind arbitrary applications to them.  I would think that in many
cases it should be possible to create "emacs:" URIs or an
"application/emacs-lisp" MIME type that could be linked to (with the
effect of using emacsclient to send code to a running Emacs process)
to get various effects.  Ugly, inefficient, and clumsy, but it
probably could be made to work for a lot of use cases.

 > But there are so many people who don't use Emacs or TeX.  They use
 > WYSIWYG word processors only.  I wish we could make Emacs easy for
 > them to use,

Now that is a goal we can all support, I'm sure.  But please take into
consideration that for 99% of the "so many people", "easy to use" is
not just a matter of software UI (including display and layout
features).  It's mostly about file format support, and that support
needs to be very high quality on input, output, and "throughput"[1]
before more than a very few people will use it "in anger".  This is
going to take a huge amount of effort, a large fraction of that
available to the Emacs projects for several years (a decade or so).


Footnotes: 
[1]  Office suites which are capable of reading most formats received,
and outputting new files that are readable when transmitted to others,
nevertheless frequently mangle files received from others in editing.

Re: Emacs as word processor

[Thien-Thi Nguyen]

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

() Richard Stallman <rms@gnu.org>
() Tue, 19 Nov 2013 01:02:05 -0500

       WYSIAIG-alike behavior would involve imitating whatever UI
       elements are popular this decade; ribbon?  flat design?

   Does LibreOffice do that?  If not, I guess it isn't really necessary
   for the job.

Right.  I think if we narrow the "the job" down to "Emacs as word
processor interaction pane" (or whatever the prevalent term is for
rectangular screen area for interaction), and omit the menus and other
peripheral control widgets from consideration, we can postulate some
specific features:

- awareness of current-column as a float
  I started working on this in 2002, but got distracted.
  The (small, exploratory) changes were reverted 2011-03-06.

- correspondance between buffer pos and pixel (x,y) coords on screen

- floating (text "flows" around) images, tables, and other "objects"

- automatic pagination

- page-based stats (word-count, etc), margins, "styles"

These would be a good start, i imagine (i don't use word processors,
personally, but know people who do).

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs as word processor

[Christoph]

I think two different problems have been mentioned here. One is 
Wysiwyg-like features the other the possibility to be compatible with 
other formats. For me the latter problem is much more crucial. Here is 
the use case which may illustrate a typical(?) situation:

In academia (humanities branch!) the MS Word format is still the 
"standard" when you exchange editable documents. More people can handle 
odt today but not too many. So I heavily depend on the import/export 
filter LibreOffice offers for Word.
I also use Orgmode in Emacs to take notes etc. In theory, I could write 
all my documents in Orgmode and export them to odt before sending them 
off. In cases of Word users who do not have import filters for odt 
(there are still a lot of them) one would have to export into the Word 
format via LibreOffice.

However, this does not help in the following two cases that are quite 
common (in short: collaborative work on a document):

1) Someone sends me a odt- or Word-document, that I have to work on, and 
possibly send it back after having made some corrections etc.

2) I want one of the word-users (or odt-users) to edit my document and 
send it back to me after which I want to review the changes and make 
more editing.

Telling people that they should use Emacs is clearly not an option, so 
even with Emacs possessing some advanced Wysiwyg functionality (which I 
would love to have) I still would heavily depend on LibreOffice.

Chris





On 11/18/2013 07:44 PM, Richard Stallman wrote:
>          [ To any NSA and FBI agents reading my email: please consider
>          [ whether defending the US Constitution against all enemies,
>          [ foreign or domestic, requires you to follow Snowden's example.
>
>      The issue is that most people want something like LibreOffice so that
>      they can do what other people do with Microsoft Word, including exchange
>      files.  That level of compatibility is a boatload of work.
>
> Yup.  But that is what is needed.
>
>      So I suspect that (a) the number of people who want this and (b) the
>      number of actual use-cases are quite small.
>
> Perhaps most current Emacs users use TeX when they want to format something.
> I use TeX to write a manual, and also when I want to send a nicely formatted
> letter; but I wish I could do the latter WYSIWYG in Emacs.
>
> But there are so many people who don't use Emacs or TeX.  They use
> WYSIWYG word processors only.  I wish we could make Emacs easy for
> them to use, so they could get the benefit of Emacs's other advantages
> while doing their word processing.
>

Re: Emacs as word processor

[Jambunathan K]

Tom Tromey <tromey@redhat.com> writes:

> However, there's also the fun:
>
>     http://www.cb1.com/~john/computing/emacs/lisp/editing/odf-mode.el

It depends on overlays.  If the file is big, the number of overlays that
will be used is going to be correspondingly large.

shr.el does a fairly good job of converting HTML to Emacs-style
text-mode buffers.  Importing text portions of an ODF file to either
text or Org mode shouldn't be difficult.

Re: Emacs as word processor

[Jambunathan K]

> Right.  I think if we narrow the "the job" down to "Emacs as word
> processor interaction pane" (or whatever the prevalent term is for
> rectangular screen area for interaction), and omit the menus and other
> peripheral control widgets from consideration, we can postulate some
> specific features:

Ability to draw simple diagrams - say a bunch of text boxes or mindmaps.
I believe Emacs has no notion of a "canvas".

> - awareness of current-column as a float
>   I started working on this in 2002, but got distracted.
>   The (small, exploratory) changes were reverted 2011-03-06.

Have you taken any notes?  If yes, could you point to it or post it.  It
can serve as data point if someone were to work on this area.

> - correspondance between buffer pos and pixel (x,y) coords on screen
>
> - floating (text "flows" around) images, tables, and other "objects"
>
> - automatic pagination
>
> - page-based stats (word-count, etc), margins, "styles"

Can we map buffer text to A4-style physical papers?

Re: Emacs as word processor

[Jambunathan K]

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


Richard Stallman <rms@gnu.org> writes:

> Would it make sense to add display features so that Org mode could
> display more like LibreOffice?

Add a Org-mode specific toolbar which looks like a LibreOffice toolbar.

What I mean is this:

When I am editing this message in message-mode, a message-mode specific
toolbar is shown (See attached screenshot).

But when I am editing an Org-mode buffer, I get a bare minimal toolbar.
So someone can cookup an Orgmode specific toolbar that gives a quick
visual feedback on what the Orgmode can do.  (See attached screenshot
for LibreOffice toolbar).

Specifically

1. Fontname
2. Fontsize
3. Text stlyes - Bold, Italic etc
4. Numbering On/Off.  Bullets.
5. Increase, Decrease Indent
6. A "stylist" that examplifies, src-ifies, centrify a block of text.
7. Justification
8. An Icon for Exporting to HTML, ODT or PDF

1, 2 falls squarely within Emacs domain and applies to any text mode
buffer.  (Use local variables to persist the fontname and size)

7 is not handled by Org-mode but falls within the domain of enriched
mode or facemenu.

----------------------------------------------------------------

It would be wonderful if we have mode-specific window configuration.  (I
am not a multi-window or multi-frame user.)

Here:

        http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/pngDhKMlKY65v.png

one can see the Navigator pane on the left and Stylist pane on the
right.  If one could pre-configure such windows for the existing users,
one can easily traverse the document or "apply" quote, example, src
styles to a block of text by simply highlighting a region and a clicking
on a style.

(I see navigator pane as a "docked" speedbar.)

Speaking of which, docking of speedbar and multiple speedbar are other
features that could be useful to have.

----------------------------------------------------------------

Speaking of visual icons, I wish the modeline or the various isearch
controls be shown as little visual icons - It will give quick feedback
and save lots of screen estate.


----------------------------------------------------------------

[-- Attachment #2: message-mode-toobar.png --]
[-- Type: image/png, Size: 9055 bytes --]

[-- Attachment #3: libreoffice-toolbar.png --]
[-- Type: image/png, Size: 18907 bytes --]

Re: Emacs as word processor

[Jambunathan K]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> we can postulate some specific features:

Ability to edit right within the rectangle.  By rectangle, I mean table
cells. (Left and right margins de-limited by the right and left columns
of a table cell.)  In other words, make table.el more responsive to
editing or allow creation of multi-paragraph Org-mode table cells.

Re: Emacs as word processor

[Thorsten Jolitz]

Jambunathan K <kjambunathan@gmail.com> writes:

> When I am editing this message in message-mode, a message-mode specific
> toolbar is shown (See attached screenshot).
>
> But when I am editing an Org-mode buffer, I get a bare minimal toolbar.

Are you aware that outorg.el works with message-mode too, so you can
edit your emails in full Org-mode just by doing M-# M-# in the
message-mode buffer and then M-# in the outorg-edit buffer when you are
done?

> It would be wonderful if we have mode-specific window configuration.  (I
> am not a multi-window or multi-frame user.)
>
> Here:
>
> http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/pngDhKMlKY65v.png
>
> one can see the Navigator pane on the left and Stylist pane on the
> right.  If one could pre-configure such windows for the existing users,
> one can easily traverse the document or "apply" quote, example, src
> styles to a block of text by simply highlighting a region and a clicking
> on a style.
>
> (I see navigator pane as a "docked" speedbar.)
>
> Speaking of which, docking of speedbar and multiple speedbar are other
> features that could be useful to have.

Recently the project 'org-writers-room' was announced on the Org-mode
mailing list -it aims to offer just that, a kind of IDE for writers with
(fixed) mode-specific window configuration, navigator, etc. (see
[[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#CAN_Dec99Ec5KzMQ7v%3DWMs%3D1RRTOXbzteaVtKNP7drD2tFzGdOA@mail.gmail.com][Email
from Matt Price: org-writers-room sort of works]] ... I hope that link
works). Maybe a starting point?

-- 
cheers,
Thorsten

Re: Emacs as word processor

[Sivaram Neelakantan]

On Tue, Nov 19 2013,Richard Stallman wrote:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
> Would it make sense to add display features so that Org mode
> could display more like LibreOffice?

Have you seen the preview option of AucTeX?  It renders the equations
and images referenced in the .tex file inline as you type it in.
Would that be a direction in which you'd want the WYSIWYG feature to
go.  Write in some markup and have a real time buffer render it
immediately as you type?

 sivaram
 -- 

Re: Emacs as word processor

[Jay Belanger]

> Lisp is one of the benefits of Emacs that I wish I had when doing
> WYSIWIG word processing.

TeXmacs uses guile.

Re: Emacs as word processor

[Jambunathan K]

Thorsten Jolitz <tjolitz@gmail.com> writes:

>> But when I am editing an Org-mode buffer, I get a bare minimal toolbar.
>
> Are you aware that outorg.el works with message-mode too, 

I am not interested in message-mode.

I was talking about Org-mode and lack of Org-mode specfic toolbar.

I was suggesting that an Org-mode specific toolbar inspired by
LibreOffice could be useful.

Re: Emacs as word processor

[Allen S. Rout]

On 11/19/2013 03:46 AM, Thien-Thi Nguyen wrote:

> I think if we narrow the "the job" down to "Emacs as word
> processor interaction pane" (or whatever the prevalent term is for
> rectangular screen area for interaction), and omit the menus and other
> peripheral control widgets from consideration, we can postulate some
> specific features:


If we were to imagine that these features exist, I suggest that the
resulting Emacs environment would not be significantly more accesible to
the random MS Word operator than is the current environment.

In fact, I think we'd push it into the Uncanny Valley; increasing
frustration because, having made the surface look somewhat like they
expect, we have left the bones in the "alien" configuration they don't
understand.   In basic Emacs, at least they know they're not in Kansas.

Anyway, since I'm not anteing code, I figure that's my 2cents.   Go you. :)


- Allen S. Rout

Re: Emacs as word processor

[Lennart Borgman]

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

On Tue, Nov 19, 2013 at 7:01 AM, Richard Stallman <rms@gnu.org> wrote:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
>     There are a lot of reactions on this thread that seem somewhat hesitant
>     about emacs adding WYSIWIG support, but I suspect it's fear that #2
> will
>     corrupt the lisp machine interfaces that we already know and
>     enjoy... but I doubt that the emacs community would let that happen
>     anyway.
>
> Lisp is one of the benefits of Emacs that I wish I had when doing
> WYSIWIG word processing.  To abandon that would defeat the whole point
> of this.
>

Perhaps extensions can be used:

http://extensions.libreoffice.org/

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

Re: Emacs as word processor

[Thien-Thi Nguyen]

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

() "Allen S. Rout" <asr@ufl.edu>
() Tue, 19 Nov 2013 09:35:48 -0500

   > if [...] "Emacs as word processor interaction pane" [...], we can
   > postulate some specific features:

   If we were to imagine that these features exist, I suggest that the
   resulting Emacs environment would not be significantly more accesible
   to the random MS Word operator than is the current environment.

   In fact, I think we'd push it into the Uncanny Valley; increasing
   frustration because, having made the surface look somewhat like they
   expect, we have left the bones in the "alien" configuration they
   don't understand.  In basic Emacs, at least they know they're not in
   Kansas.

Well, i'm no UI or HCI maven, so i can't really speak to these issues.
Recalling back to when i was introduced to Emacs, the most compelling
non-programming-that-really-is-a-degenerate-form-of-programming feature
was keyboard macros.  I don't know if that transfers cleanly into a word
processor context, though.  I imagine a more appreciated feature would be
"intelligent search and replace".

RMS: You said you wished for Emacs features using LibreOffice.  What
kind of document were you editing?  Which features did you miss?  How
did you work around their lack?  (Please be specific.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs as word processor

[chad]

On 19 Nov 2013, at 01:02, Christoph <rhogez@gmail.com> wrote:

> I think two different problems have been mentioned here. One is Wysiwyg-like features the other the possibility to be compatible with other formats. For me the latter problem is much more crucial. Here is the use case which may illustrate a typical(?) situation:
> 
> In academia (humanities branch!) the MS Word format is still the "standard" when you exchange editable documents. 

In this vein, it's worth noting that there are large fields
(publishing, legal, several industrial sciences, etc) where MS
Word's Reviewing, Track Changes, and Commenting features are
mandatory; anything that doesn't support those features is a
non-starter. Almost no Word-alikes support these features (well
enough to interoperate with Word), increasing Word's lock-in. A big
part of the problem is Word's continual changes in this area. It's
hard to believe that this is accidental or that it will stop any
time soon (especially given the horrors represented by Word's XML
formats).

I hope this helps,
~Chad

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    Would it be okay, for instance, to edit with Emacs in one buffer and
    have a separate libreoffice window update at the same time?

Maybe it would be.  Is that feasible?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    Now that is a goal we can all support, I'm sure.  But please take into
    consideration that for 99% of the "so many people", "easy to use" is
    not just a matter of software UI (including display and layout
    features).  It's mostly about file format support,

Yes, and that is part of what we need to do.
A facility was added for this purpose
many years ago: format-annotate-function etc.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Pascal J. Bourguignon]

Richard Stallman <rms@gnu.org> writes:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
>     There are a lot of reactions on this thread that seem somewhat hesitant
>     about emacs adding WYSIWIG support, but I suspect it's fear that #2 will
>     corrupt the lisp machine interfaces that we already know and
>     enjoy... but I doubt that the emacs community would let that happen
>     anyway.
>
> Lisp is one of the benefits of Emacs that I wish I had when doing
> WYSIWIG word processing.  To abandon that would defeat the whole point
> of this.

It seems to me it would be easier, and produce a better result with less
effort, to add lisp to LibreOffice than WISIWIG word-processor features
to emacs.


The overview of libreoffice says:

        You can develop for LibreOffice in one of two ways, one
    recommended and one much less so. First the somewhat less
    recommended way: it is possible to use the SDK, for wihch you can
    read the API docs here http://api.libreoffice.org/. This re-uses the
    (extremely generic) APIs we provide for macro scripting in
    StarBasic.

        The best way to add a generally useful feature to LibreOffice is
    to work on the code base however. Overall this way makes it easier
    to compile and build your code, it avoids any arbitrary limitations
    of our scripting APIs, and in general is far more simple and
    intuitive - if you are a reasonably able C++ programmer.

The C++ code uses quite a number of templates, so I guess it won't be
easy to generate automatically a FFI to drive the C++ program from lisp.

But it seems to me that it would be easy enough to target the
LibreOffice API, so that you can write LibreOffice scripts in lisp.

Since this API is apparently written in Java, we could consider using
ABCL to do this.  (Or if you insist on it, some scheme implementation on
Java or JVM).



Otherwise, the main part of WISIWIG, is to represent on screen something
that is isomorph to what's represented elsewhere.  That is, on paper
and, nowadays, on web pages.  So the first thing would be to implement a
model and views of paper pages (page size and layout, margins,
resolutions, fonts, paint, colors), and for web page rendering, we'd
need a HTML rendering engine (probably including Javascript).  Already
only that seems like a bigger job than integrating lisp with the API of
LibreOffice…


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

Re: Emacs as word processor

[joakim]

Richard Stallman <rms@gnu.org> writes:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
>     Would it be okay, for instance, to edit with Emacs in one buffer and
>     have a separate libreoffice window update at the same time?
>
> Maybe it would be.  Is that feasible?

Yes it's feasible. I can have a look, because it could be an interesting
demonstration of the Emacs Xwidget branch as well.

Here is how the similar idea works in Inkmacs(Emacs + Inkskape):

- Write your text in an org-mode file
- Let Emacs start an Inkskape instance
- Emacs communicates with Inkskape using a DBus channel
- Emacs sends dbus commands to update text objects in Inkskape. Inkskape
immediately redraws its display when it receives the dbus commands

Optionally, with the Emacs Xwidget branch, you can also embed Inkskape
inside an Emacs buffer. This is convenient because you can use all the
Emacs buffer switching commands and so on.

also, you can of course try out the idea immediately with the various
Latex preview packages that already do all of this. I'm not all too
familiar with them though, since I normally either a) don't care at all
about layout and just let Latex do its thing or b) obsess about layout,
in which case I use Inkskape.


-- 
Joakim Verona

Re: Emacs as word processor

[Lennart Borgman]

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

On Wed, Nov 20, 2013 at 7:54 AM, <joakim@verona.se> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> >     Would it be okay, for instance, to edit with Emacs in one buffer and
> >     have a separate libreoffice window update at the same time?
> >
> > Maybe it would be.  Is that feasible?
>
> Yes it's feasible. I can have a look, because it could be an interesting
> demonstration of the Emacs Xwidget branch as well.
>
> Here is how the similar idea works in Inkmacs(Emacs + Inkskape):
>
> - Write your text in an org-mode file
> - Let Emacs start an Inkskape instance
> - Emacs communicates with Inkskape using a DBus channel
> - Emacs sends dbus commands to update text objects in Inkskape. Inkskape
> immediately redraws its display when it receives the dbus commands
>
> I did something like this in nXhtml for editing HTML files, displaying the
HTML file in Firefox. It is not useful if you can not get the displaying
app to update incrementally, of course. And that was a problem with the
interface I used between Emacs and Firefox.

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

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

People should refuse to read or send Word documents.
See http://www.gnu.org/philosophy/no-word-attachments.html.
I have refused to read a Word file ever since I wrote that
article.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    In fact, I think we'd push it into the Uncanny Valley; increasing
    frustration because, having made the surface look somewhat like they
    expect, we have left the bones in the "alien" configuration they don't
    understand.   In basic Emacs, at least they know they're not in Kansas.

I think our interface will be so different from actual Word that
no one will get confused.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    Have you seen the preview option of AucTeX?  It renders the equations
    and images referenced in the .tex file inline as you type it in.
    Would that be a direction in which you'd want the WYSIWYG feature to
    go.  Write in some markup and have a real time buffer render it
    immediately as you type?

It would be a step forward, but if the user needs to know the markup
language, it will require a lot more learning a than ordinry WYSIWYG
word processors do.  Also, format compatibility is very important.
Could it be provided in this mode?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

To make LibreOffice support doing everything from Lisp or Scheme would
be a large job, but even once that is done, it would not provide what
Emacs has.  The data structures of Emacs are made for use in Lisp.
Those of LibreOffice are not.  That combination would be artificial,
and if it works, it would not work smoothly.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    RMS: You said you wished for Emacs features using LibreOffice.  What
    kind of document were you editing?  Which features did you miss?  How
    did you work around their lack?  (Please be specific.)

It was stallman.org/ebooks.pdf.  Not very complicated.  I wish I could
specify fonts in Emacs in a way that would really be useful in
making such a document.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    - awareness of current-column as a float
      I started working on this in 2002, but got distracted.
      The (small, exploratory) changes were reverted 2011-03-06.

    - correspondance between buffer pos and pixel (x,y) coords on screen

    - floating (text "flows" around) images, tables, and other "objects"

    - automatic pagination

    - page-based stats (word-count, etc), margins, "styles"

These seem like important features, I agree.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Wed, 20 Nov 2013 13:35:54 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: asr@ufl.edu, emacs-devel@gnu.org
> 
>     - awareness of current-column as a float
>       I started working on this in 2002, but got distracted.
>       The (small, exploratory) changes were reverted 2011-03-06.
> 
>     - correspondance between buffer pos and pixel (x,y) coords on screen
> 
>     - floating (text "flows" around) images, tables, and other "objects"
> 
>     - automatic pagination
> 
>     - page-based stats (word-count, etc), margins, "styles"
> 
> These seem like important features, I agree.

This one is already supported:

>     - correspondance between buffer pos and pixel (x,y) coords on screen

(Unless I misunderstand what is meant by that.)

However, I don't understand why these features are put forward before
much more basic ones.  As I understand Richard's request, he would
like to do everything we can do in Texinfo, but with WYSIWYG display,
have a capability to export that in several formats, and be able to
print it from Emacs.  Why not start with these modest features?

Re: Emacs as word processor

[Stephen J. Turnbull]

Richard Stallman writes, among other things:

 > I think our interface will be so different from actual Word that
 > no one will get confused.

To be frank, I think your goals for this feature are incoherent.  You
say you want non-Emacs users to use Emacs, then you turn around and
deprecate exactly those features of this project (Word file-format
compatibility, *Office-alike UI) that are most likely to encourage
them to try Emacs (or at least, not strongly discourage them from
doing so).

If all you really want is a more convenient way to compose the likes
of stallman.org/ebooks.pdf, what's wrong with focusing on that?  OK,
it's not going to change the world, but it would be a nice feature.

Regards

Re: Emacs as word processor

[Andreas Röhler]

Am 20.11.2013 19:53, schrieb Eli Zaretskii:
>> Date: Wed, 20 Nov 2013 13:35:54 -0500
>> From: Richard Stallman <rms@gnu.org>
>> Cc: asr@ufl.edu, emacs-devel@gnu.org
>>
>>      - awareness of current-column as a float
>>        I started working on this in 2002, but got distracted.
>>        The (small, exploratory) changes were reverted 2011-03-06.
>>
>>      - correspondance between buffer pos and pixel (x,y) coords on screen
>>
>>      - floating (text "flows" around) images, tables, and other "objects"
>>
>>      - automatic pagination
>>
>>      - page-based stats (word-count, etc), margins, "styles"
>>
>> These seem like important features, I agree.
>
> This one is already supported:
>
>>      - correspondance between buffer pos and pixel (x,y) coords on screen
>
> (Unless I misunderstand what is meant by that.)
>
> However, I don't understand why these features are put forward before
> much more basic ones.  As I understand Richard's request, he would
> like to do everything we can do in Texinfo, but with WYSIWYG display,
> have a capability to export that in several formats, and be able to
> print it from Emacs.  Why not start with these modest features?
>
>

It's far from being modest. Seems Richard reached the point of users-interest, where the most popular editor started in 1981.
Please note: saying "most popular", not best. However, there was always a point noticing that, brought here forward in vain several times.

Also don't think Emacs may change it's path that easily: it would mean to turn from producer domination into a kind of consumer market.
AFAIS there is no infrastructure for this.

Re: Emacs as word processor

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> However, I don't understand why these features are put forward before
> much more basic ones.  As I understand Richard's request, he would
> like to do everything we can do in Texinfo, but with WYSIWYG display,
> have a capability to export that in several formats, and be able to
> print it from Emacs.  Why not start with these modest features?

Please: it's time to give Org-mode a try.

C-x C-f ~/test.org RET

Insert this string:

========================================================================
* A headline

A paragraphe.
========================================================================

C-c C-e l o

If (La)TeX is installed on the machine, this will open a PDF file.

You can configure Emacs to open this PDF file (or an ODT file) in
another Emacs window.

We could make it easy to export continuously in the background and
display the PDF/ODT part in another window, this way one would really
see what you get, in real time.

I guess that'd suit most of Richard needs, but it's hard to tell.

-- 
 Bastien

Re: Emacs as word processor

[Bastien]

Bastien <bzg@gnu.org> writes:

> ========================================================================

(PS: The above line is here as a separator, don't include it in the file...)

-- 
 Bastien

Re: Emacs as word processor

[Allen S. Rout]

So, this conversation has made both Reddit and Hacker News.

https://news.ycombinator.com/item?id=6773529

http://www.reddit.com/r/emacs/comments/1r4j5c/richard_stallman_25_years_ago_i_hoped_we_would/

:)

- Allen S. Rout

Re: Emacs as word processor

[Thien-Thi Nguyen]

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

() Richard Stallman <rms@gnu.org>
() Wed, 20 Nov 2013 13:35:52 -0500

   I wish I could specify fonts in Emacs in a way that would
   really be useful in making such a document.

Are you referring to ‘customize-face’ or something else (such
as, e.g., .Xresources/XLFD/XFT processing)?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs as word processor

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Thu, 21 Nov 2013 16:25:59 +0100
> Cc: emacs-devel@gnu.org
> 
> () Richard Stallman <rms@gnu.org>
> () Wed, 20 Nov 2013 13:35:52 -0500
> 
>    I wish I could specify fonts in Emacs in a way that would
>    really be useful in making such a document.
> 
> Are you referring to ‘customize-face’ or something else (such
> as, e.g., .Xresources/XLFD/XFT processing)?

I wouldn't imagine Richard refers to anything like that.  More
probably, he refers to something like M-o.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Thu, 21 Nov 2013 09:00:12 +0100
> From: Andreas Röhler <andreas.roehler@online.de>
> 
> > However, I don't understand why these features are put forward before
> > much more basic ones.  As I understand Richard's request, he would
> > like to do everything we can do in Texinfo, but with WYSIWYG display,
> > have a capability to export that in several formats, and be able to
> > print it from Emacs.  Why not start with these modest features?
> >
> >
> 
> It's far from being modest.

Maybe you read too much into what I've written.  You can get a pretty
good idea if you visit etc/enriched.doc.

> Seems Richard reached the point of users-interest, where the most popular editor started in 1981.

What's the harm, if Emacs still doesn't have those features?

> Please note: saying "most popular", not best. However, there was always a point noticing that, brought here forward in vain several times.
> 
> Also don't think Emacs may change it's path that easily: it would mean to turn from producer domination into a kind of consumer market.
> AFAIS there is no infrastructure for this.

Before we worry about popularity, we should worry about functionality.

Re: Emacs as word processor

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: rms@gnu.org,  ttn@gnu.org,  asr@ufl.edu,  emacs-devel@gnu.org
> Date: Thu, 21 Nov 2013 10:15:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > However, I don't understand why these features are put forward before
> > much more basic ones.  As I understand Richard's request, he would
> > like to do everything we can do in Texinfo, but with WYSIWYG display,
> > have a capability to export that in several formats, and be able to
> > print it from Emacs.  Why not start with these modest features?
> 
> Please: it's time to give Org-mode a try.

Thanks, but you could assume I knew about Org (and use it ;-).

> C-x C-f ~/test.org RET
> 
> Insert this string:
> 
> ========================================================================
> * A headline
> 
> A paragraphe.
> ========================================================================
> 
> C-c C-e l o
> 
> If (La)TeX is installed on the machine, this will open a PDF file.

Sorry, but this is not WYSIWYG.  WYSIWYG means you see the text you
type in its final presentation form, or close to that.  It does not
mean you type into one buffer/window and see the result in another;
that is a step backwards from user expectations, certainly nowadays.

> I guess that'd suit most of Richard needs, but it's hard to tell.

Visit etc/enriched.doc to get an idea.  Of course, that file and
enriched.el are dormant for the last 20 years, so don't expect too
much.  But it could be a starting point, and the display engine gained
a lot of functionality that was missing in 1994.

Re: Emacs as word processor

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but you could assume I knew about Org (and use it ;-).

Sorry, I know you have been (and are still?) using Org!

Richard: please try Org-mode and its export facilities, I think it
will help turning the discussion into something more constructive.

>> If (La)TeX is installed on the machine, this will open a PDF file.
>
> Sorry, but this is not WYSIWYG.  WYSIWYG means you see the text you
> type in its final presentation form, or close to that.  It does not
> mean you type into one buffer/window and see the result in another;
> that is a step backwards from user expectations, certainly nowadays.

Of course you're right.

But WYSIWYG as LibreOffice does it solves really two problems: one is
the real WYSIWYG part (to edit a document with rich text formatting),
the other one is a social one (to edit a document as others will see
it.)

With Org-mode, both problems are solved *indirectly*, by allowing to
export your .org file to another popular formats that you can print
and share.

If the purpose is to solve the first problem within the Emacs world,
then enriched-mode is a good place to continue, though I think Org
also solves the problem and is more handy.

If the purpose is to solve the second problem, I think the solution
I proposed comes close.

Finally, solving both problems... well, I don't know.

>> I guess that'd suit most of Richard needs, but it's hard to tell.
>
> Visit etc/enriched.doc to get an idea.

Oops!  Bug: it's opened through DocView with emacs -Q.  I C-c C-c
and could see it -- nice.

> Of course, that file and
> enriched.el are dormant for the last 20 years, so don't expect too
> much.  But it could be a starting point, and the display engine gained
> a lot of functionality that was missing in 1994.

Yes, but this solution is just for Emacs people.

LibreOffice is popular not only because it's WYSIWYG, but also because
it's solves the problem of exchanging documents with Word-people.  At
least that's my guess!

2.5 cents,

-- 
 Bastien

Re: Emacs as word processor

[Andreas Röhler]

Am 21.11.2013 17:21, schrieb Eli Zaretskii:

>> Also don't think Emacs may change it's path that easily: it would mean to turn from producer domination into a kind of consumer market.
>> AFAIS there is no infrastructure for this.
>
> Before we worry about popularity, we should worry about functionality.

You still didn't get it. It's about usability, which is grown a kind of science, while often ignored here - with some the notable exceptions, yes.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Thu, 21 Nov 2013 19:34:40 +0100
> From: Andreas Röhler <andreas.roehler@online.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> Am 21.11.2013 17:21, schrieb Eli Zaretskii:
> 
> >> Also don't think Emacs may change it's path that easily: it would mean to turn from producer domination into a kind of consumer market.
> >> AFAIS there is no infrastructure for this.
> >
> > Before we worry about popularity, we should worry about functionality.
> 
> You still didn't get it. It's about usability, which is grown a kind of science, while often ignored here - with some the notable exceptions, yes.

Popularity has almost nothing to do with usability, in my experience.

And again, this is tangential to what Richard wanted to discuss.

Re: Emacs as word processor

[Tom]

Allen S. Rout <asr <at> ufl.edu> writes:

> 
> 
> So, this conversation has made both Reddit and Hacker News.
> 
> https://news.ycombinator.com/item?id=6773529
> 
> http://www.reddit.com/r/emacs/comments/1r4j5c/
richard_stallman_25_years_ago_i_hoped_we_would/
> 
> :)
> 

And one of the reddit comments says:

  "Patches welcome, RMS."

http://www.reddit.com/r/emacs/comments/1r4j5c/
richard_stallman_25_years_ago_i_hoped_we_would/cdjnyhd

:P

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

       I wish I could specify fonts in Emacs in a way that would
       really be useful in making such a document.

    Are you referring to  customize-face  or something else (such
    as, e.g., .Xresources/XLFD/XFT processing)?

I mean a simple way to put some text in a different font, such as a
14-point bold font for a title, and have it (1) display on the screen
in that font and (2) have that markup saved in the file.

Emacs can already display a piece of text in that font, but it lacks a
convenient user-level feature to do this whole job.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Lennart Borgman]

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

On Thu, Nov 21, 2013 at 10:27 PM, Richard Stallman <rms@gnu.org> wrote:

>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
>
>        I wish I could specify fonts in Emacs in a way that would
>        really be useful in making such a document.
>
>     Are you referring to  customize-face  or something else (such
>     as, e.g., .Xresources/XLFD/XFT processing)?
>
> I mean a simple way to put some text in a different font, such as a
> 14-point bold font for a title, and have it (1) display on the screen
> in that font and (2) have that markup saved in the file.
>
> Emacs can already display a piece of text in that font, but it lacks a
> convenient user-level feature to do this whole job.
>

Maybe it is worth mentioning here (to avoid confusion) that the convenient
user-level feature would be using "styles" as it is normally called in word
processords (not direct formatting - which is a kludge you use sometimes
when you are short of time, or have not learned to use a word processor
yet... ;-) )

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

RE: Emacs as word processor

[Drew Adams]

>        I wish I could specify fonts in Emacs in a way that would
>        really be useful in making such a document.
> 
>     Are you referring to customize-face or something else (such
>     as, e.g., .Xresources/XLFD/XFT processing)?
> 
> I mean a simple way to put some text in a different font, such as a
> 14-point bold font for a title, and have it (1) display on the
> screen in that font and (2) have that markup saved in the file.
> 
> Emacs can already display a piece of text in that font, but it lacks
> a convenient user-level feature to do this whole job.

You can already do all of that (the "whole job"), FWIW.  (Not that
that your more general request is limited to this.)

1. Enriched mode lets you save highlighting permanently - see
   (emacs) `Enriched Mode'.

2. Facemenu lets you highlight text easily, including text that you
   will type from now on.

There are other ways, besides facemenu, to highlight, of course.
And there are 3rd-party libraries that help with this (e.g., "I mean
a simple way").

Here is one - `highlight.el':
http://www.emacswiki.org/HighlightLibrary
http://www.emacswiki.org/emacs-en/download/highlight.el

See also `facemenu+.el':
http://www.emacswiki.org/FaceMenuPlus

Re: Emacs as word processor

[Pascal J. Bourguignon]

Richard Stallman <rms@gnu.org> writes:

> I mean a simple way to put some text in a different font, such as a
> 14-point bold font for a title, and have it (1) display on the screen
> in that font and (2) have that markup saved in the file.
>
> Emacs can already display a piece of text in that font, but it lacks a
> convenient user-level feature to do this whole job.

So, let's start some specifications for an emacs wordprocessing-mode.

- define a page size + page margins for the document.

- define header, body and footer areas of the pages.  They can be
  specified with versions for odd and even pages, and with alternate
  versions for pages beginning chapters or sections.  They can also
  contain dynamic parts (eg. foot notes from text laid out on a page may
  be inserted in the footer of the page).

  Since headers and footers can be edited with styles too, editing them
  would have to call up secondary WYSIWIG windows.

- define styles, apply styles to tags.

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

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

  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.
  

One problem is that there are parts that have a lot of editable
metadata, but which are not represented at all in a WYSIWIG document.
That's 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.

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.



In terms of user interface this kind of word processor also has this
problem: you have to have a duplicate set of commands for the metadata
than for the data.

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, since basically we have in the
WYSIWIG window only the data (which can edited with usual emacs text
editing commands), and in the metadata window, only the metadata of the
current cell (or the current path of metadata nodes from the root of the
document down to the current cell, in the document structural
hierarchy).

+------------------------------------------------------------+
|    Chapter 1. Example
|
|       Section 1.1. Subtitle
|               
|          Sentence 1 of paragraph 1.  [S]entence 2 of
|          paragraph 1. 
+--U:**- Document.ewp ----(word)------------------------------+
| <document style="book">
|   <chapter style="nice">
|     <section style="standard">
|       <paragraph style="example" indent="0"
|                  leftmargin="0.5cm" rightmargin="1cm">
|         <character fontsize="+2">
+--U:**- Document.ewp/style.estyle ----(word-style)-----------+

With [S] representing the cursor on the letter S.


I don't see how usual emacs commands can be used to edit such a style
sheet path in the metadata window, since it's kind of a transveral
view.  Of course, when giving a command to change eg. the font of a
region, we could have text to edit with the regular emacs commands,
either in the minibuffer or in a box in the metadata window, but a M-x
replace-string RET would not be too useful on such a view.

Also, notice that a lot of interesting commands can be implemented, that
don't have a nice representation of the data they would work on.

For example, we could want a command that would replace the style of all
paragraph from "standard" to "personalized".  
M-x replace-paragraph-style RET standard RET personalized RET

This would reflect on the WYSIWIG window as an updated layout and
presentation.  And if we happen to have the cursor on a paragraph that
had the "standard" style, that would update the metadata window to now
show that the current paragraph style is now "personalized".  Buf if
that wasn't the case, we would have no feed back, or just a little feed
back in the WYSIWIG window, but often style changes are not drastic
therefore little noticeable.


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.


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

And that the work needed to implement it will be offset by the sure win
that with such a set of commands, we will be able to further write other
commands in emacs lisp to manipulate emacs word processing document.
But then consider also that if the document is a structured tree, it can
be represented as a sexp (and only a validator would be needed to put
back such a document sexp modified by some user command), and similarly,
the style sheet can be represented as a sexp, so fundalementaly, no
additionnal function or commands are used to write emacs lisp code to
manipulate them.  We can still provide some utility to ease navigation
and modification of those trees while keeping their validity as document
and metadata trees.  A little like we could just take (buffer-substring)
and modify it in lisp before putting it back into the buffer, or we
could use (forward-word), (delete-region s e), etc, to edit the buffer
directly.  Only now we don't have just words and informal paragraph, but
we have a true document structure to support the styles, and we have a
metadata buffer with commands to edit the style sheet.  (map-styles
(lambda (style) (incf (style-fontsize style))) document) (add-style
"newstyle" '(:fontsize (pt 10) :left-margin (cm 3))) (replace-style
'paragraph "oldstyle" "newstyle")


Finally, let's note that a system like docbook can deal with different
kinds of document structures thru the DTD, and that the XSL are designed
to process specific kinds of DTD, so the structure of the style sheets
and the structure of the documents are not hard coded, but can be
parameterized with the equivalent of the DTD.  I'd move to support
docbook file formats, XML, XSL and DTD as external format for the emacs
word processing mode, as long as we convert them internally as sexps so
we may process them in a lispy way.

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

Re: Emacs as word processor

[Stephen J. Turnbull]

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

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    And one of the reddit comments says:

      "Patches welcome, RMS."

Whoever said that doesn't understand the structure of the GNU Project,
and seems to pretend he is the Emacs maintainer.

Would someone like to post a response there -- saying that I'm the
head of the GNU Project, as well as the initial and main developer of
GNU Emacs, not just a random user?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    To be frank, I think your goals for this feature are incoherent.  You
    say you want non-Emacs users to use Emacs, then you turn around and
    deprecate exactly those features of this project (Word file-format
    compatibility, *Office-alike UI).

I think you misunderstood what I said.

I said that people should not send Word files.  That is a different
question from whether we should handle that format.  I think we should.

What I said about the UI is that surely it would not be so similar
that people would get confused.  To make them similar would be a
tremendous additional job.

I don't think we need to do that.  People can adapt to different UI
details.  (It would be a much smaller adaptation than adapting to
today's Emacs.)  However, people could eventually work on that if they
want to.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    ========================================================================
    * A headline

    A paragraphe.
    ========================================================================

    C-c C-e l o

    If (La)TeX is installed on the machine, this will open a PDF file.

It might work for me personally.  However, I think users
who like GUIs and WYSIWYG would not be very happy with it.

    We could make it easy to export continuously in the background and
    display the PDF/ODT part in another window, this way one would really
    see what you get, in real time.

That would require formatting the document very very fast.
The longer the document is, the faster the machine would have to be.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Ivan Andrus]

On Nov 21, 2013, at 11:54 PM, Richard Stallman <rms@gnu.org> wrote:

>   And one of the reddit comments says:
> 
>     "Patches welcome, RMS."
> 
> Whoever said that doesn't understand the structure of the GNU Project,
> and seems to pretend he is the Emacs maintainer.
> 
> Would someone like to post a response there -- saying that I'm the
> head of the GNU Project, as well as the initial and main developer of
> GNU Emacs, not just a random user?

I'm sure (s)he knows exactly who you are.  And that's why it's funny.  

-Ivan

Re: Emacs as word processor

[Andreas Röhler]

Am 21.11.2013 20:06, schrieb Eli Zaretskii:
>> Date: Thu, 21 Nov 2013 19:34:40 +0100
>> From: Andreas Röhler <andreas.roehler@online.de>
>> CC: Eli Zaretskii <eliz@gnu.org>
>>
>> Am 21.11.2013 17:21, schrieb Eli Zaretskii:
>>
>>>> Also don't think Emacs may change it's path that easily: it would mean to turn from producer domination into a kind of consumer market.
>>>> AFAIS there is no infrastructure for this.
>>>
>>> Before we worry about popularity, we should worry about functionality.
>>
>> You still didn't get it. It's about usability, which is grown a kind of science, while often ignored here - with some the notable exceptions, yes.
>
> Popularity has almost nothing to do with usability, in my experience.

So why you are talking about?
At stake is how to collect info WRT usability - which entered yet in a comprehensive and systematic way AFAIS.

>
> And again, this is tangential to what Richard wanted to discuss.
>

Richard's question made some topics un-deniable which were raised already. The need to reflect the tutorial for example.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Thu, 21 Nov 2013 14:12:58 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > Emacs can already display a piece of text in that font, but it lacks
> > a convenient user-level feature to do this whole job.
> 
> You can already do all of that (the "whole job"), FWIW.  (Not that
> that your more general request is limited to this.)
> 
> 1. Enriched mode lets you save highlighting permanently - see
>    (emacs) `Enriched Mode'.
> 
> 2. Facemenu lets you highlight text easily, including text that you
>    will type from now on.

These features fall short of letting you specify the font and/or its
size, as well as a few other attributes.  (Which is a historical
accident: when enriched.el and facemenu.el were written, Emacs did not
yet support variable sizes and fonts.)  All you can do is select one
of the existing faces.  Making a new face is a tedious and not very
user-friendly job.

What Richard means is let users specify font and/or size as part of
what M-o (and the corresponding menu items) provide, which means the
face will be created on the fly, like what facemenu already does for
colors and other attributes it supports.

IOW, facemenu.el should be extended to support all the face attributes
Emacs acquired post 21.1.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Fri, 22 Nov 2013 01:54:35 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, ttn@gnu.org, asr@ufl.edu, emacs-devel@gnu.org
> 
>     We could make it easy to export continuously in the background and
>     display the PDF/ODT part in another window, this way one would really
>     see what you get, in real time.
> 
> That would require formatting the document very very fast.
> The longer the document is, the faster the machine would have to be.

To say nothing of the fact that incomplete documents might cause the
formatting to fail entirely.

Re: Emacs as word processor

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 22 Nov 2013 01:54:35 -0500
>> From: Richard Stallman <rms@gnu.org>
>> CC: eliz@gnu.org, ttn@gnu.org, asr@ufl.edu, emacs-devel@gnu.org
>> 
>>     We could make it easy to export continuously in the background and
>>     display the PDF/ODT part in another window, this way one would really
>>     see what you get, in real time.
>> 
>> That would require formatting the document very very fast.
>> The longer the document is, the faster the machine would have to be.
>
> To say nothing of the fact that incomplete documents might cause the
> formatting to fail entirely.

That's true.

Still, we already can preview LaTeX snippets within the Org buffer,
and there must be some neat previewing in another window that stands
between previewing small snippets and getting a fully exported doc.

I will see what we can do to reach this "something inbetween", as
it seems to be an interesting and useful goal /per se/.

-- 
 Bastien

Re: Emacs as word processor

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: rms@gnu.org,  ttn@gnu.org,  asr@ufl.edu,  emacs-devel@gnu.org
> Date: Thu, 21 Nov 2013 18:43:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but you could assume I knew about Org (and use it ;-).
> 
> Sorry, I know you have been (and are still?) using Org!

Yes, still do, although I use only a tiny fraction of its
functionality.

> > Of course, that file and
> > enriched.el are dormant for the last 20 years, so don't expect too
> > much.  But it could be a starting point, and the display engine gained
> > a lot of functionality that was missing in 1994.
> 
> Yes, but this solution is just for Emacs people.

We _want_ a solution for Emacs people.  For the rest, there should be
back-end export facilities and print capabilities, which are a much
simpler job and are already available, or close to that.

By contrast, the real-time presentation part remains largely unsolved.

Re: Emacs as word processor

[Rasmus]

Richard Stallman <rms@gnu.org> writes:

>     We could make it easy to export continuously in the background and
>     display the PDF/ODT part in another window, this way one would really
>     see what you get, in real time.
>
> That would require formatting the document very very fast.
> The longer the document is, the faster the machine would have to be.

At least with LaTeX the issue can somewhat be mitigated by an
intelligent LaTeX daemon like latexmk.  It monitors changes and when a
change occurs it only re-compiles the relevant parts.  I don't know if
this is smart enough to work on single file documents.  Org could
automatically export a new .tex file upon changes.  Latexmk would
update the pdf.

I don't know of a solution to ODT.

–Rasmus

-- 
May the Force be with you

Re: Emacs as word processor

[Rüdiger Sonderfeld]

And now even German language tech news

http://www.heise.de/open/meldung/Stallman-wuenscht-sich-WYSIWYG-Emacs-2052459.html

On Thursday 21 November 2013 09:34:46 Allen S. Rout wrote:
> So, this conversation has made both Reddit and Hacker News.
> 
> https://news.ycombinator.com/item?id=6773529
> 
> http://www.reddit.com/r/emacs/comments/1r4j5c/richard_stallman_25_years_ago_
> i_hoped_we_would/
> :)
> 
> - Allen S. Rout

Re: Emacs as word processor

[Stefan Monnier]

> yet support variable sizes and fonts.)  All you can do is select one
> of the existing faces.

We would only want to lift that restriction if we want to provide
bad-WYSIWYG.  Good-WYSIWYG on the other hand is perfectly happy with
that restriction, since the appearance of particular elements is only
specified indirectly via style sheets.


        Stefan

Re: Emacs as word processor

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  ttn@gnu.org,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 22 Nov 2013 08:56:45 -0500
> 
> > yet support variable sizes and fonts.)  All you can do is select one
> > of the existing faces.
> 
> We would only want to lift that restriction if we want to provide
> bad-WYSIWYG.  Good-WYSIWYG on the other hand is perfectly happy with
> that restriction, since the appearance of particular elements is only
> specified indirectly via style sheets.

I guess you've never used any of the *Office word processors, because
they allow this quite easily: there's a font selection combo on the
tool bar, and a size selection combo right next to it.  You mark the
text, then select any font and/or any size, and the marked text
acquires those attributes.  There are also tool-bar button to
gradually increase/decrease the size of the selected text.

Of course, there's also a style selection combo, which works the same
way, but I don't see how the former is "bad-WYSIWYG", certainly not as
opposed to the latter.  FWIW, I use the former very frequently,
because its effect is much more predictable than that of the style
(which comes with many strings attached, some of which you don't see
until it's too late).

Re: Emacs as word processor

[Lennart Borgman]

On Fri, Nov 22, 2013 at 3:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> I guess you've never used any of the *Office word processors, because
> they allow this quite easily: there's a font selection combo on the
> tool bar, and a size selection combo right next to it.  You mark the
> text, then select any font and/or any size, and the marked text
> acquires those attributes.  There are also tool-bar button to
> gradually increase/decrease the size of the selected text.

I use to help friends sometimes who have done exactly that when they
are writing a thesis. A big trouble. Of course they owe me a lot after
such help. ;-)

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Fri, 22 Nov 2013 01:51:37 +0100
> 
> - define a page size + page margins for the document.

IMO, this is more important for printing.  For display, it's enough to
start with the locale's defaults.

> - define header, body and footer areas of the pages.  They can be
>   specified with versions for odd and even pages, and with alternate
>   versions for pages beginning chapters or sections.  They can also
>   contain dynamic parts (eg. foot notes from text laid out on a page may
>   be inserted in the footer of the page).
> 
>   Since headers and footers can be edited with styles too, editing them
>   would have to call up secondary WYSIWIG windows.

Separate windows could be a solution, but it would be much more cool
to do what the word processors do: make the rest of the page
un-editable, and dim it to make that apparent, then let you edit only
the header/footer part.

> - define styles, apply styles to tags.

Isn't a "style" just another word for a "face"?

> - assign parenthesized tags to text ranges (in a hierarchical structure
>   similar to SGML).

Not sure what for.  This is a solution to what problem?

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

I think you underestimate the power and feature-richness of the
current Emacs display engine.  We should try using it first, before we
decide that it is inadequate and should be replaced or significantly
changed.

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

I see no need for abandoning graphical text display we use now.  None
of the leading word processors does, AFAIK.  Switching to displaying
pictures has many drawbacks; e.g., you cannot easily copy/paste with
it, and the display complexities will grow by orders of magnitude, for
now good reason.

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

We have the fringes and the display margins for that, we just need to
use them.

> One problem is that there are parts that have a lot of editable
> metadata, but which are not represented at all in a WYSIWIG document.
> That's 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.
> 
> 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.

The leading word processors have this feature, so we should have that
as well.  It doesn't have to be another window, though: we could show
the meta-data and control codes as part of the text.

> In terms of user interface this kind of word processor also has this
> problem: you have to have a duplicate set of commands for the metadata
> than for the data.
> 
> 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, since basically we have in the
> WYSIWIG window only the data (which can edited with usual emacs text
> editing commands), and in the metadata window, only the metadata of the
> current cell (or the current path of metadata nodes from the root of the
> document down to the current cell, in the document structural
> hierarchy).

It's much better to have the same command do both.  We could implement
heuristics that would guess the user intent most of the time, with
user options to override that as needed.  Most users will not need nor
want to edit the formal description of the style, be it XML or
whatever.  They will settle for a Customize way of personalizing the
styles.

Re: Emacs as word processor

[Davis Herring]

>> - define a page size + page margins for the document.
> 
> IMO, this is more important for printing.  For display, it's enough to
> start with the locale's defaults.

If you're not going to allow them to be changed, you need to not
paginate in the display at all, to avoid misleading the user into making
adjustments that are unnecessary/wrong with their (eventual) print settings.

>> - define styles, apply styles to tags.
> 
> Isn't a "style" just another word for a "face"?

No, because it can include things like paragraph indentation and
language choice (for spell check).

> The leading word processors have this feature, so we should have that
> as well.  It doesn't have to be another window, though: we could show
> the meta-data and control codes as part of the text.

This is approximately what WordPerfect does when using "Display Codes".

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Emacs as word processor

[Yuri Khan]

On Fri, Nov 22, 2013 at 9:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I guess you've never used any of the *Office word processors, because
> they allow this quite easily: there's a font selection combo on the
> tool bar, and a size selection combo right next to it.

Yes, and those, along with the <bold> <italic> <underline> buttons,
are a sure way to create an unmaintainable document. It is easy and
predictable at first and is fine if you only need to hack up a quick
page, print it out and not even bother to save it. But when writing
any kind of a long-lived document, direct formatting is a curse.

I have often said that the one way to fix Word is to have all direct
formatting controls hidden by default, and only allow style-based
formatting. (This is roughly equivalent to stripping HTML Transitional
down to HTML Strict and doing all styling via CSS.)

Re: Emacs as word processor

[Lennart Borgman]

>> Isn't a "style" just another word for a "face"?
>
> No, because it can include things like paragraph indentation and
> language choice (for spell check).

Style is tighed to the logical structure of the document. That is the
point of it. (A very idea.)

Re: Emacs as word processor

[John Yates]

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

On Fri, Nov 22, 2013 at 10:39 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Fri, Nov 22, 2013 at 9:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Yes, and those, along with the <bold> <italic> <underline> buttons,
> are a sure way to create an unmaintainable document. It is easy and
> predictable at first and is fine if you only need to hack up a quick
> page, print it out and not even bother to save it. But when writing
> any kind of a long-lived document, direct formatting is a curse.
>

+100.

I have often said that the one way to fix Word is to have all direct
> formatting controls hidden by default, and only allow style-based
> formatting.


Again, +100.

Even M$Word for a while has had both paragraph styles and character
(arbitrary text range) styles.

/john

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

Re: Emacs as word processor

[Karl Voit]

Hello Richard!

* Richard Stallman <rms@gnu.org> wrote:
> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.
>
> Could people please start working on the features that are needed?

What a mind-blowing request.

However, I do see several issues with that.

First of all, I claim that WYSIWYG has issues of its own. Please do
read [1]. I admit, that this text is very old but the key points are
still valid. Most people I know who know WYSIWYG *and* their
alternatives are not always very happy with using WYSIWYG. So why
follow this path which is know to be faulty?

Second, there are technical issues I do see. GNU/Emacs lacks a *lot*
in terms of GUI widget-set. Yes, I do believe that ribbons are
better[2] than menus for WYSIWYG tools but it's not only ribbons
that are missing. Users of WYSIWYG-tools are heavily using buttons
(mainly) and menu items (seldom) as studies show. This is not the
way GNU/Emacs is working. The button bar is very static. Not every
functionality is reachable via menu bar. Besides, menu bars got the
severe issue mentioned in [2][3] and we should do better than this.

Third, there is a huge difference in the typical group of GNU/Emacs
users and WYSIWYG-tool-users. GNU/Emacs users are happy to learn
keyboard shortcuts, tweak their environment to meet their
requirements, want to have absolutely control on what the computer
is doing, and so forth. It is a group of geeks[4] who is willing to
spend a certain time learning stuff in order to get a life-time
benefit.

On the other side, typical WYSIWYG-users just want to get the thing
done without even thinking of investing some time into learning a
tool that might offer the same. Please do not misinterpret me: this
is completely fine for many cases. I am oversimplifying a bit but
this is how the situation is to me. I gave many talks, workshops,
did one-to-one teaching, talked to other geeks and non-geeks in
order to promote the best tool for each job. Sometimes it is a
WYSIWYG-tool I recommend, sometimes it is a power-tool like
GNU/Emacs. 

Maybe I lack a huge amount of fantasy here but I don't think that
GNU/Emacs is going to be used by Joe Average who has no special IT
knowledge when there are alternative tools like Microsoft Word or
LibreOffice.

Besides: if you want to attract non-geeks, prepare that they will
complain that there is no suitable support, that they do not want to
use mailing-lists or usenet (they prefer something which is called
Web Forum), and so forth. Giving them advice like "C-h t"  or "C-h
r" is nothing they accept - they need sleek web documentation and
probably nicely formatted PDFs. It is a completely different world
to enter.

In your other emails in this thread I know that you are thinking of
getting more Joe Averages to Emacs. What I assume is that you want
to have WYSIWYG-features not because *you* want to use it. I assume
that you are thinking of the possible wishes of a novice or
occasional computer user. So if my assumption is true, this
WYSIWYG-wish is not something that arises from your use cases.
Therefore you are assuming what other people might want to use.

However, there are tools out there, that provide a solution to this
use case. I already mentioned Microsoft Word and LibreOffice as the
most prominent WYSIWYG-tools for text processing. Joe Averages are
already using them and - as I already mentioned above - I can not
think of a way that they are changing their choice to GNU/Emacs.

For the typical GNU/Emacs user, there are alternatives that result
in results they are happy to live with: AucTeX/LaTeX, Org-mode [5],
or even LibreOffice. I never heard a geek saying "there has to be an
alternative to the current tool-set" (besides the usual issues which
may be fixed or improved in the future like, e.g., LaTeX and
Unicode-support, better error messages, and so forth).

Something which would be quite nice to think of would be using
GNU/Emacs (only) as a plug-in-editor for a wider range of software
tools.  I have to tweak my systems in order to be able to edit web
forms, Wiki pages, OWA emails, and so forth in my GNU/Emacs.
Seamlessly pushing text between third party software and GNU/Emacs
is something I would like to be eased. Write the text in GNU/Emacs
and process it with other tools.

In contrast to people telling you that your idea is not good, I
would like to find out, what the (hidden) motivation is. Is it the
"get Joe Average to use GNU/Emacs"? Is it the "I want to replace
LibreOffice with GNU/Linux"? Is it "I would like to see major and
new areas for GNU/Emacs"? Or is it something else?


  1. http://ricardo.ecn.wfu.edu/~cottrell/wp.html

  2. Novice users and occasionally users are able to use much more
  functionality with context-related feature representation than
  with deeply nested menus that are using only strict hierarchies
  for managing functionality. Not only the vocabulary problem [3] is
  proving this attempt a wrong one.

  3. https://en.wikipedia.org/wiki/Susan_Dumais

  4. I am proud to be called "a geek". Nothing to be ashamed of.

  5. You *definitely* have to get in touch with Org-mode! I guess it
  is the reason number one that new users get fascinated and switch
  to GNU/Emacs these days! I personally switched from gvim to
  GNU/Emacs just because of the beautiful rich world of Org-mode.
  Don't worry, Org-mode is huge but you can happily start with a
  very small sub-set of features. You'll get to the rest sooner or
  later :-)

-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Fri, 22 Nov 2013 08:26:48 -0700
> From: Davis Herring <herring@lanl.gov>
> CC: "Pascal J. Bourguignon" <pjb@informatimago.com>, emacs-devel@gnu.org
> 
> > Isn't a "style" just another word for a "face"?
> 
> No, because it can include things like paragraph indentation and
> language choice (for spell check).

Which is exactly the problem many users have with styles.  So IMO we
shouldn't repeat those UI mistakes in Emacs, and keep these separated.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Fri, 22 Nov 2013 22:39:55 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, ttn@gnu.org, rms@gnu.org, 
> 	Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> On Fri, Nov 22, 2013 at 9:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I guess you've never used any of the *Office word processors, because
> > they allow this quite easily: there's a font selection combo on the
> > tool bar, and a size selection combo right next to it.
> 
> Yes, and those, along with the <bold> <italic> <underline> buttons,
> are a sure way to create an unmaintainable document. It is easy and
> predictable at first and is fine if you only need to hack up a quick
> page, print it out and not even bother to save it. But when writing
> any kind of a long-lived document, direct formatting is a curse.

We are not here to force any particular workflows on users.  If they
find such document unmaintainable, they will refrain from doing that.

(FWIW, I have yet to see why applying these attributes makes documents
"unmaintainable", and I write large documents for a living.)

Re: Emacs as word processor

[Eli Zaretskii]

> From: Karl Voit <devnull@Karl-Voit.at>
> Date: Fri, 22 Nov 2013 17:19:34 +0100
> 
> First of all, I claim that WYSIWYG has issues of its own. Please do
> read [1]. I admit, that this text is very old but the key points are
> still valid. Most people I know who know WYSIWYG *and* their
> alternatives are not always very happy with using WYSIWYG. So why
> follow this path which is know to be faulty?

Because it is not necessarily faulty.

That document presents a point of view.  Some will agree with it, some
won't.  Emacs is not about forcing one particular POV on its users.
Quite the contrary, it's about giving them as much freedom as possible
to do things their way.

> Second, there are technical issues I do see. GNU/Emacs lacks a *lot*
> in terms of GUI widget-set. Yes, I do believe that ribbons are
> better[2] than menus for WYSIWYG tools but it's not only ribbons
> that are missing. Users of WYSIWYG-tools are heavily using buttons
> (mainly) and menu items (seldom) as studies show. This is not the
> way GNU/Emacs is working. The button bar is very static. Not every
> functionality is reachable via menu bar. Besides, menu bars got the
> severe issue mentioned in [2][3] and we should do better than this.

Yes, the job at hand is not small.  But does that mean we shouldn't
take steps in that direction?  I hope not.

> Third, there is a huge difference in the typical group of GNU/Emacs
> users and WYSIWYG-tool-users. GNU/Emacs users are happy to learn
> keyboard shortcuts, tweak their environment to meet their
> requirements, want to have absolutely control on what the computer
> is doing, and so forth. It is a group of geeks[4] who is willing to
> spend a certain time learning stuff in order to get a life-time
> benefit.
> 
> On the other side, typical WYSIWYG-users just want to get the thing
> done without even thinking of investing some time into learning a
> tool that might offer the same. Please do not misinterpret me: this
> is completely fine for many cases. I am oversimplifying a bit but
> this is how the situation is to me. I gave many talks, workshops,
> did one-to-one teaching, talked to other geeks and non-geeks in
> order to promote the best tool for each job. Sometimes it is a
> WYSIWYG-tool I recommend, sometimes it is a power-tool like
> GNU/Emacs. 
> 
> Maybe I lack a huge amount of fantasy here but I don't think that
> GNU/Emacs is going to be used by Joe Average who has no special IT
> knowledge when there are alternative tools like Microsoft Word or
> LibreOffice.

We want to attract Joe Average's.  But what we want more is to give
Emacs geeks a way to compose document in WYSIWYGy fashion.

> Besides: if you want to attract non-geeks, prepare that they will
> complain that there is no suitable support, that they do not want to
> use mailing-lists or usenet (they prefer something which is called
> Web Forum), and so forth.

Let them complain, we've heard those complaints for many years and
didn't care.

But why shouldn't someone like RMS be able to compose a simple
document without switching to LibreOffice or whatnot?  There's no
excuse for that.

> For the typical GNU/Emacs user, there are alternatives that result
> in results they are happy to live with: AucTeX/LaTeX, Org-mode [5],
> or even LibreOffice.

For a devoted Emacs user, an Emacs solution will always blow any
3rd-party solution out of the water.  That's why there's Org mode,
Gnus, Flymake, GUD, Flyspell, etc., even though alternatives to each
one of these exist, and some of them might even be better/more
sophisticated/whatever than what Emacs has to offer in these areas.

Re: Emacs as word processor

[John Yates]

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

On Fri, Nov 22, 2013 at 12:56 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> Which is exactly the problem many users have with styles.  So IMO we
> shouldn't repeat those UI mistakes in Emacs, and keep these separated.
>

Eli,

Please elaborate.  How do you see a user setting up a list structure
indented w.r.t. its surrounding context.  How would that user proceed to
change the indentation?  Change for a bullet list to numbered?  What if
there are multiple such lists through the document and the user would like
to keep their appearance consistent?

/john

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

Re: Emacs as word processor

[Thorsten Jolitz]

Bastien <bzg@gnu.org> writes:

> But WYSIWYG as LibreOffice does it solves really two problems: one is
> the real WYSIWYG part (to edit a document with rich text formatting),
> the other one is a social one (to edit a document as others will see
> it.)

I once tried to help somebody writing a thesis in LaTeX with
[[(http://www.lyx.org/][LyX]]:

#+begin_quote
LyX is a document processor that encourages an approach to writing based on
the structure of your documents (WYSIWYM) and not simply their appearance
(WYSIWYG).

LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a
graphical interface.
#+end_quote

Quite an impressive program, but is it really a success? Very quickly, LyX
itself became the biggest obstacle of the project, and I realized how
wonderful plain tex(t) in an Emacs buffer really is ... the thesis was finally
written in Word or Open Office or so.

For me, LyX lacked the power and flexibility of Emacs AucTex as well as the
usability of the Libre Office alikes. Instead of combining the strengths of
both worlds it lost the benefits of both approaches. 

So if that might happen to an WYSIWYG Emacs, I would say its not worth the
pain, and all the effort should rather go into making the already fantastic
Org-mode even better. 

-- 
cheers,
Thorsten

Re: Emacs as word processor

[Pascal J. Bourguignon]

On 2013/11/22, at 16:04 , Eli Zaretskii wrote:

>> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
>> Date: Fri, 22 Nov 2013 01:51:37 +0100
>> 
>> - define a page size + page margins for the document.
> 
> IMO, this is more important for printing.  For display, it's enough to
> start with the locale's defaults.

My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.

Paper, PDF file, web page.

Paper and PDF files are mostly the same, rendering on a web page is different (the pagination differs).

Page size is important to a document, because unfortunately, automatic layout cannot take decisions like reordering paragraphs or figures, and editing paragraphs so that they fit on a page.

And again, THIS is the only reason why WYSIWIG as some value.


If you want to consider webpages, I'd say that nowadays you would still have to consider the size of the area where the document is to be rendered, since web designers tend to enforce fixed frames, instead of letting the browser flow the text to the random window size.  This is a fact of life.  So you may also have to set at least a page width to edit WYSIWIGLY a web page.



>> - define header, body and footer areas of the pages.  They can be
>>  specified with versions for odd and even pages, and with alternate
>>  versions for pages beginning chapters or sections.  They can also
>>  contain dynamic parts (eg. foot notes from text laid out on a page may
>>  be inserted in the footer of the page).
>> 
>>  Since headers and footers can be edited with styles too, editing them
>>  would have to call up secondary WYSIWIG windows.
> 
> Separate windows could be a solution, but it would be much more cool
> to do what the word processors do: make the rest of the page
> un-editable, and dim it to make that apparent, then let you edit only
> the header/footer part.

Possibly.  This is a user interface question that can be solved later.  What I wanted to point out, is that headers and footers, like styles, are a-priori independent of the page or even the document they appear in.


>> - define styles, apply styles to tags.
> 
> Isn't a "style" just another word for a "face"?

For a character, perhaps.  For higher level nodes, a style may be more complex, up to procedural styles, were you call up a lisp function to "font-lock" and justify the node (paragraph, chapter, etc).  For paragraphs you would have margins and indentations and perhaps drop cap styles, etc.


>> - assign parenthesized tags to text ranges (in a hierarchical structure
>>  similar to SGML).
> 
> Not sure what for.  This is a solution to what problem?

What I mean here is some kind of structured editing.

To split a paragraph in two, we can admit the usual RET key.

To split a section in two, we can admit the usual insertion of a section title.
But already here, most probably the user will enter a new paragraph containing the section title, and then select it and apply a header "style".  Well, it's not style, it's the specification of a section header tag to this text, and by inference, the spitting of the current section in two.

Those two examples have conventional "width of the ass of the horse" user interfaces, for conventional pre-defined tags: <section> <title> <para>.

But with the introduction of XSL and DTD, the user can be allowed to edit documents with a structure not pre-wired, with tags having now pre-defined conventional user interface.  

Therefore we need a standard way to edit the document tree.

In case of sexps, we use paredit.  What do we use to edit a tree that is invisible, but thru its typographied and laid yout leaves?





>> - 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.
> 
> I think you underestimate the power and feature-richness of the
> current Emacs display engine.  We should try using it first, before we
> decide that it is inadequate and should be replaced or significantly
> changed.

Perhaps.  It's true that with truncate-lines mode, we'd get a a homothetic space, but can we adjust the height of the lines, can we adjust margins (to subpixel sizes). We'd have to disable removing truncate-lines mode, and we'd have to ensure that changing the line count or line height doesn't change the page height.

I've not read the source, perhaps it's already implemented, but I've never seen in the behavior of emacs display engine indications that it's able to change characters in a page without shifting everything beyond them.


>>  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.
> 
> I see no need for abandoning graphical text display we use now.

WYSIWIG.

What we have now is not.


> None of the leading word processors does, AFAIK.  Switching to displaying
> pictures has many drawbacks; e.g., you cannot easily copy/paste with
> it, and the display complexities will grow by orders of magnitude, for
> now good reason.

Any WYSIWIG word processor displays a picture on the screen, and let you edit the underlying text data structure.  Even emacs does just that, only it has a more direct correspondance between character cells on screens and character slots in the buffer.

For example, in scrolling a word processor let you scroll pixel by pixel, while emacs let you only scroll line by line, even in the splash window.

Just take a good look at any WYSIWIG word processor window, and count the character pixels vs. the graphic pixels.  There's a lot of graphics on them: rulers, margins, 


>>  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.
> 
> We have the fringes and the display margins for that, we just need to
> use them.

WYSIWIG.


I wouldn't mind a text editor that would let us edit enriched text. 
But strangely, I doubt that would attract new users.



>> One problem is that there are parts that have a lot of editable
>> metadata, but which are not represented at all in a WYSIWIG document.
>> That's 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.
>> 
>> 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.
> 
> The leading word processors have this feature, so we should have that
> as well.  It doesn't have to be another window, though: we could show
> the meta-data and control codes as part of the text.

Well, not part of the text, that would defeat the WYSIWIG aspect, but they may be represented graphically, overlaid on or around the text.  There may be tip tool boxes, and stuff.

Now, some web editors provide three views of the document:

- WYSIWIG web page, rendered just like in a browser, but editable as in any word processor.

- tagged document, where the web page is still rendered like in a browser, but each element is adorned with a graphic tag that can be manipulated (selected, edited, moved around, etc).

- plain text editor of the HTML.


I would say that this solution works well enough, you can switch easily from one view to another depending on the kind of editing action you want to perform at the moment, and you have full access to all the levels.

But in a way, it represents the failure of the WYSIWIG word processor, since as soon as you have something more complex than MacWrite, basically, you have to revert to a structured editor, or to a plain text editor.

For us programmers it would be a good and nice solution.

But users can't deal with the structured view and much less with the "code" of the HTML text view.

So I think we should try to find a solution to let plain users perform structural editing of their documents and style sheets easily, in a WYSIWIG editor.  But indeed perhaps there's no other solution than to present alternative, lower level  and non WYSIWIG views.



>> In terms of user interface this kind of word processor also has this
>> problem: you have to have a duplicate set of commands for the metadata
>> than for the data.
>> 
>> 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, since basically we have in the
>> WYSIWIG window only the data (which can edited with usual emacs text
>> editing commands), and in the metadata window, only the metadata of the
>> current cell (or the current path of metadata nodes from the root of the
>> document down to the current cell, in the document structural
>> hierarchy).
> 
> It's much better to have the same command do both.  We could implement
> heuristics that would guess the user intent most of the time, with
> user options to override that as needed.  Most users will not need nor
> want to edit the formal description of the style, be it XML or
> whatever.  They will settle for a Customize way of personalizing the
> styles.

Yes, or use predefined style sheets and document structures.


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

Re: Emacs as word processor

[Pascal J. Bourguignon]

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

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Fri, 22 Nov 2013 14:01:22 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: Davis Herring <herring@lanl.gov>, pjb@informatimago.com, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> How do you see a user setting up a list structure indented
> w.r.t. its surrounding context.  How would that user proceed to
> change the indentation?

With the command to change the indentation, of course, what else?

> Change for a bullet list to numbered?

With a command to change a bulleted list to a numbered one.

> What if there are multiple such lists through the document and the
> user would like to keep their appearance consistent?

With a command to change all such lists, perhaps giving the user an
opportunity to interactively confirm each one of them.

I probably don't even begin to understand what problems you have in
mind, because what I described above I do every day in Office.  And
one of the ugliest things Office sometimes does is make changes in
entirely unrelated parts of the document, changes I didn't asked for
and didn't authorize.  More often than not, I don't even know about
those changes until much later, when simply undoing them is a painful
option, since it would require undoing many other changes I did in the
meantime.

Emacs has features that make repetitive command execution very simple.
So we don't need to patronize our users and pretend we know better
what she has in mind, we could let the user repeat the command if she
wants, or offer interactive repetition, similar to M-%.  Then this
whole nightmare of elaborate styles that change things behind your
back at the most unexpected moment, like when you paste from another
document, could just go away, never to be seen again.

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Fri, 22 Nov 2013 22:06:23 +0100
> Cc: emacs-devel@gnu.org
> 
> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.

I cannot disagree more.  The main features of a document change very
little with paper size changes.

> >> - define styles, apply styles to tags.
> > 
> > Isn't a "style" just another word for a "face"?
> 
> For a character, perhaps.  For higher level nodes, a style may be more complex, up to procedural styles, were you call up a lisp function to "font-lock" and justify the node (paragraph, chapter, etc).  For paragraphs you would have margins and indentations and perhaps drop cap styles, etc.

I see no reason for these features to be connected to a style.  They
can easily be separate; keeping them separate will make it easier for
users to specify arbitrary combinations of them.

> >> - assign parenthesized tags to text ranges (in a hierarchical structure
> >>  similar to SGML).
> > 
> > Not sure what for.  This is a solution to what problem?
> 
> What I mean here is some kind of structured editing.
> 
> To split a paragraph in two, we can admit the usual RET key.
> 
> To split a section in two, we can admit the usual insertion of a section title.
> But already here, most probably the user will enter a new paragraph containing the section title, and then select it and apply a header "style".  Well, it's not style, it's the specification of a section header tag to this text, and by inference, the spitting of the current section in two.
> 
> Those two examples have conventional "width of the ass of the horse" user interfaces, for conventional pre-defined tags: <section> <title> <para>.
> 
> But with the introduction of XSL and DTD, the user can be allowed to edit documents with a structure not pre-wired, with tags having now pre-defined conventional user interface.  
> 
> Therefore we need a standard way to edit the document tree.

I think you confuse user interface with implementation.  I can easily
envision commands that insert a section header that don't need any
idea about the document tree.

> >> - 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.
> > 
> > I think you underestimate the power and feature-richness of the
> > current Emacs display engine.  We should try using it first, before we
> > decide that it is inadequate and should be replaced or significantly
> > changed.
> 
> Perhaps.  It's true that with truncate-lines mode, we'd get a a homothetic space, but can we adjust the height of the lines, can we adjust margins (to subpixel sizes).

The former is possible today, the latter can be added (but I really
don't see a need).

> We'd have to disable removing truncate-lines mode

What? why??

And why are you talking about truncate-lines, when Emacs has word-wrap
for quite some time now?

> >>  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.
> > 
> > I see no need for abandoning graphical text display we use now.
> 
> WYSIWIG.
> 
> What we have now is not.

But we can have WYSIWIG without that.

> > None of the leading word processors does, AFAIK.  Switching to displaying
> > pictures has many drawbacks; e.g., you cannot easily copy/paste with
> > it, and the display complexities will grow by orders of magnitude, for
> > now good reason.
> 
> Any WYSIWIG word processor displays a picture on the screen, and let you edit the underlying text data structure.  Even emacs does just that, only it has a more direct correspondance between character cells on screens and character slots in the buffer.

Of course, a character on glass is just a bunch of pixels.  But if
that is what you are talking about, then what exactly are you saying
that we need to change from what we have today?

> For example, in scrolling a word processor let you scroll pixel by pixel, while emacs let you only scroll line by line, even in the splash window.

Emacs has pixel-level scrolling for a long time, it just is activated
in very rare cases, so you perhaps don't know it exists.

> Just take a good look at any WYSIWIG word processor window, and count the character pixels vs. the graphic pixels.  There's a lot of graphics on them: rulers, margins, 

Emacs can display images as well, you know.  We just need to use that.

> I wouldn't mind a text editor that would let us edit enriched text. 
> But strangely, I doubt that would attract new users.

Let's care about the features first, and talk about attractors later.

Re: Emacs as word processor

[John Yates]

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

On Fri, Nov 22, 2013 at 4:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:

I see no reason for these features to be connected to a style.  They
> can easily be separate; keeping them separate will make it easier for
> users to specify arbitrary combinations of them.
>

Is that really the goal?

When I started programming 45 years ago I wrote in the only language
available for system programming: assembler.  I hand laid out every looping
construct.  I hand allocated every register.  I was entirely on my own to
identify and enforce all necessary conventions.  Using a high level
language deprives me of some of the fine control I once had.  In exchange
though I can contemplate and even complete radically larger designs.  I am
extremely grateful for a limited vocabulary of loops, for entirely
automatic register allocation and for languages that enforce strong typing.

I am unmoved by the prospect of being able to specify entirely arbitrary
combinations of all formatting elements at any and every point in my
documents.

/john

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

Re: Emacs as word processor

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
>> Date: Fri, 22 Nov 2013 22:06:23 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.
>
> I cannot disagree more.  The main features of a document change very
> little with paper size changes.

The structure of the document doesn't change (it's mostly unrelated to
the presentation or layout).  But the layout of the document depends
obviously on the target medium.  And the user of a WYSIWIG word
processor uses the information provided by the layout output graphic
view, to edit the text and structure of its document so it presents
well.

For example, if you have small sections that fit several on a page, you
would use a style where they flow on a page.  But if you have some
bigger sections, you may rather choose a style where each section starts
on its own page.  And in both cases, you may have exceptions, and bad
cases, such as the section that takes exactly one page and one line on
the following page, followed by another section started on the next
page.  If that other section is bigger than one page, you may want to
keep it starting on its own page, so you'll edit the first section so
that it takes one line less and fit on one page.

Switching to legal paper size is not an option, here all the paper pages
are A4 size, this is the norm. :-)

(Ok, an alternative would be to reduce the vertical margin, but this may
open a can of worm in the rest of the document).


So I persist, WYSIWIG = target medium representation.


If you don't specify target medium representation, then you don't need
WYSIWIG.  You may just use a structure editor (perhaps enriched with
fonts, bold and italic), and have a batch layout processor, eg. a web
browser (modulo my remarks concerning the common use of fixed size web
pages).




>> >> - assign parenthesized tags to text ranges (in a hierarchical structure
>> >>  similar to SGML).
>> > 
>> > Not sure what for.  This is a solution to what problem?
>> 
>> What I mean here is some kind of structured editing.
>> 
>> To split a paragraph in two, we can admit the usual RET key.
>> 
>> To split a section in two, we can admit the usual insertion of a section title.
>> But already here, most probably the user will enter a new paragraph
>> containing the section title, and then select it and apply a header
>> "style".  Well, it's not style, it's the specification of a section
>> header tag to this text, and by inference, the spitting of the
>> current section in two.
>> 
>> Those two examples have conventional "width of the ass of the horse"
>> user interfaces, for conventional pre-defined tags: <section>
>> <title> <para>.
>> 
>> But with the introduction of XSL and DTD, the user can be allowed to
>> edit documents with a structure not pre-wired, with tags having now
>> pre-defined conventional user interface.
>> 
>> Therefore we need a standard way to edit the document tree.
>
> I think you confuse user interface with implementation.  I can easily
> envision commands that insert a section header that don't need any
> idea about the document tree.

That's exactly what I've described above.  

What I'm asking, is what you do once the user specified a DTD containing
elements such as: <xlorf>, <grlyb> and <ashur>?  How do you edit them?


>> >> - 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.
>> > 
>> > I think you underestimate the power and feature-richness of the
>> > current Emacs display engine.  We should try using it first, before we
>> > decide that it is inadequate and should be replaced or significantly
>> > changed.
>> 
>> Perhaps.  It's true that with truncate-lines mode, we'd get a a
>> homothetic space, but can we adjust the height of the lines, can we
>> adjust margins (to subpixel sizes).
>
> The former is possible today, the latter can be added (but I really
> don't see a need).
>
>> We'd have to disable removing truncate-lines mode
>
> What? why??

Because otherwise it's not WYSIWIG anymore: without truncate-lines, the
lines are flowed and are not displayed anymore like they appear on the
printed page.


> And why are you talking about truncate-lines, when Emacs has word-wrap
> for quite some time now?

I'm not sure what you mean by word-wrap exactly?

- open some text file.
- M-x set-fill-column RET 40 RET  -- characters not 12.5 cm!
- C-x h M-x set-justification-left RET
- reduce the width of the frame or window to 30 characters wide.

Without truncate-line mode, each line is wrapped over, which is not
WYSIWIG.

With M-x visual-line-mode RET it's the same thing.


>> >>  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.
>> > 
>> > I see no need for abandoning graphical text display we use now.
>> 
>> WYSIWIG.
>> 
>> What we have now is not.
>
> But we can have WYSIWIG without that.

Well, of course.  We ALREADY have a WYSIWIG editor!
Just M-x ps-print-buffer RET and see how the printed page is exactly
like the screen.  So we have it without that.  Sure.

We even have a WYSIWIG web renderer with M-x htmlize-buffer RET.


But this is not with that that we want to attract new users, and that
is not this kind of text files document that we want to present to our
co-workers who are expecting word processed documents.



>> > None of the leading word processors does, AFAIK.  Switching to displaying
>> > pictures has many drawbacks; e.g., you cannot easily copy/paste with
>> > it, and the display complexities will grow by orders of magnitude, for
>> > now good reason.
>> 
>> Any WYSIWIG word processor displays a picture on the screen, and let
>> you edit the underlying text data structure.  Even emacs does just
>> that, only it has a more direct correspondance between character
>> cells on screens and character slots in the buffer.
>
> Of course, a character on glass is just a bunch of pixels.  But if
> that is what you are talking about, then what exactly are you saying
> that we need to change from what we have today?

Type: M-x shell RET libreoffice RET 
Click on: Text document
Type: Hello world!
Select the paragraph, 
Click on the left margin knob above and move it 0.5 inch to the right.

Notice how the page is represented, as a white rectangle, how the
margins are represented as L shapes offset from the four corners, how
rules are graphical representations with graphical graduations,
unrelated to the font sizes, notice how scrolling occurs pixel by pixel, graphically.

Select the word Hello, click on the style popup menu, select More…,
scroll down and click on Vertical Numbering Symbols.

Notice  how the word Hello is rotated 90 degree counter clock wise.

All those representations could not occur no a normal textual terminal:
they are in essence graphical.



>> For example, in scrolling a word processor let you scroll pixel by
>> pixel, while emacs let you only scroll line by line, even in the
>> splash window.
>
> Emacs has pixel-level scrolling for a long time, it just is activated
> in very rare cases, so you perhaps don't know it exists.
>
>> Just take a good look at any WYSIWIG word processor window, and
>> count the character pixels vs. the graphic pixels.  There's a lot of
>> graphics on them: rulers, margins,
>
> Emacs can display images as well, you know.  We just need to use that.
>
>> I wouldn't mind a text editor that would let us edit enriched text. 
>> But strangely, I doubt that would attract new users.
>
> Let's care about the features first, and talk about attractors later.

I won't deny that some pieces are already implemented.  Happily!
Again, for now, let's concentrate on specifications and see if that
makes something that would be worth implementing.

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

Re: Emacs as word processor

[Pascal J. Bourguignon]

John Yates <john@yates-sheets.org> writes:

> On Fri, Nov 22, 2013 at 4:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>
>     I see no reason for these features to be connected to a style.
>      They
>     can easily be separate; keeping them separate will make it easier
>     for
>     users to specify arbitrary combinations of them.
>
>
> Is that really the goal?
>
> When I started programming 45 years ago I wrote in the only language
> available for system programming: assembler.  I hand laid out every
> looping construct.  I hand allocated every register.  I was entirely
> on my own to identify and enforce all necessary conventions.  Using a
> high level language deprives me of some of the fine control I once
> had.  In exchange though I can contemplate and even complete
> radically larger designs.  I am extremely grateful for a limited
> vocabulary of loops, for entirely automatic register allocation and
> for languages that enforce strong typing.
>
> I am unmoved by the prospect of being able to specify entirely
> arbitrary combinations of all formatting elements at any and every
> point in my documents.


Well, of course, a well structured document can be laid out
automatically and produce quite readable a document.  

However, it seems to me that we encounter frequently enough local
layout or typographical problems that require manual intervention.  So I
wouldn't discard the possibility of editing locally the style, only
applicable on a single character, word, paragraph, whatever the
structural elements that need to be tuned.

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

Re: Emacs as word processor

[Stefan Monnier]

> We are not here to force any particular workflows on users.

Of course not.  That means we should make it easy for people to
introduce a new kind of face and to specify the face's appearance.
But not to let people directly specify the appearance.


        Stefan

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    2. Facemenu lets you highlight text easily, including text that you
       will type from now on.

I don't think Facemenu handles use of bigger fonts for headings.

Anyway, there are many other very simple and commonly used formatting
features that any word processor has, but Emacs doesn't have.
Those are the things I'm asking people to implement.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    What Richard means is let users specify font and/or size as part of
    what M-o (and the corresponding menu items) provide, which means the
    face will be created on the fly, like what facemenu already does for
    colors and other attributes it supports.

I don't mind if it is limited to a specific set of fonts, if it were a
broad enough set of fonts, something comparable to what LibreOffice
offers.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

I am not sure what you mean by bad-WYSIWYG or good-WYSIWYG;
I don't know whether I would agree with your judgments about them.
I think LibreOffice is a pretty good model for WYSIWYG, apart
from not being Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

Styles facilitate maintenance of large documents.  That is why Texinfo
is based on styles.  For small documents, you would not get much
benefit from the styles, and specifying fonts and other appearance
parametets directly might be less work.

But I would not mind if at first we implement only styles.
That might be good enough to start with.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    First of all, I claim that WYSIWYG has issues of its own. Please do
    read [1]. I admit, that this text is very old but the key points are
    still valid. Most people I know who know WYSIWYG *and* their
    alternatives are not always very happy with using WYSIWYG. So why
    follow this path which is know to be faulty?

It's not faulty.  It's imperfect.

The other points are just jobs to be done.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    >     Would it be okay, for instance, to edit with Emacs in one buffer and
    >     have a separate libreoffice window update at the same time?
    >
    > Maybe it would be.  Is that feasible?

    Yes it's feasible. I can have a look, because it could be an interesting
    demonstration of the Emacs Xwidget branch as well.

    Here is how the similar idea works in Inkmacs(Emacs + Inkskape):

    - Emacs communicates with Inkskape using a DBus channel
    - Emacs sends dbus commands to update text objects in Inkskape. Inkskape
    immediately redraws its display when it receives the dbus commands

It would be possible to implement this, if LibreOffice has the same
sort of feature that Inkskape has.  But does it?

The next question is whether this would work fast enough in LibreOffice.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Fri, 22 Nov 2013 17:01:31 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: "Pascal J. Bourguignon" <pjb@informatimago.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Nov 22, 2013 at 4:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> I see no reason for these features to be connected to a style.  They
> > can easily be separate; keeping them separate will make it easier for
> > users to specify arbitrary combinations of them.
> >
> 
> Is that really the goal?

It is good enough a goal for me.  When we get there, we could start
talking about moving further.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Sat, 23 Nov 2013 01:06:28 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, ttn@gnu.org, eliz@gnu.org,
> 	yuri.v.khan@gmail.com, drew.adams@oracle.com
> 
> Styles facilitate maintenance of large documents.  That is why Texinfo
> is based on styles.

The Texinfo "styles" are actually typefaces, so they are "faces" in
Emacs parlance.

If you think I'm mistaken, please point out what is there in Texinfo
"styles" that we don't have in Emacs faces.

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Fri, 22 Nov 2013 23:53:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> >> Date: Fri, 22 Nov 2013 22:06:23 +0100
> >> Cc: emacs-devel@gnu.org
> >> 
> >> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.
> >
> > I cannot disagree more.  The main features of a document change very
> > little with paper size changes.
> 
> The structure of the document doesn't change (it's mostly unrelated to
> the presentation or layout).  But the layout of the document depends
> obviously on the target medium.

The layout depends on the medium in very minor ways, as long as we are
talking about the "usual" page sizes.  If what you have in mind is A3
paper or greeting cards, then the layout is indeed greatly affected,
but that's taking the issue to its extreme.

IOW, WYSIWYG is much more than just layout.

> So I persist, WYSIWIG = target medium representation.

And I insist that this is a myopic view of WYSIWYG.

> If you don't specify target medium representation, then you don't need
> WYSIWIG.

Entirely wrong.

You seem to think that visual appearance of the text itself is not an
important part of WYSIWYG.  Nothing can be farther from truth.

> What I'm asking, is what you do once the user specified a DTD containing
> elements such as: <xlorf>, <grlyb> and <ashur>?  How do you edit them?

I have no idea what these are or why would the user need to edit them.

> >> We'd have to disable removing truncate-lines mode
> >
> > What? why??
> 
> Because otherwise it's not WYSIWIG anymore: without truncate-lines, the
> lines are flowed and are not displayed anymore like they appear on the
> printed page.
> 
> 
> > And why are you talking about truncate-lines, when Emacs has word-wrap
> > for quite some time now?
> 
> I'm not sure what you mean by word-wrap exactly?

"C-h v word-wrap RET" will tell you.

> - open some text file.
> - M-x set-fill-column RET 40 RET  -- characters not 12.5 cm!
> - C-x h M-x set-justification-left RET
> - reduce the width of the frame or window to 30 characters wide.
> 
> Without truncate-line mode, each line is wrapped over, which is not
> WYSIWIG.
> 
> With M-x visual-line-mode RET it's the same thing.

So we need to add a feature whereby word-wrap happens at a fixed
column.  That should be easy.

> Type: M-x shell RET libreoffice RET 
> Click on: Text document
> Type: Hello world!
> Select the paragraph, 
> Click on the left margin knob above and move it 0.5 inch to the right.
> 
> Notice how the page is represented, as a white rectangle, how the
> margins are represented as L shapes offset from the four corners, how
> rules are graphical representations with graphical graduations,
> unrelated to the font sizes, notice how scrolling occurs pixel by pixel, graphically.
> 
> Select the word Hello, click on the style popup menu, select More…,
> scroll down and click on Vertical Numbering Symbols.
> 
> Notice  how the word Hello is rotated 90 degree counter clock wise.
> 
> All those representations could not occur no a normal textual terminal:
> they are in essence graphical.

Wrong.  Text can be laid out vertically as well (if we decide that's
an important feature to have in Emacs) without treating it as a
picture.

Re: Emacs as word processor

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
>> Date: Fri, 22 Nov 2013 23:53:40 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
>> >> Date: Fri, 22 Nov 2013 22:06:23 +0100
>> >> Cc: emacs-devel@gnu.org
>> >> 
>> >> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium.
>> >
>> > I cannot disagree more.  The main features of a document change very
>> > little with paper size changes.
>> 
>> The structure of the document doesn't change (it's mostly unrelated to
>> the presentation or layout).  But the layout of the document depends
>> obviously on the target medium.
>
> The layout depends on the medium in very minor ways, as long as we are
> talking about the "usual" page sizes.  If what you have in mind is A3
> paper or greeting cards, then the layout is indeed greatly affected,
> but that's taking the issue to its extreme.
>
> IOW, WYSIWYG is much more than just layout.
>
>> So I persist, WYSIWIG = target medium representation.
>
> And I insist that this is a myopic view of WYSIWYG.
>
>> If you don't specify target medium representation, then you don't need
>> WYSIWIG.
>
> Entirely wrong.
>
> You seem to think that visual appearance of the text itself is not an
> important part of WYSIWYG.  Nothing can be farther from truth.
>
>> What I'm asking, is what you do once the user specified a DTD containing
>> elements such as: <xlorf>, <grlyb> and <ashur>?  How do you edit them?
>
> I have no idea what these are or why would the user need to edit them.

Exactly my point.

The user specified <xlorf> as a structuring element for his kind of
documents, and you and emacs don't know what it means, and how it should
represented in a WYSIWIG way and how it should be manipulated from a
WYSIWIG view.

Nonetheless, a structure editor can edit them, adding <xlorf> nodes and
childrens, as specified by the user-supplied DTD.

That's why it seems obvious to me, once we've specified that we allowed
users to supply their own DTD, that we need to provide an explicit set
of commands to edit the structure of the document, in additionnal to the
usual text editing command set translated to usual structure editing.



>> >> We'd have to disable removing truncate-lines mode
>> >
>> > What? why??
>> 
>> Because otherwise it's not WYSIWIG anymore: without truncate-lines, the
>> lines are flowed and are not displayed anymore like they appear on the
>> printed page.
>> 
>> 
>> > And why are you talking about truncate-lines, when Emacs has word-wrap
>> > for quite some time now?
>> 
>> I'm not sure what you mean by word-wrap exactly?
>
> "C-h v word-wrap RET" will tell you.

"This variable has no effect if long lines are truncated (see"

And this is not a WYSIWIG feature, since it changes the layout depending
on the width of the emacs window, instead of depending on the width of
the page set up.



>> - open some text file.
>> - M-x set-fill-column RET 40 RET  -- characters not 12.5 cm!
>> - C-x h M-x set-justification-left RET
>> - reduce the width of the frame or window to 30 characters wide.
>> 
>> Without truncate-line mode, each line is wrapped over, which is not
>> WYSIWIG.
>> 
>> With M-x visual-line-mode RET it's the same thing.
>
> So we need to add a feature whereby word-wrap happens at a fixed
> column.  That should be easy.

Yes, if you think that word-wrap can be safely integrated into a word
processor.  But this is an implementation detail, why do you discuss it
now?




>> Type: M-x shell RET libreoffice RET 
>> Click on: Text document
>> Type: Hello world!
>> Select the paragraph, 
>> Click on the left margin knob above and move it 0.5 inch to the right.
>> 
>> Notice how the page is represented, as a white rectangle, how the
>> margins are represented as L shapes offset from the four corners, how
>> rules are graphical representations with graphical graduations,
>> unrelated to the font sizes, notice how scrolling occurs pixel by pixel, graphically.
>> 
>> Select the word Hello, click on the style popup menu, select More…,
>> scroll down and click on Vertical Numbering Symbols.
>> 
>> Notice  how the word Hello is rotated 90 degree counter clock wise.
>> 
>> All those representations could not occur no a normal textual terminal:
>> they are in essence graphical.
>
> Wrong.  Text can be laid out vertically as well (if we decide that's
> an important feature to have in Emacs) without treating it as a
> picture.

What about the drawing of the margins and other signs that don't occur
in character cells?


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

Re: Emacs as word processor

[John Yates]

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

On Sat, Nov 23, 2013 at 3:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> [Why private?]


Fumble fingered.

> > Fri, 22 Nov 2013 16:47:05 -0500, 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".  After that I want my tool have a
basic
> > sense of how each item ought to be formatted.  More importantly I want
it
> > to allow me to say, all elements of a particular type that I may have
> > created heretofore as well as any I may create in the future should be
> > formatted in some new manner.  I think of this as a declarative UI.
> >
> > If I understond your description correctly your model is one in which
(as
> > an inveterate emacs user :-) I would compose a command to say "find all
> > items matching the following pattern and change each's formatting
property
> > P from X to Y".  I think of that as an imperative UI.  My biggest
stumbling
> > block is that I do not understand how it allows me to express my
intentions
> > relative to content yet to be entered.
>
> We need to have both.  For the former, we have face customization,
> which does exactly what you describe.


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.

Perhaps you are saying that a viable design could extend faces with
additional attributes to support those concepts.  Hmm... I will give that
some thought.  At the very least, without introduction of any new
terminology, it will introduce yet another Humpty-Dumpty-esque "When
*I*use a word it means just what I choose it to mean - neither more
nor less"
for emacs new comers.

/john

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

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Sat, 23 Nov 2013 10:13:38 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > > Fri, 22 Nov 2013 16:47:05 -0500, 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".  After that I want my tool have a
> basic
> > > sense of how each item ought to be formatted.  More importantly I want
> it
> > > to allow me to say, all elements of a particular type that I may have
> > > created heretofore as well as any I may create in the future should be
> > > formatted in some new manner.  I think of this as a declarative UI.
> > >
> > > If I understond your description correctly your model is one in which
> (as
> > > an inveterate emacs user :-) I would compose a command to say "find all
> > > items matching the following pattern and change each's formatting
> property
> > > P from X to Y".  I think of that as an imperative UI.  My biggest
> stumbling
> > > block is that I do not understand how it allows me to express my
> intentions
> > > relative to content yet to be entered.
> >
> > We need to have both.  For the former, we have face customization,
> > which does exactly what you describe.
> 
> 
> 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.

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.

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.

Re: Emacs as word processor

[Lennart Borgman]

On Sat, Nov 23, 2013 at 4:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> 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.
>
> 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.
>
> 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.

Styles may depend on the structure to. Compare the spec for CSS.

Re: Emacs as word processor

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 23 Nov 2013 17:43:40 +0100
> Cc: John Yates <john@yates-sheets.org>, Emacs-Devel devel <emacs-devel@gnu.org>
> 
> > 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.
> 
> Styles may depend on the structure to. Compare the spec for CSS.

They may, but they don't need to.  I hope in Emacs they will not.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > Styles facilitate maintenance of large documents.  That is why Texinfo
    > is based on styles.

    The Texinfo "styles" are actually typefaces, so they are "faces" in
    Emacs parlance.

We are miscommunicating -- Texinfo has various constructs that specify
semantic markup, and some, such as @example, specify a typeface and other
parameters too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Lennart Borgman]

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

On Nov 23, 2013 6:52 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>

> >
> > Styles may depend on the structure to. Compare the spec for CSS.
>
> They may, but they don't need to.  I hope in Emacs they will not.

This is a must when you are designing web pages. So for compatibility
reasons I think it would be unlucky if Emacs did not support this.

However I do not know how the standard text document formats look in this
regard.

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

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Sat, 23 Nov 2013 16:12:27 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: john@yates-sheets.org, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, ttn@gnu.org, yuri.v.khan@gmail.com,
> 	drew.adams@oracle.com
> 
>     > Styles facilitate maintenance of large documents.  That is why Texinfo
>     > is based on styles.
> 
>     The Texinfo "styles" are actually typefaces, so they are "faces" in
>     Emacs parlance.
> 
> We are miscommunicating -- Texinfo has various constructs that specify
> semantic markup, and some, such as @example, specify a typeface and other
> parameters too.

Sorry, I don't see the difference.  I asked you to point out those
differences, i.e. tell what does Texinfo have that is conceptually
different from Emacs faces.  Unfortunately, you didn't.

Re: Emacs as word processor

[PJ Weisberg]

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

On Nov 23, 2013 5:44 AM, "Pascal J. Bourguignon" <pjb@informatimago.com>
wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> >> Date: Fri, 22 Nov 2013 23:53:40 +0100

> >> What I'm asking, is what you do once the user specified a DTD
containing
> >> elements such as: <xlorf>, <grlyb> and <ashur>?  How do you edit them?
> >
> > I have no idea what these are or why would the user need to edit them.
>
> Exactly my point.
>
> The user specified <xlorf> as a structuring element for his kind of
> documents, and you and emacs don't know what it means, and how it should
> represented in a WYSIWIG way and how it should be manipulated from a
> WYSIWIG view.
>
> Nonetheless, a structure editor can edit them, adding <xlorf> nodes and
> childrens, as specified by the user-supplied DTD.
>
> That's why it seems obvious to me, once we've specified that we allowed
> users to supply their own DTD, that we need to provide an explicit set
> of commands to edit the structure of the document, in additionnal to the
> usual text editing command set translated to usual structure editing.

In the context of a WYSIWYG word processor, why in god's name would the
user be specifying a DTD?

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

Emacs will never be a WYSIWYG-editor and should not try to (was: Emacs as word processor)

[Karl Voit]

A bit of a harsh statement in the subject. However, I will try to
explain it:

* Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Karl Voit <devnull@Karl-Voit.at>
>> Date: Fri, 22 Nov 2013 17:19:34 +0100
>> 
>> First of all, I claim that WYSIWYG has issues of its own. Please do
>> read [1]. I admit, that this text is very old but the key points are
>> still valid. Most people I know who know WYSIWYG *and* their
>> alternatives are not always very happy with using WYSIWYG. So why
>> follow this path which is know to be faulty?
>
> Because it is not necessarily faulty.

Fair enough. I tend to follow the critique mentioned in [1].

> That document presents a point of view.  Some will agree with it, some
> won't.  Emacs is not about forcing one particular POV on its users.

In my opinion, WYSIWYG is forcing one very particular POV on its
users.

> Quite the contrary, it's about giving them as much freedom as possible
> to do things their way.

I would be very pleased to see (low-tech) mock-ups of the GUI for
WYSIWYG without forcing POVs to users. This is the only way to get
onto a more concrete level of discussion about this topic. There are
many new techniques the GNU/Emacs community has to learn and
develop. 

I have got the feeling that this community has not had the need for
those methods before. This also inherits a somewhat dangerous issue
for all current GNU/Emacs users ("never change a running system").

>> Second, there are technical issues I do see. GNU/Emacs lacks a *lot*
>> in terms of GUI widget-set. Yes, I do believe that ribbons are
>> better[2] than menus for WYSIWYG tools but it's not only ribbons
>> that are missing. Users of WYSIWYG-tools are heavily using buttons
>> (mainly) and menu items (seldom) as studies show. This is not the
>> way GNU/Emacs is working. The button bar is very static. Not every
>> functionality is reachable via menu bar. Besides, menu bars got the
>> severe issue mentioned in [2][3] and we should do better than this.
>
> Yes, the job at hand is not small.  But does that mean we shouldn't
> take steps in that direction?  I hope not.

This is quite a philosophical response to my IMHO specific
statement. For my opinion: too philosophical compared to the very
concrete request of RMS.

>> Maybe I lack a huge amount of fantasy here but I don't think that
>> GNU/Emacs is going to be used by Joe Average who has no special IT
>> knowledge when there are alternative tools like Microsoft Word or
>> LibreOffice.
>
> We want to attract Joe Average's.  But what we want more is to give
> Emacs geeks a way to compose document in WYSIWYGy fashion.

It would be interesting to discuss, where this requests are coming
from. So far I could not get the impression that this is a
wide-spread wish.

>> Besides: if you want to attract non-geeks, prepare that they will
>> complain that there is no suitable support, that they do not want to
>> use mailing-lists or usenet (they prefer something which is called
>> Web Forum), and so forth.
>
> Let them complain, we've heard those complaints for many years and
> didn't care.

In case you "want to attract Joe Average's", don't you think this is
a very severe problem? This is somewhat OK to the current community
although I know a lot of very good people who do complain about
this. However, it is a big no-no for Joe Average's.

> But why shouldn't someone like RMS be able to compose a simple
> document without switching to LibreOffice or whatnot?  There's no
> excuse for that.

I simply cannot follow your arguments I am afraid. When I try to
follow your thoughts, I get to questions like: "why shouldn't
someone like RMS be able to draw mouse-driven vector graphics
without switching to CorelDraw/LibreOffice or whatnot?" What is your
thought about this?

In terms of a broad set of features/modules, Emacs is *the* number
one software in the world (I guess). However, it can not change its
underlying principles that much - IMHO. 

GNU/Emacs will never be a mouse-driven CAD tool. 

It will never be a 3D-first-person-shooter. 

It will never be a high-performance distributed data-base. 

It will never be a very large number of things.

Don't get me wrong: It's perfectly OK to me. GNU/Emacs has its
advantages but there are certain limitations so that GNU/Emacs can
not deliver a solution to *any* requirement out there.

What am I saying ... we do not even have multi-threading in
GNU/Emacs in the wild! This is probably the most annoying issue with
GNU/Emacs than anything else. Technically, I am no GNU/Emacs
insider. However, I do claim that you can not think of turning
GNU/Emacs in a WYSIWYG text processing machine without
multi-threading. We should cope with our technical debts and deliver
a robust platform instead of trying to get our minds over issues
that are way out of our part of the IT-world.

>> For the typical GNU/Emacs user, there are alternatives that result
>> in results they are happy to live with: AucTeX/LaTeX, Org-mode [5],
>> or even LibreOffice.
>
> For a devoted Emacs user, an Emacs solution will always blow any
> 3rd-party solution out of the water.  

This is a very valid goal. In reality it is not always the case.

> That's why there's Org mode, Gnus, Flymake, GUD, Flyspell, etc.,
> even though alternatives to each one of these exist, and some of
> them might even be better/more sophisticated/whatever than what
> Emacs has to offer in these areas.

I totally agree to this.

-- 
All in all, one of the most disturbing things today is the definitive
fact that the NSA, GCHQ, and many more government organizations are
massively terrorizing the freedom of us and the next generations.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Thien-Thi Nguyen]

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

() Karl Voit <devnull@Karl-Voit.at>
() Sun, 24 Nov 2013 12:11:53 +0100

   I do claim that you can not think of turning GNU/Emacs in a WYSIWYG
   text processing machine without multi-threading.

Emacs provides concurrency via child processes.  I don't think that
model is incompatible w/ adding features to support a "WYSIWYG text
processing machine".  So, no, it is not true that i cannot think so.

To support the argument in the subject line, you might say instead that
Emacs has traditionally leaned very far from exploiting the features
that allow persisting to disk of in-memory-user-visible representations
of text, to crown some file format as "native".

That is, no one has really pushed the limits (played *hard*) with
‘write-region-annotate-functions’ and faces, together, and furthermore
championed any particular conglomeration of conventions as a packaged
solution.

You might argue that because this has not happened (and due also to
other technical and social factors), it will never happen.  And you'd be
right, up until the moment Someone does indeed step up and just do it,
bugs in teeth be damned (i equate playing *hard* to riding a motorcycle
very fast, w/ nothing protecting the rider's ear-to-ear grin from the
onslaught of wind and destiny -- a memory i wouldn't mind reliving)...

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Eli Zaretskii]

> From: Karl Voit <devnull@Karl-Voit.at>
> Date: Sun, 24 Nov 2013 12:11:53 +0100
> 
> A bit of a harsh statement in the subject. However, I will try to
> explain it:

I'm not sure you should bother: Emacs development is not driven by
arguments of this kind, it is driven by people who have an itch to
scratch.

For that matter, all this argument about whether Emacs should or
should not provide a WYSIWYG mode is pointless: there's no marketing
department or any kind of "management" to convince, which will then
take care of executing the decisions.  This feature will or will not
be developed depending on whether or not someone will decide to do
that.  When (if) such a person emerges, no amount of argument will
convince her either way, and I cannot imagine that the changes she
submits, if the code is clean, will be rejected because someone thinks
Emacs "should not try".

> > That document presents a point of view.  Some will agree with it, some
> > won't.  Emacs is not about forcing one particular POV on its users.
> 
> In my opinion, WYSIWYG is forcing one very particular POV on its
> users.

Only on those who will choose to use the WYSIWYG mode.  Because this
is what was suggested: addition of such a mode.  Nobody said that it
will come _instead_ of all the other existing non-WYSIWYG modes.
People who like using LaTeX or Texinfo or troff or whatever, will
still be able to use them.

IOW, no one's freedom will be diminished by such an addition, and no
one will be forced to accept the WYSIWYG paradigm if they don't want
to.

> I have got the feeling that this community has not had the need for
> those methods before.

We have an explicit request on the table now, don't we?

> >> Second, there are technical issues I do see. GNU/Emacs lacks a *lot*
> >> in terms of GUI widget-set. Yes, I do believe that ribbons are
> >> better[2] than menus for WYSIWYG tools but it's not only ribbons
> >> that are missing. Users of WYSIWYG-tools are heavily using buttons
> >> (mainly) and menu items (seldom) as studies show. This is not the
> >> way GNU/Emacs is working. The button bar is very static. Not every
> >> functionality is reachable via menu bar. Besides, menu bars got the
> >> severe issue mentioned in [2][3] and we should do better than this.
> >
> > Yes, the job at hand is not small.  But does that mean we shouldn't
> > take steps in that direction?  I hope not.
> 
> This is quite a philosophical response to my IMHO specific
> statement.

Perhaps I didn't understand your statement, then.  It looked like a
list of missing features that will have to be implemented as part of
the job.  If you didn't mean to say by that list that the job is
large, then what did you mean to say?

> >> Maybe I lack a huge amount of fantasy here but I don't think that
> >> GNU/Emacs is going to be used by Joe Average who has no special IT
> >> knowledge when there are alternative tools like Microsoft Word or
> >> LibreOffice.
> >
> > We want to attract Joe Average's.  But what we want more is to give
> > Emacs geeks a way to compose document in WYSIWYGy fashion.
> 
> It would be interesting to discuss, where this requests are coming
> from. So far I could not get the impression that this is a
> wide-spread wish.

As I said, we _do_ want to attract.  But I have yet to see a single
Emacs features whose driver was _only_ to attract newcomers.  Emacs
development is not driven by such factors, they are at best
"additional considerations".

> >> Besides: if you want to attract non-geeks, prepare that they will
> >> complain that there is no suitable support, that they do not want to
> >> use mailing-lists or usenet (they prefer something which is called
> >> Web Forum), and so forth.
> >
> > Let them complain, we've heard those complaints for many years and
> > didn't care.
> 
> In case you "want to attract Joe Average's", don't you think this is
> a very severe problem?

No, I don't, because the main motivation of whoever will do this job
(if such a person will step forward) will most probably be that she
thinks the feature is "cool", not that it will or won't attract
someone.

> > But why shouldn't someone like RMS be able to compose a simple
> > document without switching to LibreOffice or whatnot?  There's no
> > excuse for that.
> 
> I simply cannot follow your arguments I am afraid. When I try to
> follow your thoughts, I get to questions like: "why shouldn't
> someone like RMS be able to draw mouse-driven vector graphics
> without switching to CorelDraw/LibreOffice or whatnot?" What is your
> thought about this?

Richard didn't ask about those other capabilities.  And the fact that
he didn't makes very good sense to me.

> I do claim that you can not think of turning GNU/Emacs in a WYSIWYG
> text processing machine without multi-threading.

I don't see the connection between these two.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:
>> I do claim that you can not think of turning GNU/Emacs in a WYSIWYG
>> text processing machine without multi-threading.
>
> I don't see the connection between these two.

Indeed, all the great old WYSIWIG word processors were written without
multithreading. Xerox 860 IPS (CP/M), LisaWrite (The Lisa operating
system featured cooperative (non-preemptive) multitasking […]), MacWrite
(MacOS), etc.


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

RE: Emacs as word processor

[Drew Adams]

> In the context of a WYSIWYG word processor, why in god's name
> would the user be specifying a DTD?

(Why would anyone want to do anything in a god's name, unless
s?he were running for some kind of high priest?)

---

FWIW, and without wanting to dig further into this discussion:

Doc tools used by doc professionals include some that are both
WYSIWYG and structure-based.  And these are typically considered
the best doc tools available currently.  Examples: Framemaker,
Arbortext, and XMetal, with Framemaker being somewhat better
than others in the WYSIWYG department. 

Such tools are typically XML-based nowadays.  They are in fact
XML editors, and generally have excellent round-tripping.

Structure is enforced by XML validation against a DTD or an
XML-Schema schema.  And there is excellent support for structure
editing, both lax (you can create invalid structure and clean it
up later) and strict (you can perform only actions that do not
invalidate the structure, even temporarily).

And yet the display and interaction can be WYSIWYG.  There are
typically multiple views: from WYSIWYG (sometimes multiple such,
depending on what is to be shown/emphasized) to XML markup using
plain-text, with combinations: WYSIWYG but showing XML elements
and attributes.

Typically, such views are not just push-a-button-to-update-result.
Each view is editable, and the effect is reflected immediately in
any and all of them.  Typically, a user edits in both a structure
window and a WYSIWYG window, using whichever is handier for the
editing task at hand.

All this is to say that a structural - and even a textual,
markup, plain-text representation of a document - is NOT
incompatible with a WYSIWYG representation, and the two are not
incompatible wrt interactive editing.

That said, these are mature products with lots of hours of
development behind them.  Emacs could of course try to progress
in such a direction, adding such to its wishlist.  But in that
case I'd suggest biting off small pieces to attack at a time,
as the full realization of something like this would be a lot
of work.

Emacs could choose to build such an effort on top of XML or
JSON (?) or TeX or Org or whatever.  Or just Lisp sexps (lists).
For purposes of exchange and pluggability and tools (e.g. XQuery,
XSLT), XML could be a natural choice.  But then again, those
things are ultimately about I/O and persistence - they impose
nothing about the implementation.

To be clear, I am not proposing that Emacs develop such
capabilities, nor am I opposing that.  Just providing some info.

(BTW, my advice is to forget about MS Word, which much of this
discussion has turned around.  MS Office products are now based
on XML.  But as others have pointed out, it is not the best XML.
And interactively the products are far from a guide wrt what
Emacs could/should do.  The best that can be said for them is
that their use of XML can at least now let other XML-based
products exchange data with them and manipulate their documents,
modulo hiccups.  And they will no doubt get better with time.)

Re: Emacs will never be a WYSIWYG-editor and should not try to (was: Emacs as word processor)

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    In my opinion, WYSIWYG is forcing one very particular POV on its
    users.

Emacs won't force WYSIWYG on any users.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > We are miscommunicating -- Texinfo has various constructs that specify
    > semantic markup, and some, such as @example, specify a typeface and other
    > parameters too.

    Sorry, I don't see the difference.  I asked you to point out those
    differences, i.e. tell what does Texinfo have that is conceptually
    different from Emacs faces.  Unfortunately, you didn't.

I thought that giving @example as an example was a sufficient answer.

Emacs faces specify only the appearance of individual characters.
Styles in Texinfo can specify indentation and justification options, and
vertical space before or after, as well as the choice of font.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Sun, 24 Nov 2013 13:37:13 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: yuri.v.khan@gmail.com, monnier@iro.umontreal.ca, ttn@gnu.org,
> 	emacs-devel@gnu.org, drew.adams@oracle.com,
> 	john@yates-sheets.org
> 
> Emacs faces specify only the appearance of individual characters.
> Styles in Texinfo can specify indentation and justification options, and
> vertical space before or after, as well as the choice of font.

Thanks.

Indeed, faces cannot specify this, but I see no reason why they
couldn't be extended to do that as well.

Re: Emacs as word processor

[Lennart Borgman]

On Sun, Nov 24, 2013 at 9:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> Emacs faces specify only the appearance of individual characters.
>> Styles in Texinfo can specify indentation and justification options, and
>> vertical space before or after, as well as the choice of font.
>
> Thanks.
>
> Indeed, faces cannot specify this, but I see no reason why they
> couldn't be extended to do that as well.

They could. But then they would be styles. ;-)

Re: Emacs as word processor

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Sun, 24 Nov 2013 22:21:37 +0200

   Indeed, faces cannot specify this, but I see no reason why they
   couldn't be extended to do that as well.

If "faces" (the concept) were to include these extra-character features,
then their composition would be greatly complicated.  Too, application
(i'm imagining the case of yanking text w/ a ‘face’ text-property that
controls, say, pre-paragraph line-spacing into the middle of other text,
which has conflicting specs, or a context where "paragraph" does not
even have meaning).

It seems more natural to leave "faces" (the concept) as a "leaf"
feature, IMHO.  For example, if the "style" i want is to have top-level
headings of a nested list in Courier, sub-headings in Italic, and all
body text in Times, then i think it would be more natural to specify
that directly to the style machinery and let it wrangle the faces for
me, then to specify the faces "Courier, only in top-level list
headings" and so on, as unique entities, to be applied in a separate
step to the particular text i'm composing.

Not to mention when i promote a sub-heading to top-level, who (which
part of Emacs) is responsible for recognizing the text cut via ‘C-w’ and
yanked via ‘C-y’ is now "out of style"?  And what to do about it?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs as word processor

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnuvola.org>
> Date: Sun, 24 Nov 2013 22:06:02 +0100
> 
> 
> [1:text/plain Hide]
> 
> () Eli Zaretskii <eliz@gnu.org>
> () Sun, 24 Nov 2013 22:21:37 +0200
> 
>    Indeed, faces cannot specify this, but I see no reason why they
>    couldn't be extended to do that as well.
> 
> If "faces" (the concept) were to include these extra-character features,
> then their composition would be greatly complicated.

That ship sailed a long time ago: we already have 'line-spacing' text
property.  Indentation and justification are no different.

> It seems more natural to leave "faces" (the concept) as a "leaf"
> feature, IMHO.  For example, if the "style" i want is to have top-level
> headings of a nested list in Courier, sub-headings in Italic, and all
> body text in Times, then i think it would be more natural to specify
> that directly to the style machinery and let it wrangle the faces for
> me, then to specify the faces "Courier, only in top-level list
> headings" and so on, as unique entities, to be applied in a separate
> step to the particular text i'm composing.

This is the source of all evil in Office.  The result is a terrible
mess where the user ends up having no control on what is going on in
her document (except for very short documents).  No, thanks.

Re: Emacs as word processor

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Thien-Thi Nguyen <ttn@gnuvola.org>

Listen to Master Thi.  He is wise and appreciates the Zen of
Motorcycle Maintenance, and well groks the higher-order Quality.

 > > If "faces" (the concept) were to include these extra-character
 > > features, then their composition would be greatly complicated.
 > 
 > That ship sailed a long time ago: we already have 'line-spacing' text
 > property.

Which demonstrates why it is unfortunate that text properties are the
primary interface in Emacs.  They're too easy to use for things that
conceptually attach to text units larger than single characters, but
they have no clue about such units -- it's entirely up to the user to
DTRT.

 > Indentation and justification are no different.

Ah, but they *are* different, at least potentially.  Default line
spacing can be implemented by changing the depth of the character box,
uniformly without respect to the identity of the character, for all
characters covered by that face.  (I suspect that's how this works in
Emacs; XEmacs doesn't have the feature AFAIK.)  Indentation and
justification are much more complex: they depend on the semantics of
the text, possibly including the particular characters.  For example,
in Japanese typography, punctuation and certain ligatures are allowed
to protrude on the right margin in fully justified text.  And line
spacing *also* should have a variant that applies to larger units of
text.  (Note that TeX implements both, and Knuth points out in the
TeXbook that use of extended depth to implement "poor man's
double-spacing" is ugly and hardly readable.  But it's possible in
principle.)

 > [Structured styles] is the source of all evil in Office.  The
 > result is a terrible mess where the user ends up having no control
 > on what is going on in her document (except for very short
 > documents).  No, thanks.

No, that's not the problem.  The problem is that *Office separates
editing of styles from editing of the document, making style editing
the province of experts.  And *Office does a rather sucky job on
things like indentation and mark formatting of bullet lists and
enumerations (at least in Japanese documents).

But it doesn't have to be that way.  A simple implementation of Drew's
"structured document WYSIWYG" would be as with many calendar programs,
which ask if a repeating appointment should be changed throughout, or
only on this date.  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

If you check the "Review" button, it would pop up a buffer listing all
exceptional headers at affected levels (ie, those with different font
families from the global style), with check boxes to revert them to
the global style, with execute options [Revert all] [Revert selected]
[Revert none].  (Not [Cancel] for the last, because that could be
construed to apply to the whole heading edit operation.)

You don't have to like the details of the workflow I just outlined,
although I suspect that applied to header, footer, and section
headings it would be quite acceptable.  In the body we would probably
want a separate command (or perhaps use universal prefix?) to access
styles rather than local formatting.  (I'm not actually sure of that.)

This doesn't address the issues of creating styles (ie, defining
"section heading" as a unit for style editing, and the associated UI
elements), and the balance between flexible control at the level of
individual words and providing structured styles is going to require a
lot of attention to detail.  But I think such an approach provides
both simplicity and sufficient control for "simple WYSIWYG document
processing".

Re: Emacs as word processor

[Yuri Khan]

On Mon, Nov 25, 2013 at 4:06 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> If "faces" (the concept) were to include these extra-character features,
> then their composition would be greatly complicated.  Too, application
> (i'm imagining the case of yanking text w/ a ‘face’ text-property that
> controls, say, pre-paragraph line-spacing into the middle of other text,
> which has conflicting specs, or a context where "paragraph" does not
> even have meaning).

In *Office, styles are subdivided into “character styles” and
“paragraph styles” (and, more recently, “list styles” and “table
styles”). Text that is cut or copied out of the middle of a paragraph
does not carry paragraph styles with it. Thus, pasted into a paragraph
with different spacing, it assumes the spacing of the target paragraph
(as spacing is a paragraph style feature).

On the other hand, a whole paragraph, when cut, carries all its
paragraph styles, and all its content carries its character styles.

Additionally, if text is not explicitly formatted with character
styles or character-level direct formatting, it behaves as plain text
when cut, assuming the character styles of the paste target.

Also, text can be explicitly marked as e.g. italic but otherwise have
no font-related formatting. Thus, it will inherit other properties
from the context: if pasted into a body paragraph whose base font is
black normal straight Times New Roman 10pt, it becomes black normal
italic Times New Roman 10pt; but pasted into a heading whose base font
is blue bold straight Arial 16pt, becomes blue bold italic Arial 16pt.

This is in fact very similar to Emacs’ face composition mechanism
where many faces may be applied simultaneously, with some properties
of some faces being undefined.


Now, problems arise when characters *do* have explicit character-level
formatting that is visually indistinguishable from the base paragraph
font. Such text *will* carry the font with it when copied and pasted,
giving the user the feeling of unpredictability and not being in
control.

Another frequent problem with WYSIWYG formatted text editors is
pasting text copied from a different application, such as a web
browser or a different word processor. It is then common to retain as
much formatting as is available in the source document, which is
rarely what the user expects.

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Thien-Thi Nguyen <ttn@gnuvola.org>,
>     emacs-devel@gnu.org
> Date: Mon, 25 Nov 2013 11:15:08 +0900
> 
>  > Indentation and justification are no different.
> 
> Ah, but they *are* different, at least potentially.  Default line
> spacing can be implemented by changing the depth of the character box,
> uniformly without respect to the identity of the character, for all
> characters covered by that face.  (I suspect that's how this works in
> Emacs; XEmacs doesn't have the feature AFAIK.)

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.

> Indentation and justification are much more complex: they depend on
> the semantics of the text, possibly including the particular
> characters.  For example, in Japanese typography, punctuation and
> certain ligatures are allowed to protrude on the right margin in
> fully justified text.  And line spacing *also* should have a variant
> that applies to larger units of text.

Sorry, I don't see the difficulties.  Emacs already examines the
properties of each character when it displays text, and its word-wrap
and truncation/continuation decisions already take issues similar to
the above into consideration.

>  > [Structured styles] is the source of all evil in Office.  The
>  > result is a terrible mess where the user ends up having no control
>  > on what is going on in her document (except for very short
>  > documents).  No, thanks.
> 
> No, that's not the problem.  The problem is that *Office separates
> editing of styles from editing of the document, making style editing
> the province of experts.  And *Office does a rather sucky job on
> things like indentation and mark formatting of bullet lists and
> enumerations (at least in Japanese documents).

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.

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

Re: Emacs as word processor

[Stephen J. Turnbull]

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.

Another way to look at this is "what happens if *two* intervals
completely contained in the same line have *different* line-separation
properties?"  In TeX this is well-defined: use the largest descent of
any character on the line.  I suppose in Emacs it is the same.  But
this doesn't look very good in many cases.

 > Sorry, I don't see the difficulties.  Emacs already examines the
 > properties of each character when it displays text, and its word-wrap
 > and truncation/continuation decisions already take issues similar to
 > the above into consideration.

Of course it does.  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.

 > >  > [Structured styles] is the source of all evil in Office.  The
 > >  > result is a terrible mess where the user ends up having no control
 > >  > on what is going on in her document (except for very short
 > >  > documents).  No, thanks.
 > > 
 > > No, that's not the problem.  The problem is that *Office separates
 > > editing of styles from editing of the document, making style editing
 > > the province of experts.  And *Office does a rather sucky job on
 > > things like indentation and mark formatting of bullet lists and
 > > enumerations (at least in Japanese documents).
 > 
 > 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.  The changes often do affect the containing block
(paragraph, table, etc), but not the whole document.  I usually wish
that would happen, but it doesn't ... unless you edit a style.

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

But if I edit the *style* of some particular object that occurs only
occasionally in the presentation (such as a section heading), that is
going to change the look and feel of the whole document *whether I
apply that change to all similar objects or not*.  Specifically, if I
*don't* apply it to the similar objects, the document's overall style
becomes less uniform.  That may be what you intend, and it may not be.

If you're a poet (say, e.e.cummings), I agree, lack of (conventional)
uniformity is High Art.  But in most organizations, lack of uniformity
in documents is not greatly appreciated, not by the bosses and enven
less so by the customers.  Applying a changed style to all objects
using that style should be the default.  It wouldn't be hard to define
the API and UI so that you could turn it off if you desire, and that
probably should be done.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

      This feature will or will not
    be developed depending on whether or not someone will decide to do
    that.

I hope that my suggestion will get people interested in doing this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Eli Zaretskii]

> Cc: ttn@gnuvola.org,
>     emacs-devel@gnu.org
> From: stephen@xemacs.org (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.

Re: Emacs as word processor

[John Yates]

[-- 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 --]

Re: Emacs as word processor

[Lennart Borgman]

On Mon, Nov 25, 2013 at 6:51 PM, John Yates <john@yates-sheets.org> wrote:
>
> text calling them simply "faces" would surely be confusing.  We might call
> them "paragraph faces" or "structural faces" or "structural styles" or
> whatever...

Please just call them *-styles. That is what everyone else calls them. ;-)

And stick to the structures defined by HTML/CSS and Document
Foundation (Libre Office etc). New visualizations of the structures
are of course helpful for Emacs users.

Re: Emacs as word processor

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 25 Nov 2013 19:02:21 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, Nov 25, 2013 at 6:51 PM, John Yates <john@yates-sheets.org> wrote:
> >
> > text calling them simply "faces" would surely be confusing.  We might call
> > them "paragraph faces" or "structural faces" or "structural styles" or
> > whatever...
> 
> Please just call them *-styles.

Yes, and please call Emacs "Word" or "LibreOffice".

Re: Emacs as word processor

[Jambunathan K]

I am surprised that the discussion has more or less focussed on the
"character styles" part but has more or less ignored lists and tables.

John Yates <john@yates-sheets.org> writes:

> structural elements

Please take a look at

    http://orgmode.org/worg/dev/org-syntax.html
    http://orgmode.org/worg/dev/org-export-reference.html

The parser is in org-element.el.  The "affiliated keywords" are a
primitive form of specifying up some attributes - HTML or LaTeX specific
- of an element (say a paragraph).

There are plenty of examples of real life Org files in
    
   http://orgmode.org/w/?p=worg.git;a=tree

It is instructive to run

   M-x pp-eval-expression (org-element-parse-buffer)

in an Org file to see how the text file is translated in to Lisp.

----------------------------------------------------------------

Ideally if a wordprocessing-mode buffer is DE-RICHIFIED one should could
end up with an Org-mode buffer.  This would be a good goal to have.

i.e., For all practical purposes, the new mode should be a "RICHIFIED"
Org-mode buffer.  The richness would come from attaching
display/rendering properties like margin, padding etc to an Org-mode
buffer.

Before finalizing the internal representation of document please pay
close attention to Org's parser infrastructure and representation and
see how it could be AUGMENTED to provide richification.

----------------------------------------------------------------

Real-life documents are a COLLECTION of files.  So, the default format
will be a zip file the usual bells and whistles like manifest etc.

----------------------------------------------------------------

Table editing:

We would need the ability to edit multiple paragraphs within a table
cell.  This means M-q working as expected, table rows expanding down
below if required etc. all with good responsiveness from display.

----------------------------------------------------------------

Markup format:

As for markup format, I see that there is not much demand for docbook.
(The org-docbook.el exporter which was part of earlier releases has been
removed and not even a single soul - this includes the original author -
has cried foul.)

The primary contenders are LaTeX, HTML (may be Epub) or OpenDocument
format.

There could be a native format which can be "read" in as a sexp.  (Think
stringified buffer with text properties)

----------------------------------------------------------------

Scripting?

Typically a document has a scripting language - HTML has Javascript,
OpenOffice files have the Basic Macros.  Emacs lisp can be considered as
a "scripting language" for Emacs generated files.   I am not sure what
this comment amounts to, just recording it ...

----------------------------------------------------------------

In-Document Change tracking

There is a lot of demand for in-document markup that highlights changes.
This permits colloboration.  Even if colloboration between two users
editing the SAME document but with different TOOLS (say Emacs,
LibreOffice, MS Word) could be an ideal to aspire to, ability to do
change tracking between two Emacs users should still be permissible.

This IMO is not a desirable but an essential feature of the proposed
wordprocessing mode.

Re: Emacs as word processor

[Lennart Borgman]

On Mon, Nov 25, 2013 at 7:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 25 Nov 2013 19:02:21 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
>>
>> On Mon, Nov 25, 2013 at 6:51 PM, John Yates <john@yates-sheets.org> wrote:
>> >
>> > text calling them simply "faces" would surely be confusing.  We might call
>> > them "paragraph faces" or "structural faces" or "structural styles" or
>> > whatever...
>>
>> Please just call them *-styles.
>
> Yes, and please call Emacs "Word" or "LibreOffice".

When everyone else does that I will of course follow suite.

Re: Emacs as word processor

[Allen S. Rout]

On 11/23/2013 03:22 AM, Eli Zaretskii wrote:

> 
> The layout depends on the medium in very minor ways, as long as we are
> talking about the "usual" page sizes.  If what you have in mind is A3
> paper or greeting cards, then the layout is indeed greatly affected,
> but that's taking the issue to its extreme.
> 
> IOW, WYSIWYG is much more than just layout.
> 

I think this is a critical point, and I think that Eli is deeply
incorrect here.  WYSIWYG is -only- about layout, for the overwhelming
majority of its users.  I think that's why many of us aren't so fond of it.

There is no distinction between letter and greeting cards which is not
present in the comparison between letter and
letter-with-really-small-margins. Line breaks, kerning, justification
details... all of this is relevant if we actually want WYSIWYG.

Maybe we could aim for a different target?   What You See Is Pretty Close?

- Allen S. Rout

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Allen S. Rout" <asr@ufl.edu>
> Date: Mon, 25 Nov 2013 15:42:52 -0500
> 
> On 11/23/2013 03:22 AM, Eli Zaretskii wrote:
> 
> > 
> > The layout depends on the medium in very minor ways, as long as we are
> > talking about the "usual" page sizes.  If what you have in mind is A3
> > paper or greeting cards, then the layout is indeed greatly affected,
> > but that's taking the issue to its extreme.
> > 
> > IOW, WYSIWYG is much more than just layout.
> > 
> 
> I think this is a critical point, and I think that Eli is deeply
> incorrect here.  WYSIWYG is -only- about layout, for the overwhelming
> majority of its users.  I think that's why many of us aren't so fond of it.

Then I guess there are several conflicting ways of interpreting
WYSIWYG.  It's not that I just landed from Mars, or never saw a
WYSIWYG word processor before.

We will just have to agree to disagree.

Of course, the real question is what did Richard have in mind.

> There is no distinction between letter and greeting cards which is not
> present in the comparison between letter and
> letter-with-really-small-margins. Line breaks, kerning, justification
> details... all of this is relevant if we actually want WYSIWYG.

I won't object if Emacs supported writing papers in a WYSIWYGy
fashion, but didn't support greeting cards.

Re: Emacs as word processor

[Allen S. Rout]

On 11/25/2013 04:15 PM, Eli Zaretskii wrote:

> 
> We will just have to agree to disagree.
> 

Indeed.. :)

>
> Of course, the real question is what did Richard have in mind.
> 

and internalizing, in our own minds, that rms-WYSIWYG is probably
distinct from whatever else we might have observed running around with
that label.

- Allen S. Rout

Re: Emacs as word processor

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Allen S. Rout" <asr@ufl.edu>
>> Date: Mon, 25 Nov 2013 15:42:52 -0500
>> 
>> On 11/23/2013 03:22 AM, Eli Zaretskii wrote:
>> 
>> > 
>> > The layout depends on the medium in very minor ways, as long as we are
>> > talking about the "usual" page sizes.  If what you have in mind is A3
>> > paper or greeting cards, then the layout is indeed greatly affected,
>> > but that's taking the issue to its extreme.
>> > 
>> > IOW, WYSIWYG is much more than just layout.
>> > 
>> 
>> I think this is a critical point, and I think that Eli is deeply
>> incorrect here.  WYSIWYG is -only- about layout, for the overwhelming
>> majority of its users.  I think that's why many of us aren't so fond of it.
>
> Then I guess there are several conflicting ways of interpreting
> WYSIWYG.  It's not that I just landed from Mars, or never saw a
> WYSIWYG word processor before.
>
> We will just have to agree to disagree.
>
> Of course, the real question is what did Richard have in mind.
>
>> There is no distinction between letter and greeting cards which is not
>> present in the comparison between letter and
>> letter-with-really-small-margins. Line breaks, kerning, justification
>> details... all of this is relevant if we actually want WYSIWYG.
>
> I won't object if Emacs supported writing papers in a WYSIWYGy
> fashion, but didn't support greeting cards.

Why not?  Don't tell us you never receive those irritating greeting
cards from non-programmers.  Why shouldn't we be able to retaliate in
kind? 
-- 
__Pascal Bourguignon__
http://www.informatimago.com/

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    Now, problems arise when characters *do* have explicit character-level
    formatting that is visually indistinguishable from the base paragraph
    font. Such text *will* carry the font with it when copied and pasted,
    giving the user the feeling of unpredictability and not being in
    control.

If it is no worse in Emacs than it is in the other word processors
people are used to, we can live with it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Stephen J. Turnbull]

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

Re: Emacs as word processor

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ttn@gnuvola.org,
>     emacs-devel@gnu.org
> Date: Tue, 26 Nov 2013 11:35:12 +0900
> 
> 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.

We have yank-excluded-properties for that.

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

I assume we want the former.  At least that's what I had in mind.  The
latter is not a practical goal, I agree.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> I hope that my suggestion will get people interested in doing this.

I hope that my suggestion to test Org will somehow not be burried
with this huge thread :)

Looking forward to reading your feedback, independently of the
WYSIWYG discussion !

-- 
 Bastien

Re: Emacs as word processor

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > 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.
 > 
 > We have yank-excluded-properties for that.

Yeah, but it currently contains only one presentation property
(invisible) by default.  Things like a particular font or color used
for emphasis are likely to be incorrect in a different document, and
occasionally even when moved to a different context in the *same*
document.  Indentation, enumeration, marginal annotations similarly.

My point is that dealing with these cases is going to require
attention to a lot of fine detail, and the text-property API is much
coarser than that.  Of course you could proliferate properties
("non-copyable-face"), and add code to deal with them.  But having an
additional level of indirection (which is being called "style" in this
thread) is going to be very useful in organizing these things.

Re: Emacs as word processor

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> has more or less ignored lists and tables.

Images, as well.

Re: Emacs as word processor

[Tom]

Richard Stallman <rms <at> gnu.org> writes:

> 
> I don't know how to use Org mode, and don't know what it does (it
> seems to do so many things),

Wouldn't it be a good investment of your time to familiarize yourself with
it a bit?

It's a major piece of the emacs ecosystem, so it's useful to know what
it can do in order to make informed decisions about the future direction
of emacs.

And you may even find it useful in your own workflow if you get to know
it better.
 

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Andreas Röhler]

Am 26.11.2013 08:01, schrieb Bastien:
> Richard Stallman <rms@gnu.org> writes:
>
>> I hope that my suggestion will get people interested in doing this.
>
> I hope that my suggestion to test Org will somehow not be burried
> with this huge thread :)
>
> Looking forward to reading your feedback, independently of the
> WYSIWYG discussion !
>

Hi Bastien,

there is a thing WRT Emacs and org-mode seeing not mentioned so far:

org-mode developed a lot of useful things, thanks all for that.

However, seen from main stuff, it's somehow written around the corner,
parallel or not fitting into the other. The use of hard-coded stars for example is hardly the state of art in a general-purpose editor.

AFAIS org-mode is composed of at least three major areas:

- the org-mode strictly spoken, with it's date-time and planning stuff.
- literal programming with it's exporters, which is probably of most interest here
- basic fixes and enhancements of common Emacs features, tables, footnotes etc.

Would wish the both last items seeing back-ported into major Emacs without need of org-mode.

Cheers,

Andreas

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Bastien]

Hi Andreas,

Andreas Röhler <andreas.roehler@online.de> writes:

> AFAIS org-mode is composed of at least three major areas:
>
> - the org-mode strictly spoken, with it's date-time and planning stuff.
> - literal programming with it's exporters, which is probably of most interest here
> - basic fixes and enhancements of common Emacs features, tables, footnotes etc.
>
> Would wish the both last items seeing back-ported into major Emacs
> without need of org-mode.

For the second item, you can't have it without Org.

For the third one, there is already

  M-x orgtbl-mode RET
  M-x orgstruct-mode RET

Do you have a concrete suggestion for another minor-mode
that could spin off from Org?

-- 
 Bastien

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Andreas Röhler]

Am 26.11.2013 10:15, schrieb Bastien:
> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> AFAIS org-mode is composed of at least three major areas:
>>
>> - the org-mode strictly spoken, with it's date-time and planning stuff.
>> - literal programming with it's exporters, which is probably of most interest here
>> - basic fixes and enhancements of common Emacs features, tables, footnotes etc.
>>
>> Would wish the both last items seeing back-ported into major Emacs
>> without need of org-mode.
>
> For the second item, you can't have it without Org.

Why not? We are speaking about org-babel, which is a great idea but not related to
the ToDo, time- and date stuff, were org-mode started and what its name indicates.


>
> For the third one, there is already
>
>    M-x orgtbl-mode RET
>    M-x orgstruct-mode RET
>

Well, so my suggestion is to transform it into just table-mode, struct-mode etc.

> Do you have a concrete suggestion for another minor-mode
> that could spin off from Org?
>

footnote? There will be a lot more with some probability...

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Bastien]

Andreas Röhler <andreas.roehler@online.de> writes:

>> For the second item, you can't have it without Org.
>
> Why not? We are speaking about org-babel, which is a great idea but not related to
> the ToDo, time- and date stuff, were org-mode started and what its name indicates.

Because it's technically impossible.

>> For the third one, there is already
>>
>>    M-x orgtbl-mode RET
>>    M-x orgstruct-mode RET
>
> Well, so my suggestion is to transform it into just table-mode,
> struct-mode etc.

The name of the minor-modes reminds people those modes use Org syntax,
other names would be too generic IMHO.

>> Do you have a concrete suggestion for another minor-mode
>> that could spin off from Org?
>
> footnote? There will be a lot more with some probability...

Org footnotes can be used through orgstruct-mode, I think that's
enough.

I grok your general idea, but I'm afraid it's too general for me
now.

-- 
 Bastien

RE: Emacs as word processor

[Drew Adams]

(I still intend to stay out of this thread, for the most part...)

FWIW, wrt the discussion about handling properties, e.g., yanking
or not etc.:

Two little commands from library `highlight.el' let you copy/paste
text properties from/to the active region: `hlt-copy-props' and
`hlt-yank-props'.  And command `hlt-mouse-copy-props' copies them
from the mouse pointer position (i.e., point & copy).

If you use the mouse to select the region (not necessary, just
an example) then this is like using the little "paintbrush" tool
in some applications (e.g. MS Office apps).

Except that you can keep pasting the same properties here and
there; no need to copy again.  And undo works normally, removing
the pasted properties.  And you can control which text properties
get copied, both by option and on the fly.

http://www.emacswiki.org/HighlightLibrary#toc6

Re: Emacs as word processor

[John Yates]

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

On Tue, Nov 26, 2013 at 2:05 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

But having an
> additional level of indirection (which is being called "style" in this
> thread) is going to be very useful in organizing these things.
>

Another form of indirection would be to allow abstract mark-up.  In the
context of today's face model it would be nice to be able to mark a span
with an abstract property or face (e.g. emphasis) without binding it
immediately to concrete face attributes.  Presumably there would be a
defined search through a document's structure and its associated styles for
mapping such abstract markup to concrete face attributes.

My hope would be that pasting into a separate document text with abstract
markup might be a bit less fraught than the horrors alluded to previously.

/john

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

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    I hope that my suggestion to test Org will somehow not be burried
    with this huge thread :)

I tried it a little bit and it ran into an undefined function.
Then I rebuilt the autoloads.  I will try it again when I have time.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    Wouldn't it be a good investment of your time to familiarize yourself with
    it a bit?

I am not sure.  It seems to require a LOT of time.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    - basic fixes and enhancements of common Emacs features, tables, footnotes etc.

    Would wish the both last items seeing back-ported into major Emacs without need of org-mode.

In principle, I agree.  But there seems to be a disagreement about
whether these are fixes or enhancements of common Emacs features.
Bastien said,

    For the second item, you can't have it without Org.

Andreas, could you list a few of these points, so we can see
whether they make sense outside Org mode?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Lennart Borgman]

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

On Nov 26, 2013 4:34 PM, "John Yates" <john@yates-sheets.org> wrote:
>
> On Tue, Nov 26, 2013 at 2:05 AM, Stephen J. Turnbull <stephen@xemacs.org>
wrote:
>
>> But having an
>> additional level of indirection (which is being called "style" in this
>> thread) is going to be very useful in organizing these things.
>
>
> Another form of indirection would be to allow abstract mark-up.  In the
context of today's face model it would be nice to be able to mark a span
with an abstract property or face (e.g. emphasis) without binding it
immediately to concrete face attributes.

Is no that what is done normally in XML documents? (Html/css, office, etc)?
I think this belongs to the structure.

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

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Andreas Röhler]

Am 26.11.2013 16:58, schrieb Richard Stallman:
>          [ To any NSA and FBI agents reading my email: please consider
>          [ whether defending the US Constitution against all enemies,
>          [ foreign or domestic, requires you to follow Snowden's example.
>
>      - basic fixes and enhancements of common Emacs features, tables, footnotes etc.
>
>      Would wish the both last items seeing back-ported into major Emacs without need of org-mode.
>
> In principle, I agree.  But there seems to be a disagreement about
> whether these are fixes or enhancements of common Emacs features.
> Bastien said,
>
>      For the second item, you can't have it without Org.
>
> Andreas, could you list a few of these points, so we can see
> whether they make sense outside Org mode?
>

I'll cc that to Carsten, who will know best where to start.

If you take a look into the org-directory, you'll see several files, whose name indicate the purpose beside from org-mode in its strict sense.

Probably it would be great to have the exporter(s?) --which may output into HTML, PDF or ODF-- available in all text-modes.
IIRC also import from ODF is written already, so it's not far away from playing libre-office :)

 From my perspective porting org-footnote.el would pay.
The footnote.el in mail-directory isn't able to store resp. to read in existing footnotes.
All textmodes could offer footnotes.

Well, the code providing literal programming is quite an item by themselves, no trivial thing.
Just being surprised it should not work outside org-mode too ;)

Re: Emacs as word processor

[John Yates]

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

On Tue, Nov 26, 2013 at 11:57 AM, Lennart Borgman <lennart.borgman@gmail.com
> wrote:

> Is not that what is done normally in XML documents? (Html/css, office,
> etc)?
>
Yes, pretty much.  I did not mean in anyway to give an impression that this
represented creativity on my part.  I was simply trying to suggest a way to
achieve the level of abstraction I have experienced in other mark-up
systems.

/john

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

Re: Emacs as word processor / Text Properties

[Pascal J. Bourguignon]

To me, text properties, and faces as text properties, have always felt
like a kludge.


At best, they may be used to transport information from the modes to the
display engine, like the faces, but otherwise (apart for quick & dirty
jobs), it seems to me that in general modes sh/would have more pertinent
lisp data structures, and use them to set the face in the buffer to
represent that data structure.

I know that emacs puts a lot of importance on the buffer data structure
(a sequence of characters with attributes), which is all right for a
text editor, but when you write _applications_ in emacs, it is much too
limiting.  And a word processor is an application, with more complex
data structures than a sequence of characters.

So indeed, when copy-pasting text in a word processor, depending on the
range of text, ie. depending on the structure that is copied: simple
sequence of characters, punctuated sequence of words, paragraphs,
sections, chapters or whole document, you may or may not want to bring
along the styles.  But most often you will want to bring along the
structure.   


eg. probably, if your selection crosses element boundaries, for the characters
that have only one "tag", you won't want to bring the style and faces,
but for characters that are inside elements copied in whole, you will  
want to apply the style for those elements in the target place.  In both
cases, the faces as copied text properties  are useless.

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

Re: Emacs as word processor

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> writes:

> (I still intend to stay out of this thread, for the most part...)
>
> FWIW, wrt the discussion about handling properties, e.g., yanking
> or not etc.:
>
> Two little commands from library `highlight.el' let you copy/paste
> text properties from/to the active region: `hlt-copy-props' and
> `hlt-yank-props'.  And command `hlt-mouse-copy-props' copies them
> from the mouse pointer position (i.e., point & copy).
>
> If you use the mouse to select the region (not necessary, just
> an example) then this is like using the little "paintbrush" tool
> in some applications (e.g. MS Office apps).
>
> Except that you can keep pasting the same properties here and
> there; no need to copy again.  And undo works normally, removing
> the pasted properties.  And you can control which text properties
> get copied, both by option and on the fly.
>
> http://www.emacswiki.org/HighlightLibrary#toc6


Isn't it exactly just what we would want to avoid?

Wouldn't we want to promote structured editing with style sheets, so
that instead of pasting faces, you'd rather change the structure of the
document, indicating <emphasis>, or <blockquote style="literary">
and letting the word processor perform the style cascade and text
rendering?

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

RE: Emacs as word processor

[Drew Adams]

> Isn't it exactly just what we would want to avoid?

No.

As long as you have the possibility of properties (call them what you
like) being attached to individual characters irrespective of any
possible underlying structure, you want to make it easy to transfer
and copy sets of such properties.

Even in a structured application, the _possibility_ should be there.
This is the case, for example, in Framemaker.  You can use it for
both structured applications and for unstructured ones.

Even for use with a structured application, nothing _prevents_ you
from applying ad hoc formatting in Framemaker.  But of course users
of such apps themselves avoid doing that.  Neither I, nor any of my
colleagues, for example, have _ever_ used ad hoc formatting with
Framemaker for the documents we write, which are all structured (XML).

There's an overriding, simple reason for that.  Tools that create
different kinds of output (HTML, help, PDF, for different devices
etc.) work with the underlying structure (in a word, the XML data).
They ignore any ad hoc formatting.  So it does you no good to fiddle
with bold or italic here and there, instead of, say, wrapping an
element in a predefined Emphasis element that has a Role attribute
set to value CodeInlineBold (or whatever).

IOW, enforcement where and when appropriate, and according to strictly
defined schemas.  But nothing prevents you from ad hoc formatting, for
those cases where there is no structured app.

> Wouldn't we want to promote structured editing with style sheets, so
> that instead of pasting faces, you'd rather change the structure of the
> document, indicating <emphasis>, or <blockquote style="literary">
> and letting the word processor perform the style cascade and text
> rendering?

Yes, for a structured application.  That is typically enforced by an
XML Schema schema or a DTD or other validation tools, or at a minimum
by good practice.

Even then, the same UI principle applies.  In Framemaker I can copy
an XML element's attribute values and then paste them onto other
elements.  Depending on user preferences (strict or lax), doing that
to the wrong kind of element (one that does not have the same
attributes) will either be prevented or allowed.

This is a useful and common UI tool.  Whether you are copying a color
(a la eyedropper) or other text attributes, the same idea applies.
Kind of strange, IMO, that Emacs itself has not had such a simple
UI tool.

And yes, I do propose it as a start, for those of you who are
thinking of moving Emacs toward being able to do more WYSIWYG
editing. Copy faces, fonts, background color, whatever from here.
Paste over there. Piece of cake - quick, useful.  And that includes
pasting the absence of certain properties, in order to remove them
from the paste target.

Emacs, above all editors and environments, should not hardcode any
black-&-white behavior in this regard.  It should, on the one hand,
give users the tools to both (a) control editing rigorously, in a
structured way, and (b) on the other hand, allow users to fly by the
seat of their pants.

This should be a no brainer for Emacs.  Emacs was *the* counter
model, back in the 80s & 90s when some were promoting locked-in,
strict "structured editors" (often in Lisp, BTW, and often
implemented using Emacs).

The Emacs approach was to let you do pretty much anything, but to
also provide feedback and validation wrt the desired structure.
And if you wanted strict prevention, Emacs offered you that too.
Guess which model "won".  Au choix.  User control.

This is the Emacs way.  Anything less is limiting.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Achim Gratz]

Richard Stallman writes:
>     I hope that my suggestion to test Org will somehow not be burried
>     with this huge thread :)
>
> I tried it a little bit and it ran into an undefined function.
> Then I rebuilt the autoloads.  I will try it again when I have time.

My recommendation is to use the build system and properly install Org,
otherwise (depending on how your startup is structured) you can all too
easily pull in some older parts of Org that are part of Emacs' own
installation.  The minimum requirement is that the autoloads have been
generated (as you've found out), but in this case the load-path must
point to org-mode/lisp/ before any other startup that potentially loads
any piece of org-mode takes place.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Achim Gratz]

Andreas Röhler writes:
> If you take a look into the org-directory, you'll see several files,
> whose name indicate the purpose beside from org-mode in its strict
> sense.

Before you send others to read those, why not have a look yourself?

> Probably it would be great to have the exporter(s?) --which may output
> into HTML, PDF or ODF-- available in all text-modes.

You might want to take notice that the exporters do exactly nothing
without org-element and org-element defines Org syntax and nothing else.

> From my perspective porting org-footnote.el would pay.

This too depends on the rest of Org to figure out what it is looking at
and where to place the actual content (and then find it again).

> Well, the code providing literal programming is quite an item by
> themselves, no trivial thing.  Just being surprised it should not work
> outside org-mode too ;)

Again, it relies heavily on the infrastructure provided by Org.

There are bits and pieces in Org that would likely benefit from
generalization that might re-factor them out of Org (or not, since
nobody tried yet).  But such refactoring would be a lot of work and
you won't be able to contribute, so…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Emacs as word processor

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> I am not sure.  It seems to require a LOT of time.

It takes a small amount of time to learn a small amount of features,
and a lot of time to learn a lot of features, like any other software.

But IMHO the payoff of learning even a small amount of Org's features
is immediately big, which makes a difference.

Anyway, thanks in advance for your time,

-- 
 Bastien

Re: Emacs as word processor

[Lennart Borgman]

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

On Wed, Nov 27, 2013 at 12:08 AM, Bastien <bzg@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> > I am not sure.  It seems to require a LOT of time.
>
> It takes a small amount of time to learn a small amount of features,
> and a lot of time to learn a lot of features, like any other software.
>
> But IMHO the payoff of learning even a small amount of Org's features
> is immediately big, which makes a difference.
>
> Anyway, thanks in advance for your time,
>
> I would say that org-mode is very easy to get started with. For writing I
think the folding in org-mode is superb. And then you can export to
LibreOffice and finish the writing.

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

Re: Emacs as word processor / Text Properties

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    To me, text properties, and faces as text properties, have always felt
    like a kludge.

Since they belong on a character, they avoid the anomalies that would
otherwise happen when you copy text around in the buffer or between
buffers.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs will never be a WYSIWYG-editor and should not try to

[Andreas Röhler]

Am 26.11.2013 22:45, schrieb Achim Gratz:
> Andreas Röhler writes:
>> If you take a look into the org-directory, you'll see several files,
>> whose name indicate the purpose beside from org-mode in its strict
>> sense.
>
> Before you send others to read those, why not have a look yourself?
>

Why such a tune?
All I'm saying is, a lot of useful things exist in org-mode, which might be of use outside too.
There is an org-timer.el and a timer.el, and org-table.el and a table.el etc.

>> Probably it would be great to have the exporter(s?) --which may output
>> into HTML, PDF or ODF-- available in all text-modes.
>
> You might want to take notice that the exporters do exactly nothing
> without org-element and org-element defines Org syntax and nothing else.
>

Which also means: some parts of org-mode could be re-considered WRT to modularity.
Indeed org-mode didn't invent exporting, so it's useful probably to look into muse or whatever too.


>>  From my perspective porting org-footnote.el would pay.
>
> This too depends on the rest of Org to figure out what it is looking at
> and where to place the actual content (and then find it again).
>
>> Well, the code providing literal programming is quite an item by
>> themselves, no trivial thing.  Just being surprised it should not work
>> outside org-mode too ;)
>
> Again, it relies heavily on the infrastructure provided by Org.
>

If there is an infrastructure useful for org-mode, part of these infrastructure will turn out useful for all Emacs.
There is a bad and a good thing. The god thing is, these things exist. The bad: people a compelled into a separate ecosystem, with its own issues and quirks, a separate 
bug-reporting etc.


> There are bits and pieces in Org that would likely benefit from
> generalization that might re-factor them out of Org (or not, since
> nobody tried yet).

It might be done step by step, starting with useful subroutines like org-trim.
Make a common trim in subr.el from it etc.

That would reduce parallel programming, reduce the volume of the sources etc.

  But such refactoring would be a lot of work and
> you won't be able to contribute, so…

The FSF recieved my disclaimer. Maybe it's sufficient to port the trim function? ;)

Re: Emacs as word processor / Text Properties

[T.V. Raman]

All that said, *every* known WYSWYG word-processor also degrades
to using a dump of its internal data structures as its file
format.  Emacs has stayed free of this mess, and documents I
wrote as a grad student in 1990 are still fully usable and live
in 2013 -- rather than having turned into ossified bags of bits.
This is a feature, not a bug.
-- 

-- 


On 11/26/13, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>
> To me, text properties, and faces as text properties, have always felt
> like a kludge.
>
>
> At best, they may be used to transport information from the modes to the
> display engine, like the faces, but otherwise (apart for quick & dirty
> jobs), it seems to me that in general modes sh/would have more pertinent
> lisp data structures, and use them to set the face in the buffer to
> represent that data structure.
>
> I know that emacs puts a lot of importance on the buffer data structure
> (a sequence of characters with attributes), which is all right for a
> text editor, but when you write _applications_ in emacs, it is much too
> limiting.  And a word processor is an application, with more complex
> data structures than a sequence of characters.
>
> So indeed, when copy-pasting text in a word processor, depending on the
> range of text, ie. depending on the structure that is copied: simple
> sequence of characters, punctuated sequence of words, paragraphs,
> sections, chapters or whole document, you may or may not want to bring
> along the styles.  But most often you will want to bring along the
> structure.
>
>
> eg. probably, if your selection crosses element boundaries, for the
> characters
> that have only one "tag", you won't want to bring the style and faces,
> but for characters that are inside elements copied in whole, you will
> want to apply the style for those elements in the target place.  In both
> cases, the faces as copied text properties  are useless.
>
> --
> __Pascal Bourguignon__
> http://www.informatimago.com/
>
>
>

RE: Emacs as word processor / Text Properties

[Drew Adams]

> All that said, *every* known WYSWYG word-processor also degrades
> to using a dump of its internal data structures as its file
> format.

Not sure just what you mean by that.  But if the internal data
structures faithfully represent XML data, and the output file
format is a serialization of that XML data, then this is hardly
messy or lossy.

And that is the case for more and more "WYSIWYG" editors, at
least the "high-end" ones.  The internal data structures are XML,
and the file format is XML.  From the internal XML, or from the
output XML file, is generated XHTML, PDF, or whatever.

Internally, an XML representation might use a DOM or binary XML
or any number of other implementation means.  But the only
important question is whether the output (serialized) form and
the internal form mirror each other properly.

(For that, there can be considerations of whether document
fidelity is needed or just DOM fidelity (i.e., whether or not
insignificant whitespace needs to be preserved).

Sometimes an editor ("word processor") has additional output
file formats, even if it is capable of saving as XML.  But
that's another story.  More and more, the "real" output file
format is XML.  (Yes, for MS Word, most people still see
*.doc files, not XML files.)

Re: Emacs as word processor / Text Properties

[T.V. Raman]

Internal data structures being XML is a small step -- but only a
very small step. Angle brackets do not in themselves semantics
make:-)

For seeing what I mean, just take a look at the xml files in any
of the modern MS  Office file formats.  Most word-processors
after a while lose the distinction between layout style and
content, and what results in the file format is a messy bag of bits.
-- 

-- 


On 11/27/13, Drew Adams <drew.adams@oracle.com> wrote:
>> All that said, *every* known WYSWYG word-processor also degrades
>> to using a dump of its internal data structures as its file
>> format.
>
> Not sure just what you mean by that.  But if the internal data
> structures faithfully represent XML data, and the output file
> format is a serialization of that XML data, then this is hardly
> messy or lossy.
>
> And that is the case for more and more "WYSIWYG" editors, at
> least the "high-end" ones.  The internal data structures are XML,
> and the file format is XML.  From the internal XML, or from the
> output XML file, is generated XHTML, PDF, or whatever.
>
> Internally, an XML representation might use a DOM or binary XML
> or any number of other implementation means.  But the only
> important question is whether the output (serialized) form and
> the internal form mirror each other properly.
>
> (For that, there can be considerations of whether document
> fidelity is needed or just DOM fidelity (i.e., whether or not
> insignificant whitespace needs to be preserved).
>
> Sometimes an editor ("word processor") has additional output
> file formats, even if it is capable of saving as XML.  But
> that's another story.  More and more, the "real" output file
> format is XML.  (Yes, for MS Word, most people still see
> *.doc files, not XML files.)
>

RE: Emacs as word processor / Text Properties

[Drew Adams]

> Internal data structures being XML is a small step -- but only a
> very small step. Angle brackets do not in themselves semantics
> make:-)

Angle brackets are not an inherent part of XML, except its serialized
form.  Think XML data, not XML as marked-up text.  No one represents
XML internally using text.  Not an angle bracket in sight.

And internal data structure being XML or Lisp sexps (which I also
suggested) would be a GIANT step.  A definition of well formedness
and being able to validate against schemas (e.g., XML schemas or DTDs)
makes a huge difference.

> For seeing what I mean, just take a look at the xml files in any
> of the modern MS Office file formats.

Not a reference, sorry - not representative.  I've already commented
on this.  MS Office's use of XML is not up to par.  But even it might
improve with time...  It has to interact with the rest of the world.
At a minimum, it has to grok clean XML and sooner or later will need
to be able to output clean XML for others (or they will filter to
get that).

> Most word-processors after a while lose the distinction between
> layout style and content, and what results in the file format is
> a messy bag of bits.

Wrong.  The tendency is in the other direction, at least if you
include high-end tools that people use to create doc.  Of course,
if you just count the number of executables out there in the wild,
then MS Word might beat all others combined (just a guess).  Still,
it is not the measure I use, and it certainly is not a goal that
anyone starting today would aim for.

In the context of Emacs, which would be to a large extent starting
from scratch in this area, there is zero reason to emulate something
like MS Word, in terms either of its internal data representations
or its *.doc files.  (That does not mean that Emacs could not import
or export *.doc files.  I mean only that it is far saner to build on
something like XML.)

Re: Emacs as word processor / Text Properties

[T.V. Raman]

I have been a fan of XML for 15 years. But that said, you're not
going to convince me  that I'll do better with something that is
a reflection of data structures from a word processor as opposed
to say an org file that focuses on the structure of my content. I
became a fan of XML because I hoped it would bring the richness
of s-expressions to the Web, but that dream collapsed a long time ago.

-- 
Best Regards,
--raman


On 11/27/13, Drew Adams <drew.adams@oracle.com> wrote:
>> Internal data structures being XML is a small step -- but only a
>> very small step. Angle brackets do not in themselves semantics
>> make:-)
>
> Angle brackets are not an inherent part of XML, except its serialized
> form.  Think XML data, not XML as marked-up text.  No one represents
> XML internally using text.  Not an angle bracket in sight.
>
> And internal data structure being XML or Lisp sexps (which I also
> suggested) would be a GIANT step.  A definition of well formedness
> and being able to validate against schemas (e.g., XML schemas or DTDs)
> makes a huge difference.
>
>> For seeing what I mean, just take a look at the xml files in any
>> of the modern MS Office file formats.
>
> Not a reference, sorry - not representative.  I've already commented
> on this.  MS Office's use of XML is not up to par.  But even it might
> improve with time...  It has to interact with the rest of the world.
> At a minimum, it has to grok clean XML and sooner or later will need
> to be able to output clean XML for others (or they will filter to
> get that).
>
>> Most word-processors after a while lose the distinction between
>> layout style and content, and what results in the file format is
>> a messy bag of bits.
>
> Wrong.  The tendency is in the other direction, at least if you
> include high-end tools that people use to create doc.  Of course,
> if you just count the number of executables out there in the wild,
> then MS Word might beat all others combined (just a guess).  Still,
> it is not the measure I use, and it certainly is not a goal that
> anyone starting today would aim for.
>
> In the context of Emacs, which would be to a large extent starting
> from scratch in this area, there is zero reason to emulate something
> like MS Word, in terms either of its internal data representations
> or its *.doc files.  (That does not mean that Emacs could not import
> or export *.doc files.  I mean only that it is far saner to build on
> something like XML.)
>

Re: Emacs as word processor / Text Properties

[Lennart Borgman]

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

The capability to export from .org files to LibreOffice etc is a very good
feature. However the trouble is you can not import LibreOffice (since .org
files can't handle all of the structure).

I think it is a huge job to be able to edit something with all the
structures in a LibreOffice file (I am thinking of just Writer part).
Perhaps a LibreOffice plugin is a bit easier to develop since Emacs does
not have to hold the complicated XML data. I suppose it has to ask
LibreOffice for it. Perhaps the plugin then must not then be able to edit
all the data. (That depends of course on the plugin architecture.)


On Thu, Nov 28, 2013 at 1:50 AM, T.V. Raman <tv.raman.tv@gmail.com> wrote:

> I have been a fan of XML for 15 years. But that said, you're not
> going to convince me  that I'll do better with something that is
> a reflection of data structures from a word processor as opposed
> to say an org file that focuses on the structure of my content. I
> became a fan of XML because I hoped it would bring the richness
> of s-expressions to the Web, but that dream collapsed a long time ago.
>
> --
> Best Regards,
> --raman
>
>
> On 11/27/13, Drew Adams <drew.adams@oracle.com> wrote:
> >> Internal data structures being XML is a small step -- but only a
> >> very small step. Angle brackets do not in themselves semantics
> >> make:-)
> >
> > Angle brackets are not an inherent part of XML, except its serialized
> > form.  Think XML data, not XML as marked-up text.  No one represents
> > XML internally using text.  Not an angle bracket in sight.
> >
> > And internal data structure being XML or Lisp sexps (which I also
> > suggested) would be a GIANT step.  A definition of well formedness
> > and being able to validate against schemas (e.g., XML schemas or DTDs)
> > makes a huge difference.
> >
> >> For seeing what I mean, just take a look at the xml files in any
> >> of the modern MS Office file formats.
> >
> > Not a reference, sorry - not representative.  I've already commented
> > on this.  MS Office's use of XML is not up to par.  But even it might
> > improve with time...  It has to interact with the rest of the world.
> > At a minimum, it has to grok clean XML and sooner or later will need
> > to be able to output clean XML for others (or they will filter to
> > get that).
> >
> >> Most word-processors after a while lose the distinction between
> >> layout style and content, and what results in the file format is
> >> a messy bag of bits.
> >
> > Wrong.  The tendency is in the other direction, at least if you
> > include high-end tools that people use to create doc.  Of course,
> > if you just count the number of executables out there in the wild,
> > then MS Word might beat all others combined (just a guess).  Still,
> > it is not the measure I use, and it certainly is not a goal that
> > anyone starting today would aim for.
> >
> > In the context of Emacs, which would be to a large extent starting
> > from scratch in this area, there is zero reason to emulate something
> > like MS Word, in terms either of its internal data representations
> > or its *.doc files.  (That does not mean that Emacs could not import
> > or export *.doc files.  I mean only that it is far saner to build on
> > something like XML.)
> >
>
>

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

Re: Emacs as word processor / Text Properties

[Stephen J. Turnbull]

Lennart Borgman writes:

 > The capability to export from .org files to LibreOffice etc is a very
 > good feature.

That's arguable.  It means that you may not be able to roundtrip editing:

 > However the trouble is you can not import LibreOffice (since .org
 > files can't handle all of the structure).

That's T.V.'s point, you see.  Well, actually you have to look at *why*
you can't import it.  So, let's see ....

How often do you actually need the structure that's imposed?  Consider
the HTML email I'm responding to, which is a response to a plain text
email.  In my (ancient broken) MUA, your email completely screws up the
display and confuses the message-mode buffer when I yank it.  Did you
actually use any features that aren't present in plain text to express
your ideas?  No.  But you screwed up my MUA (which is HTML-aware, but
not good enough to handle the crap produced by HTML-oriented MUAs)
anyway, for no good reason.  The same thing will happen to you if you
export a document composed in org-mode to .odt so a person who uses
*Office can edit it.  Every time, regardless of need for features that
org doesn't provide.

*Most of the time* there's no *content* or *expression* in a .doc or
.odt file that org-mode can't handle fine.  But you still can't import
it.  That's just *wrong*.

I will grant Drew's point: I'm sure that the high-end WYSIWYG programs
do keep a good separation between content (including expressive
semantics such as "emphasis") and presentation.  But *Office doesn't,
and won't for a decade, I expect.  And that's our target, not
Framemaker, because the people we need to exchange documents with use
*Office.

RE: Emacs as word processor / Text Properties

[Drew Adams]

> I will grant Drew's point: I'm sure that the high-end WYSIWYG programs
> do keep a good separation between content (including expressive
> semantics such as "emphasis") and presentation.  But *Office doesn't,
> and won't for a decade, I expect.  And that's our target, not
> Framemaker, because the people we need to exchange documents with use
> *Office.

(They also use HTML and PDF... and mobipocket and epub...)

I thought I saw two goals/targets mentioned - somewhat independent,
if not contradictory:

1. Exchange with other tools/apps like *Office: import/export (save as).

2. Emacs as a clean WYSIWYG editor.

I was speaking mainly to #2: schema-definable structure cohabiting
with WYSIWYG.

I don't see that #1 alone "is our target".  Just one opinion.

I might even suggest not worrying about #1 on its own.  Get #2 right
and import/export will follow, to a large degree.  And to the degree
that *Office documents are incompatible with clean XML/XHTML/whatever,
just say no: don't worry much about it.

RE: Emacs as word processor / Text Properties

[Stephen J. Turnbull]

Drew Adams writes:

 > I don't see that #1 alone "is our target".  Just one opinion.

I don't either.  My point is simply that *if* sharing files (your #1)
is *a* goal, the target formats are *Office formats (.doc, OOXML, ODF
basically, and maybe we can ignore .doc in the near future).

 > I might even suggest not worrying about #1 on its own.  Get #2 right
 > and import/export will follow, to a large degree.

Export, already demonstrated in practice.  Import, I'll bet you my
dollars against your yen (up to a reasonable number like "20") that
getting separation of content from presentation (#2) right gets you
about 10% of the way to importing any of those formats reliably.

 > And to the degree that *Office documents are incompatible with
 > clean XML/XHTML/whatever, just say no: don't worry much about it.

That's cheating, of course. :-)  I don't have anything against that
strategy, personally (it's the one I advocate, after all).  But there
are people who think that file sharing with non-Emacs users is a goal.

Re: Emacs as word processor / Text Properties

[Bastien]

Drew Adams <drew.adams@oracle.com> writes:

> I might even suggest not worrying about #1 on its own.  Get #2 right
> and import/export will follow, to a large degree.

A few years of hacking Org suggests that it's useful to think about
#1 and #2 as closely tangled issues.

2 cents, of course,

-- 
 Bastien

Re: Emacs as word processor / Text Properties

[Andreas Röhler]

Am 28.11.2013 08:34, schrieb Bastien:
> Drew Adams <drew.adams@oracle.com> writes:
>
>> I might even suggest not worrying about #1 on its own.  Get #2 right
>> and import/export will follow, to a large degree.
>
> A few years of hacking Org suggests that it's useful to think about
> #1 and #2 as closely tangled issues.
>
> 2 cents, of course,
>

Or to say #1 would provide the machine to build #2 upon.

Then it's up to decide using #1 for faster editing large texts, while #2 with single, occasional pages or for Emacs beginners might be preferable.

Re: Emacs as word processor / Text Properties

[Jambunathan K]

"T.V. Raman" <tv.raman.tv@gmail.com> writes:

> All that said, *every* known WYSWYG word-processor also degrades to
> using a dump of its internal data structures as its file format.

Dis-regarding Org-mode, is like dis-regarding elephant in the room.

The proposed word-processing mode MAY or MUST save to or import from
Org-mode format.  (Org-mode is indeed a storage format)

LibreOffice has a configuration option whereby one can configure the
default format for saving.

In an Ideal World, I should be able to edit in Word-processing mode but
save it in Org-mode.  What this means that "Text markup" like *, / etc
and directives like "#+BEGIN_" etc are implicitly specified (and hence
hidden from the user) and honored on read-in and write-out.

Re: Emacs as word processor / Text Properties

[Jambunathan K]

A bit freewheeling.


"T.V. Raman" <tv.raman.tv@gmail.com> writes:

> the structure of my content

Much depends on "my".

Let me call it "What I mean is what I mean" (Get off my lawn) processing
mode.

----------------------------------------------------------------

Novel, Script writing:
=====================

I remember seeing a screenshot (does someone have a link?) of an Emacs
buffer of popular sci-fi writer.  The buffer was showing a WIP novel.
IIRC, It was a flip-flop of ">"-prefixed lines (think Gnus-citaion
markers) and regular lines with the convention that one stood for the
actual prose of the novel and the other note on current context.  (For
example, the author could do flush-lines and keep-lines and get an early
draft of the novel.)

This author was proficient enough to have "invent his own system and
conventions to aid his own workflow".  (Isn't this freedom is all
about?)

Thought experiment:
==================

If I am a writer of novels (complex plot, reliant on research material
collected from disparate sources), can I re-purpose my Emacs to
"self-publish" a novel without getting in the way and much less effort.

----------------------------------------------------------------

Multi-lingual documents:
=====================

How about documents that have multiple scripts and one MAY have to
fiddle with bidi-settings on a per-element basis.  (Things like Bidi are
not only about aesthetics but also tied directly to the "content".)

Now if you want to have Tables with Bidi-text then Orgmode is
practically useless.

----------------------------------------------------------------

Org emphasis markers are un-satisfactory
========================================

Org - like any other markup format - imposes itself on the user.  (i.e.,
it caters to the lowest common denominator.)

Unfortuanately, there are people who want slightly more than the lowest
common denominator.  There have been numerous threads in the past, where
Org (and hence Emacs in general, so to speak) is KNOWN to be
unsatisfactory and getting in the way of what the user wants to do.

----------------------------------------------------------------

Realities of having and maintain a hand-written parser
======================================================

Org maintainers have refused to re-consider or re-purpose Org emphasis
markers (for a good reason).  By, "Emphasis" is meant what the user
himself thinks as emphasis and not what Org says it ought to be.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14157#8.

----------------------------------------------------------------

Emacs Lisp, Customizable, Extensible - Huh! - No Thanks
========================================================

Insisting on proficiency with Emacs Lisp, when computers and Emacs are
being used by non-programmers (Think, Arts and Humanities. A
non-LaTeX(?) camp.  Supporter of OpenDocument formats.)  is a bit absurd
in modern times.

That something is extensible or customizable is good on paper.  But if
it cannot put food on the plate, then that is a bit sad.

How many users of Emacs do you think can write a defun (leave alone a
export filter) in a single go.

,---- http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00849.html
| 
| So, is this feature a must-have? Or would a filter template in Worg more
| appropriate in this case?
`----

This thread was about introducing pagebreaks in the exported document.

,---- http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00849.html
|
| Anyway, I don't think this is a good idea to introduce a new syntax just
| to avoid a one-liner (or a hook, see below). Also, this would only make
| sense in few export back-ends.
| 
| Really, introducing new syntax has a cost, so you have to ponder if it's
| really useful, because, once installed, every Org user will have to pay
| the price for it.
| 
| Admittedly, in this particular case, that cost isn't very high, but
| I think it would nonetheless add up to the list of hardly-used syntax
| category."
`----

----------------------------------------------------------------

Generating Indices
==================

texi allows one to build an "index".

Is there a way I can specify an index for a book or manual I write with
Org-mode?

In LibreOffice, one can "extract" certain styles and generate a TOC for
it.

----------------------------------------------------------------

No Bibliographies
=================

There is no "standard" way to create Bibliographies.

----------------------------------------------------------------

No Real-life Tables
===================

I have expanded on this aspect before.

----------------------------------------------------------------

Need to extract and transform Text Properties
============================================

I believe the word-processing mode can come with an added feature
whereby one can "grok or transform" text based on "Text Properties".
i.e., Think regexp-replace but regexp specifies properties and not the
text itself.

See

    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15244
    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15245

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Let me call it "What I mean is what I mean" (Get off my lawn) processing
> mode.

without incurring Himalayan overheads.

Re: Emacs as word processor / Text Properties

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Let me call it "What I mean is what I mean" (Get off my lawn) processing
>> mode.
>
> without incurring Himalayan overheads.

Maybe of interest: https://en.wikipedia.org/wiki/WYSIWYM

-- 
 Bastien

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

>> Jambunathan K <kjambunathan@gmail.com> writes:
>>
>>> Let me call it "What I mean is what I mean" (Get off my lawn) processing
>>> mode.
>>
>> without incurring Himalayan overheads.
>
> Maybe of interest: https://en.wikipedia.org/wiki/WYSIWYM

"When I use a word," Jambu said, in rather a scornful tone, "it means
just what I choose it to mean—neither more nor less."

Re: Emacs as word processor / Text Properties

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> "When I use a word," Jambu said, in rather a scornful tone, "it means
> just what I choose it to mean—neither more nor less."

"The question is," said Bastu, "whether you can make words mean so
many different things."

-- 
 Bastien

Re: Emacs as word processor / Text Properties

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Fri, 29 Nov 2013 14:14:31 +0530
> Cc: "Pascal J. Bourguignon" <pjb@informatimago.com>,
> 	Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> How about documents that have multiple scripts and one MAY have to
> fiddle with bidi-settings on a per-element basis.

I must confess I have no idea what you are talking about here: what
"bidi settings"?

> (Things like Bidi are not only about aesthetics but also tied
> directly to the "content".)

Again, if this is a real issue, please elaborate.  Bidi is neither
about aesthetics nor about "content", it's about displaying certain
scripts as their readers require.  To understand that, imagine that
you need to read English text where the order of the characters was
reversed.  I guess you won't be amused.

> Now if you want to have Tables with Bidi-text then Orgmode is
> practically useless.

"Practically useless" is a wild exaggeration.  I use it just fine.

But yes, there are several features of the UBA that Emacs supports
which can improve this.  Org Mode should use those features when
appropriate.  Unfortunately, too many Emacs modes, Org included, still
treat text as a unidirectional stream of characters that will keep
their logical order on display, and don't cater enough to the needs of
bidirectional scripts.  I expect Org users who work with those scripts
to submit bug reports with specific use cases, and ask the Org
maintainers to use the above-mentioned features.

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jambunathan K <kjambunathan@gmail.com>
>> Date: Fri, 29 Nov 2013 14:14:31 +0530
>> Cc: "Pascal J. Bourguignon" <pjb@informatimago.com>,
>> 	Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
>> 
>> How about documents that have multiple scripts and one MAY have to
>> fiddle with bidi-settings on a per-element basis.
>
> I must confess I have no idea what you are talking about here: what
> "bidi settings"?

I have a vague understanding of Bidi based on what I read here:

   https://web.archive.org/web/20130917205858/http://dotancohen.com/howto/rtl_right_to_left.html

From that link:

,----
| Word Processor documents
| 
| In OpenOffice Writer, pages can be configured as RTL in Format → Page →
| Page → Text Direction. Paragraphs can be configured to RTL in Format →
| Paragraph → Alignment → Text Direction.
`----

,----
| HTML code
| 
| HTML is fairly straightforward to configure for RTL. Like word
| processors documents, entire pages or individual paragraphs can be set
| to RTL.
`----

Let me ask you a question back:

What if I want a bidi-paragraph-direction where the "directionality is
UNLIKE the first strong directional character".

Emacs cannot do that.

ps: When I ask this question, I assume that the people who wrote the
standards have good enough reasons to introduce tag paragraph
"explicitly".

,----
| bidi-paragraph-direction is a variable defined in `C source code'.
| Its value is nil
| 
|   Automatically becomes buffer-local when set.
|   This variable is safe as a file local variable if its value
|   satisfies the predicate which is a byte-compiled expression.
| 
| Documentation:
| If non-nil, forces directionality of text paragraphs in the buffer.
| 
| If this is nil (the default), the direction of each paragraph is
| determined by the first strong directional character of its text.
| The values of `right-to-left' and `left-to-right' override that.
| Any other value is treated as nil.
| 
`----

>> (Things like Bidi are not only about aesthetics but also tied
>> directly to the "content".)
>
> Again, if this is a real issue, please elaborate.  Bidi is neither
> about aesthetics nor about "content", it's about displaying certain
> scripts as their readers require.  To understand that, imagine that
> you need to read English text where the order of the characters was
> reversed.  I guess you won't be amused.

I was responding to Raman and merely noting that word-processing mode
cannot be discerned just in terms of aesthetics or content alone.
Directonality is neither about aesthetic nor about content but about
convention.  It falls in a no-man land.

>> Now if you want to have Tables with Bidi-text then Orgmode is
>> practically useless.
>
> "Practically useless" is a wild exaggeration.  I use it just fine.

This is not a criticism of Bidi.  This thread is about why an
word-processing mode would make sense INSPITE of powerfulness of
Org-mode.


Currently, in Org-mode, one cannot have multi-paragraph tables.
Assuming that in near future, it does support such tables, how would one
go about fixing the directionality.

> But yes, there are several features of the UBA that Emacs supports
> which can improve this.  Org Mode should use those features when
> appropriate.  Unfortunately, too many Emacs modes, Org included, still
> treat text as a unidirectional stream of characters that will keep
> their logical order on display, and don't cater enough to the needs of
> bidirectional scripts.  I expect Org users who work with those scripts
> to submit bug reports with specific use cases, and ask the Org
> maintainers to use the above-mentioned features.

Bottom line is this:

Org-mode is useful in practice but it falls way short of being a
"complete" system.  It is here that a word-processing mode will be
extremely useful.

Let me re-iterate, I am responding to Raman whose comment vaguely
implied that the coupling between content and display is loose enough to
the point of being non-existent and that content with a very lightweight
markup would serve "complete" set of needs.

Here is a case of Chinese user saying that Org's notion of emphasis
markers is in conflict with the realities of his language.

http://lists.gnu.org/archive/html/emacs-orgmode/2012-11/msg00564.html

Re: Emacs as word processor / Text Properties

[Andreas Röhler]

[ ... ]
>
> Org emphasis markers are un-satisfactory
> ========================================
>
> Org - like any other markup format - imposes itself on the user.  (i.e.,
> it caters to the lowest common denominator.)
>
> Unfortuanately, there are people who want slightly more than the lowest
> common denominator.  There have been numerous threads in the past, where
> Org (and hence Emacs in general, so to speak) is KNOWN to be
> unsatisfactory and getting in the way of what the user wants to do.
>

Right. Another reason why the stuff needs to be abstracted from org-mode.

Re: Emacs as word processor / Text Properties

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Nov 2013 15:21:27 +0530
> 
> What if I want a bidi-paragraph-direction where the "directionality is
> UNLIKE the first strong directional character".
> 
> Emacs cannot do that.

Yes, it can: set bidi-paragraph-direction to either left-to-right or
right-to-left, and that setting will override the dynamic
determination of paragraph base direction by its first strong
directional character.  This is the equivalent of the following Office
feature:

> | In OpenOffice Writer, pages can be configured as RTL in Format → Page →
> | Page → Text Direction.

If you need to override the base direction of a single paragraph, as
in this feature:

> |                         Paragraphs can be configured to RTL in Format →
> | Paragraph → Alignment → Text Direction.

then simply insert LRM or RLM characters at the beginning of that
paragraph.

> ps: When I ask this question, I assume that the people who wrote the
> standards have good enough reasons to introduce tag paragraph
> "explicitly".

There are no "tag paragraphs" in the Unicode Standard.  There's a
reference to "higher-level protocols", which can be anything.  But
until and unless someone explains why inserting invisible control
characters is not enough, I see no reason to introduce anything more
complex into Emacs.  In any case, such additional features will only
make sense if Emacs saves the buffer as something other than plain
text, because in plain text, _the_only_ means of overriding
directionality is with the bidirectional control characters.

> ,----
> | bidi-paragraph-direction is a variable defined in `C source code'.
> | Its value is nil
> | 
> |   Automatically becomes buffer-local when set.
> |   This variable is safe as a file local variable if its value
> |   satisfies the predicate which is a byte-compiled expression.
> | 
> | Documentation:
> | If non-nil, forces directionality of text paragraphs in the buffer.
> | 
> | If this is nil (the default), the direction of each paragraph is
> | determined by the first strong directional character of its text.
> | The values of `right-to-left' and `left-to-right' override that.
> | Any other value is treated as nil.
> | 
> `----

Yes, exactly: see the last paragraph of this doc string.

> I was responding to Raman and merely noting that word-processing mode
> cannot be discerned just in terms of aesthetics or content alone.
> Directonality is neither about aesthetic nor about content but about
> convention.  It falls in a no-man land.

It falls in the display engine land.

> >> Now if you want to have Tables with Bidi-text then Orgmode is
> >> practically useless.
> >
> > "Practically useless" is a wild exaggeration.  I use it just fine.
> 
> This is not a criticism of Bidi.  This thread is about why an
> word-processing mode would make sense INSPITE of powerfulness of
> Org-mode.

You said that Org mode is practically useless when used with
bidirectional text.  I'm saying that I use Org like that every day, so
it is not useless.

IOW, this is not about Bidi, this is about Org used with bidirectional
scripts.

> Currently, in Org-mode, one cannot have multi-paragraph tables.
> Assuming that in near future, it does support such tables, how would one
> go about fixing the directionality.

You already asked this in the past, and I already provided several
alternatives.  One is to use TAB characters, another is to use the
'(space . PROPS)' display spec, yet another is to use RLM/RLM
controls.  Between these, I don't believe there's a problem we won't
be able to solve.

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Thanks for the note.

>> ps: When I ask this question, I assume that the people who wrote the
>> standards have gooed enough reasons tag paragraphs as RTL or LTR
>> "explicitly".

> But until and unless someone explains why inserting invisible control
> characters is not enough

I don't know.

You are saying that explicit markers could be used in place of
per-paragraph tagging to achieve the desired effect.

May be it is not a question of "enough" but a question of
"manageable". i.e., minimizing or eliminating undesired effects while
moving - copy + pasting - the text around.

The FAQ below talks about avoiding paired control codes (to avoid
goofing up of structure) and says RLM and LRM are "less problematic".

So, the question is were you surprised (or annoyed) by unexpected
directionality when copy-pasting text that have markers.  Will use of
per-paragraph specification minimize the associated headaches.

,---- http://www.w3.org/International/questions/qa-bidi-controls.en.php
|
| To correctly format bidi text in (X)HTML or XML content, should I use
| Unicode control codes or markup?
| 
| [snip]
| 
| In (X)HTML and XML do not use the paired Unicode bidi formatting code
| characters where equivalent markup is available.
| 
| Reasons
| 
| When control characters are used in free-flowing content there is always
| a likelihood of overlapping or unterminated ranges - especially because
| the characters themselves have no visible form. If attributes are used,
| this is not an issue in well-formed markup.
| 
| It is also much easier to manage inheritance and the effects of
| paragraph separators with markup. Using Unicode controls results in a
| lot more work to achieve the same result. Also it is difficult to know
| how to achieve effects like reversing table columns and right-aligning
| text with just Unicode control codes.
| 
| The HTML 4 specification specifically warns against mixing the two
| approaches because of the increased likelihood of improper nesting. It
| also recommends the use of markup because it "offers a better guarantee
| of document structural integrity and alleviates some problems when
| editing bidirectional HTML text with a simple text editor". It does not
| proscribe the use of Unicode bidi formatting codes.
| 
| The joint Unicode Technical Report #20 and W3C Note, Unicode in XML and
| other Markup Languages goes further. It explicitly recommends that only
| the markup be used.
| 
| [snip]
| 
| RLM and LRM characters
| 
| Two other invisible but non-embedding directional control characters
| provided by Unicode do not usually have corresponding markup and should
| be used either in character or escaped form. Note that they are less
| problematic because they are used singly, not in pairs to delimit ranges
| of text like the other control characters we have discussed.
| 
|     U+200E:   LEFT-TO-RIGHT MARK
|     U+200F:   RIGHT-TO-LEFT MARK
`----

>> Currently, in Org-mode, one cannot have multi-paragraph tables.
>> Assuming that in near future, it does support such tables, how would one
>> go about fixing the directionality.
>
> You already asked this in the past, and I already provided several
> alternatives.  One is to use TAB characters, another is to use the
> '(space . PROPS)' display spec, yet another is to use RLM/RLM
> controls.  Between these, I don't believe there's a problem we won't
> be able to solve.

I am sleeping on it.

The scenario I am placing is this:

     Org-mode table + Multi-paragraph table cells + Mixed scripts.

From the FAQ above,     

,----
| ... Using Unicode controls results in a lot more work to achieve the
| same result. Also it is difficult to know how to achieve effects like
| reversing table columns and right-aligning text with just Unicode
| control codes.
`----

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

>> Currently, in Org-mode, one cannot have multi-paragraph tables.
>> Assuming that in near future, it does support such tables, how would one
>> go about fixing the directionality.
>
> You already asked this in the past, and I already provided several
> alternatives.  One is to use TAB characters, another is to use the
> '(space . PROPS)' display spec, yet another is to use RLM/RLM
> controls.  Between these, I don't believe there's a problem we won't
> be able to solve.

For the sake of record, Uwe ended up with "physically" reversing a table
row.  Note the absence of Bidi markers in that text.

See
http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00281.html

ps: My "gut feeling" is that Uwe is also new to Bidi markups.

Re: Emacs as word processor / Text Properties

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Nov 2013 19:12:32 +0530
> 
> You are saying that explicit markers could be used in place of
> per-paragraph tagging to achieve the desired effect.

No, I'm saying more than that: inserting those control characters _is_
the Emacs way of tagging the paragraph as having a certain base
direction.  Since Emacs is mostly about plain-text files, there's no
other way to achieve that effect, while being sure that any other
random UBA-compliant application will obey that.

> May be it is not a question of "enough" but a question of
> "manageable". i.e., minimizing or eliminating undesired effects while
> moving - copy + pasting - the text around.

I see no adverse effects from copy/paste due to these controls, except
those effects that are already here to stay: in general, pasting
bidirectional text into a middle of another text can already have
profound non-local effects on how the paragraph into which you paste
is displayed.  RLM and LRM are just 2 strong directional characters,
so their effect is the same as that of some Arabic or Hebrew
character.

> The FAQ below talks about avoiding paired control codes (to avoid
> goofing up of structure) and says RLM and LRM are "less problematic".

Don't take what w3.org says about (X)HTML and XML as having any
relevance whatsoever on what Emacs does or needs to do.  Emacs deals
with plain text that is generally devoid of any persistent tags or
other meta-data, so it cannot possibly DTRT by tags and markup, it
must use only characters and directional controls.  By contrast,
w3.org is about markup languages, where the situation is entirely
different, and actually using LRM, RLM, and other Unicode controls is
"considered harmful".

> The scenario I am placing is this:
> 
>      Org-mode table + Multi-paragraph table cells + Mixed scripts.
> 
> >From the FAQ above,     
> 
> ,----
> | ... Using Unicode controls results in a lot more work to achieve the
> | same result. Also it is difficult to know how to achieve effects like
> | reversing table columns and right-aligning text with just Unicode
> | control codes.
> `----

"A lot more work" might be relevant for a human who prepares a Web
page by hand, but it is no excuse for an Emacs mode.  A layman might
have hard time figuring out the effect of this or that technique wrt
bidirectional text, but we in Emacs have enough knowhow and experience
to deal with that correctly, and the infrastructure already exists to
make it possible.  All we need is for modes to use that.

Re: Emacs as word processor / Text Properties

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Nov 2013 19:48:16 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Currently, in Org-mode, one cannot have multi-paragraph tables.
> >> Assuming that in near future, it does support such tables, how would one
> >> go about fixing the directionality.
> >
> > You already asked this in the past, and I already provided several
> > alternatives.  One is to use TAB characters, another is to use the
> > '(space . PROPS)' display spec, yet another is to use RLM/RLM
> > controls.  Between these, I don't believe there's a problem we won't
> > be able to solve.
> 
> For the sake of record, Uwe ended up with "physically" reversing a table
> row.  Note the absence of Bidi markers in that text.
> 
> See
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00281.html

That thread talks about exporting to ODT, so I don't really understand
the issues involved.

> ps: My "gut feeling" is that Uwe is also new to Bidi markups.

He's certainly not new to them.  But for some reason he didn't respond
to my suggestions and didn't heed to them.

Re: Emacs as word processor / Text Properties

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

> No, I'm saying more than that: inserting those control characters _is_
> the Emacs way of tagging the paragraph as having a certain base
> direction.  Since Emacs is mostly about plain-text files, there's no
> other way to achieve that effect, while being sure that any other
> random UBA-compliant application will obey that.

As a side note, what this means is that "importers" (HTML -> Text
converters) like eww + shr MUST insert "extra" directional markers while
dealing with directional tags.

Re: Emacs as word processor / Text Properties

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Nov 2013 22:17:38 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, I'm saying more than that: inserting those control characters _is_
> > the Emacs way of tagging the paragraph as having a certain base
> > direction.  Since Emacs is mostly about plain-text files, there's no
> > other way to achieve that effect, while being sure that any other
> > random UBA-compliant application will obey that.
> 
> As a side note, what this means is that "importers" (HTML -> Text
> converters) like eww + shr MUST insert "extra" directional markers while
> dealing with directional tags.

No, they shouldn't.  That's not how Emacs works.  Instead, Emacs
should process the directional tags and DTRT.  This (i.e. display of
marked-up bidirectional text) is not yet supported, but OTOH no one
requested that yet.  (Well, actually, one person did, several years
ago, but I never heard from him since.)

Inserting into buffer text something that wasn't there to begin with
is asking for trouble: sooner or later that something will leak to the
disk, and users will rightfully complain that Emacs corrupts their
files.

Re: Emacs as word processor / Text Properties

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    The proposed word-processing mode MAY or MUST save to or import from
    Org-mode format.  (Org-mode is indeed a storage format)

I am sure that it will support this format, because that's not the
hard part.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Hendrik Boom]

On Sun, 17 Nov 2013 02:28:51 -0500, Richard Stallman wrote:

> 25 years ago I hoped we would extend Emacs to do WYSIWG word processing.
>  That is why we added text properties and variable width fonts. 
> However, more features are still needed to achieve this.
> 
> Could people please start working on the features that are needed?

There is one reason that I use emacs for my writing.

The file structure is very compatible with modern distributed revision 
management systems.  (I use monotone).

When I edit stuff, only the bit I'm editing changes.  The rest stays the 
same.

I've introduced minimal mark-up, so that I can specify italics and such 
when I need them.  And I wrote a program to convert the (almost) plain-
text to .fodt so I can feed it into LibreOffice for a nice printout.

Maybe I should just have used asciidoc or markdown.  But when I  started 
on this stuff I didn't know about those tools, and maybe the didn't exist 
yet.

The main spec for this program is that it doesn't choke on *any* input, 
and does something reasonable with it whether it is nicely marked up or 
not.

I avoid large-scale bracketing structure as much as I can, because the 
merge tools used with revision control are terrible at preserving 
brackets.

I OpenOffice would place lots of line breaks in consistent places so that 
revision management would merge properly, .fodt's bracket structure would 
*still* be a problem, because LibreOffice chokes on bracket mismatch.

So in my markup, I assign operator priorities to separators -- like 
paragraphs, sections, and so forth.  The code is a mess, because I didn't 
realize this at first.  Everything will need to be rewritten a few times 
before my program does what I want and is really well-structured.  But 
hey, this is experimental (textual) UI programming, and you don't know 
what you want until you have it and it isn't it.

I wouldn't mind in the slightest if I were to be editing WYSIWYG and the 
word-processor were to save my data in an internal format that's amenable 
to revision management and automatic merging.  Especially if it avoids 
layout-specification overkill the way most word processors do.  I'm 
really interested in a document compiler where I specify structural 
matters and the word processor shows me how it might look on a page.  But 
the page layout shouldn't be definitive.  If I map it onto a different 
page size, it should reflow, adjust.  In fact, it might as well adapt 
itself to a scrolling resizable GUI window the way well-written HTML does.

What's needed for this?  A layout manager that constantly recalculates 
what should be in the screen as the text it's laying out changes.  And an 
editor-interface to that layout manager that does the usual editor 
commands as applied to the non-laid-out source code.

Well, actually, we should accept that a document is a data structure.  A 
data structure that's traditionally represented mapped onto a long string 
of characters, or as ink in paper in a particular style of arrangement.

It's a data structure just as much as a Lisp program is a data structure, 
traditionally represented either with pointers in RAM or as text with 
lots and lots of parentheses.

The underlying data structure is what we  want to edit.  It needs to have 
a representation that's amenable to revision control.  Possibly  every 
object in the data structure gets a persistent name (maybe a random
64-bit number) and the objects (paragraphs, sentences, chapters, 
etc) refer to each other by these names and the set of objects is written 
out in order, sorted by name.  With lots of newlines.

That should merge properly.

Anybody up for this?  The data structure could be reusable in completely 
different kinds of applications, not just word processing.  It could be 
manipulated with different views, ones "showing codes" as WordPerfect 
used to so, ones that WYSIWYG, whatever.

I don't know if any of this is like what emacs does internally.

I don't know if anyone has built a mergeable object store like this.

-- hendrik

Re: Emacs as word processor

[Hendrik Boom]

On Tue, 26 Nov 2013 11:35:12 +0900, Stephen J. Turnbull wrote:

> Eli Zaretskii writes:
...
...
 
> 
>  > > 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.

What you want might be like kerning, only it's vertical, and done line-by-
line, not character by character.

-- hendrik

Re: Emacs as word processor

[Thien-Thi Nguyen]

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

() Hendrik Boom <hendrik@topoi.pooq.com>
() Mon, 2 Dec 2013 19:30:03 +0000 (UTC)

   The underlying data structure is what we want to edit.
   It needs to have a representation that's amenable to
   revision control.  [...]  With lots of newlines.

   That should merge properly.

   Anybody up for this?

Check out the .ixin files in:

 http://www.gnuvola.org/software/ixin/ixin-1.8.tar.xz

Then, ask yourself: Do you want to edit .ixin directly?
Why, or why not?  (See also c/spit.el in that tarball.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs as word processor

[René Kyllingstad]

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

On Mon, Dec 2, 2013 at 8:30 PM, Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> On Sun, 17 Nov 2013 02:28:51 -0500, Richard Stallman wrote:
>
> > 25 years ago I hoped we would extend Emacs to do WYSIWG word processing.
> >  That is why we added text properties and variable width fonts.
> > However, more features are still needed to achieve this.
> >
> > Could people please start working on the features that are needed?
>
> I've introduced minimal mark-up, so that I can specify italics and such
> when I need them.  And I wrote a program to convert the (almost) plain-
> text to .fodt so I can feed it into LibreOffice for a nice printout.
>
> Maybe I should just have used asciidoc or markdown.  But when I  started
> on this stuff I didn't know about those tools, and maybe the didn't exist
> yet.
>

​What about making some version of markdown the storage format?

On read Emacs converts the markdown to text properties. On save it's
converted to markdown.

​Seems like this could be made to work well enough for simple documents,
and would be more pleasant to look at than the markdown.

One could either type the markdown and have it update on the fly, or use
commands to switch to italic, insert bullet point, change bullet style,
right-align, etc.

This would only support the style way of editing, not directly setting font
properties of some text. Configuring the style is done with customize-face,
and any improvements to that would benefit the rest of Emacs.

Having reflow to a specific paper size could be an orthogonal feature,
turned on and off for this or other modes. It might be nice to edit the
first draft with reflow to the current window size, and then turn on paper
size and margins when getting ready to print.

This does not at all attack the fundamental problem of layout in Emacs,
which means it would be relatively simple to implement.


-- René

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

Re: Emacs as word processor

[Jambunathan K]

René Kyllingstad <Rene@Kyllingstad.com> writes:

> ​What about making some version of markdown the storage format?

I suppose you aren't a Org-mode user or you feel that markdown is
superior (for what values of superior?) to Org-mode.

Org-mode, is the de-facto markup format for Emacs users.  Emacs has
rst.el.  Vanilla Emacs doesn't have font-lock support for markdown.  So
the existing support infrastructure surrouding Org-mode markup is much
far ahead of markdown.

ps: I am not opposed to markdown code.  Given a choice, Org-mode should
get priority treatment.

Re: Emacs as word processor

[T.V. Raman]

In the long run, I believe all of markdown, org, rst and any
other form of text files with some level of embedded markup will
 survive the test of time in the following sense:

1. Content created using these will survive and be usable 20
years from now even if those specific processors disappear.

I fail  to hold the same confidence about word-processor formats,
even if those choose XML  as a serialization -- though at one
point I hoped that XML  would indeed  help move that ball
forward.

See this article
"Fancy Color Paper Universe"
http://emacspeak.sourceforge.net/publications/colored-paper.html
(it's only 2 pages) thatI wrote  in 2000. Nearly
15 years later, the only post-script I would add is that much to
my disappointment, the Web too has turned into one more fancy
colored piece of paper.
-- 

-- 


On 12/3/13, Jambunathan K <kjambunathan@gmail.com> wrote:
> René Kyllingstad <Rene@Kyllingstad.com> writes:
>
>> What about making some version of markdown the storage format?
>
> I suppose you aren't a Org-mode user or you feel that markdown is
> superior (for what values of superior?) to Org-mode.
>
> Org-mode, is the de-facto markup format for Emacs users.  Emacs has
> rst.el.  Vanilla Emacs doesn't have font-lock support for markdown.  So
> the existing support infrastructure surrouding Org-mode markup is much
> far ahead of markdown.
>
> ps: I am not opposed to markdown code.  Given a choice, Org-mode should
> get priority treatment.
>
>

Re: Emacs as word processor

[Eli Zaretskii]

> Date: Tue, 3 Dec 2013 08:32:33 -0800
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> 
> In the long run, I believe all of markdown, org, rst and any
> other form of text files with some level of embedded markup will
>  survive the test of time in the following sense:
> 
> 1. Content created using these will survive and be usable 20
> years from now even if those specific processors disappear.
> 
> I fail  to hold the same confidence about word-processor formats,
> even if those choose XML  as a serialization -- though at one
> point I hoped that XML  would indeed  help move that ball
> forward.

I don't see why: the Office formats introduced in 1997 are still very
much usable today, 16 years later, even though a new format was
introduced in 2007.

Re: Emacs as word processor

[Andreas Röhler]

Am 03.12.2013 12:36, schrieb Jambunathan K:
> René Kyllingstad <Rene@Kyllingstad.com> writes:
>
>> ​What about making some version of markdown the storage format?
>
> I suppose you aren't a Org-mode user or you feel that markdown is
> superior (for what values of superior?) to Org-mode.
>
> Org-mode, is the de-facto markup format for Emacs users.

What a perfectly ill-guided pretend.

Re: Emacs as word processor

[Juan M. Gonzalez]

Richard Stallman <rms <at> gnu.org> writes:
> 25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing.  That is why we added text properties and variable width
> fonts.  However, more features are still needed to achieve this.
> 
> Could people please start working on the features that are needed?


The following free software, co-funded by the European Union, seems similar
to what is suggested in this thread:

Hallo.js - Editing Markdown in WYSIWYG
http://hallojs.org/demo/markdown/

On this simple but interesting demo, we can click or select anything in the
main text, and a toolbar for bold, headings, etc. appears to edit and format
the text directly (WYSIWYG), instead of the Markdown source, which is
automatically updated at the same time.

An Emacs' optional WYSIWYG frontend or minor mode could offer multiple
markups as configurable or automatic backends, according to the major mode
in use; e.g. markups like Emacs Org, LaTeX, HTML, Markdown, etc.

There are some first steps in Emacs in this direction, already mentioned in
this thread, like the old minor mode enriched-mode (with text/enriched as
underlying markup), etc.:

http://www.emacswiki.org/EnrichedMode
http://www.gnu.org/software/emacs/manual/html_node/emacs/Enriched-Mode.html
http://www.opensource.apple.com/source/emacs/emacs-92/emacs/lisp/facemenu.el
http://www.emacswiki.org/FaceMenuPlus
http://www.emacswiki.org/HighlightLibrary

(See also the Emacs menu Edit > Text Properties).

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> I am not sure.  It seems to require a LOT of time.

Starting with basic outlining should get you started.

Create a file test.org.

In test.org type

* First item

Then type M-RET and you get something like this

* First item
* 

with the cursor positoned after the second "*".  
Type "Subitem" (without the quotes).
Then do M-Rightarrow and you get this

* First item
** Subitem

Then just fill in some sample text, like eg. this.

* First item

This is /italics/ and this is *bold*.

And this is a simple command line example:
: ls -al

** Subitem

Need some text down here as well.

Then do `C-c C-e h RET' and your sample document should pop up in HTML
formatted form in a web browser.

Now you can try using TAB to open and close items (the lines with "*" at
the left), and using M-rightarrow and M-leftarrow to move items up and
down in the hierarchy.

You can use M-uparrow and M-downarrow to move items and their children
up and down in the document.

Once the basics is in your fingers it's possible to explore the rest.

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:


>     RMS: You said you wished for Emacs features using LibreOffice.  What
>     kind of document were you editing?  Which features did you miss?  How
>     did you work around their lack?  (Please be specific.)

> It was stallman.org/ebooks.pdf.  Not very complicated.  I wish I could
> specify fonts in Emacs in a way that would really be useful in
> making such a document.

Hum... below follows ebooks.org (an org-mode translation of that
document). I use visual-line-mode in org-mode, which is why you see the
long lines. The text could just as easily be formatted with wrapping at
79 columns (or whatever).

Load ebooks.org a garden variety emacs, and try various exports (`C-c C-e'
followed by an appropriate export, you will be prompted).

Also, M-RET and M-arrow works for me for adding items to the items lists
and moving items around, and changing the item levels. But that was a
non-standard setting, and I can't remember which one.

I don't know how to change the fonts in the exports from the default,
I've never felt I needed to, but I'm sure others will jump in to say
how.

---8<-8<-8<-------ebooks.org---
* The Danger of Ebooks

In an age where business dominates our governments and writes our laws, every technological advance offers business an opportunity to impose new restrictions on the public. Technologies that could have empowered us are used to chain us instead.

With printed books,
 - You can buy one with cash, anonymously.
 - Then you own it.
 - You are not required to sign a license that restricts your use of it.
 - The format is known, and no proprietary technology is needed to read the book.
 - You can give, lend or sell the book to another.
 - You can, physically, scan and copy the book, and it's sometimes lawful under copyright.
 - Nobody has the power to destroy your book.

Contrast that with Amazon ebooks (fairly typical):
 - Amazon requires users to identify themselves to get an ebook.
 - In some countries, including the US, Amazon says the user cannot own the ebook.
 - Amazon requires the user to accept a restrictive license on use of the ebook.
 - The format is secret, and only proprietary user-restricting software can read it at all.
 - An ersatz “lending” is allowed for some books, for a limited time, but only by specifying by name another user of the same system. No giving or selling.
 - To copy the ebook is impossible due to Digital Restrictions Management in the player. and prohibited by the license, which is more restrictive than copyright law.
 - Amazon can remotely delete the ebook using a back door. It used this back door in 2009 to delete thousands of copies of George Orwell's 1984.

Even one of these infringements makes these ebooks a step backward from printed books. We must reject ebooks that damage our freedom.

The ebook companies say denying our traditional freedoms is necessary to continue to pay
authors. The current copyright system supports those companies handsomely, and most authors
badly. We can support authors better in other ways that don't require curtailing our freedom, and
even legalize sharing. Two methods I've suggested are:
 - To distribute tax funds to authors based on the cube root of each author's popularity. (See http://stallman.org/articles/internet-sharing-license.en.html.)
 - To design players so users can send authors anonymous voluntary payments.

Ebooks don't have to attack our freedom (Project Gutenberg's ebooks don't), but they will if companies get to decide. It's up to us to stop them.

*Join our cause: sign up at* http://DefectiveByDesign.org/ebooks.html

URL of this handout: http://stallman.org/articles/ebooks.pdf

Copyright 2011, 2012 Richard Stallman
Released under Creative Commons Attribution 3.0.

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> Lisp is one of the benefits of Emacs that I wish I had when doing
> WYSIWIG word processing.  To abandon that would defeat the whole point
> of this.

FWIW I really would have liked to see an s-expression based text
document file format see actual use.

Re: Emacs as word processor

[Stephen J. Turnbull]

Steinar Bang writes:

 > FWIW I really would have liked to see an s-expression based text
 > document file format see actual use.

XML! <duck />

Re: Emacs as word processor

[T.V. Raman]

I spent about 6 years (2000 -- 2006) investing in XMl  hoping
that it would give us s-expressions -- sadly it gave everything
but.

To me the living proof  of this is  that in 2013, I write org
files by hand -- in 2001 when I was still dreaming the xml will
give us s-expressions dream, I wrote xml and html by hand - the
zenith was nxml-mode -- but though nxml-mode is a marvellous
piece of work, xml dragged in far too much of the old sgml
baggage, without bringing much new to the party --
-- 

-- 


On 12/15/13, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Steinar Bang writes:
>
>  > FWIW I really would have liked to see an s-expression based text
>  > document file format see actual use.
>
> XML! <duck />
>
>
>
>

Re: Emacs as word processor

[Juan M. Gonzalez]

T.V. Raman <tv.raman.tv <at> gmail.com> writes:
> 
> I spent about 6 years (2000 -- 2006) investing in XMl  hoping
> that it would give us s-expressions -- sadly it gave everything
> but.
> 
> To me the living proof  of this is  that in 2013, I write org
> files by hand -- in 2001 when I was still dreaming the xml will
> give us s-expressions dream, I wrote xml and html by hand - the
> zenith was nxml-mode -- but though nxml-mode is a marvellous
> piece of work, xml dragged in far too much of the old sgml
> baggage, without bringing much new to the party --
> 
> -- 
> 
> On 12/15/13, Stephen J. Turnbull <stephen <at> xemacs.org> wrote:
> > Steinar Bang writes:
> >
> > > FWIW I really would have liked to see an s-expression based text
> > > document file format see actual use.
> >
> > XML! <duck />


About those possibilities, Richard Stallman has been asked, in this thread,
"1. What would you recommend as the backend format?" His answer:

"It would be good to support several, including some use of HTML, ODF, and
maybe Texinfo."

http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00557.html
http://article.gmane.org/gmane.emacs.devel/165333

And also about the Org-mode markup as storage format:

"I am sure that it will support this format, because that's not the
hard part."

http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg01138.html
http://article.gmane.org/gmane.emacs.devel/165914

That's reasonable. If we look at LibreOffice Writer, that RMS has mentioned
as an example, it can save in a good number of different formats: .odt,
.txt, .html, .xml, etc.

And about the compatibility between formats? Let's say we have a document in
a format that allows embedded LaTeX for math formulae, etc., like Org markup
or the latest MultiMarkdown, and we want to save it in a more limited format
such as plain Markdown. That's solved by LibreOffice in a simple way, with a
warning: "This document may contain formatting or content that cannot be
saved in the currently selected file format". However, it lets us go ahead,
and saves what is supported in the format chosen by the user.

So it seems an optional minor WYSIWYG mode that could be used by Emacs major
modes, and which would allow a number of different formats, is a suggested
way. Especially for text markups already supported by Emacs and its
different major modes.

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Load ebooks.org a garden variety emacs, and try various exports (`C-c C-e'
    followed by an appropriate export, you will be prompted).

I did that, and it showed me only the first line.
I don't know what to do next.

I think the problem is that it is trying to treat the file as an
outline.  However, this is not an outline.  It is a document with a
title and some lists of bullet points.

Maybe a modified version of Org mode would handle this just fine,
but the modification needs to be done -- not just possible -- and it
needs to be the default for this sort of document.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Jambunathan K]

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

Richard Stallman <rms@gnu.org> writes:

> Maybe a modified version of Org mode would handle this just fine

I am attaching a sample Org file and a OpenDocument export of it.

If you are using Emacs from bzr repo then,

(custom-set-variables
 '(org-export-backends (quote (ascii html icalendar latex odt org)))
 '(org-latex-pdf-process
   (quote
    ("pdflatex -interaction nonstopmode -output-directory %o %f" "bibtex %b" "pdflatex -interaction nonstopmode -output-directory %o %f" "pdflatex -interaction nonstopmode -output-directory %o %f"))))

Use the following commands

    C-x C-f ebooks.org
    C-c C-e h h (for HTML)
    C-c C-e o o (for ODT)
    C-c C-e l o (for LaTeX -> PDF)

Hint: Pause after C-c C-e.  See the header line.  Chars between [x] are
active keys.


[-- Attachment #2: ebooks.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 11851 bytes --]

[-- Attachment #3: ebooks.org --]
[-- Type: text/x-org, Size: 3260 bytes --]

#+TITLE: The Danger Of Ebooks
#+DATE: 2013-12-16 Mon
#+AUTHOR: Richard Stallman
#+EMAIL: rms@gnu.org
#+OPTIONS: ':nil *:t -:nil ::t <:t H:3 \n:nil ^:t arch:headline
#+OPTIONS: author:t c:nil creator:comment d:(not "LOGBOOK") date:t
#+OPTIONS: e:t email:nil f:t inline:t num:nil p:nil pri:nil prop:nil
#+OPTIONS: stat:t tags:t tasks:t tex:t timestamp:t toc:nil todo:t |:t
#+CREATOR: Emacs 24.3.50.3 (Org mode 8.2.4)
#+DESCRIPTION:
#+EXCLUDE_TAGS: noexport
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export

* The Danger of Ebooks

In an age where business dominates our governments and writes our
laws, every technological advance offers business an opportunity to
impose new restrictions on the public. Technologies that could have
empowered us are used to chain us instead.

With printed books,
 - You can buy one with cash, anonymously.
 - Then you own it.
 - You are not required to sign a license that restricts your use of
   it.
 - The format is known, and no proprietary technology is needed to
   read the book.
 - You can give, lend or sell the book to another.
 - You can, physically, scan and copy the book, and it's sometimes
   lawful under copyright.
 - Nobody has the power to destroy your book.

Contrast that with Amazon ebooks (fairly typical):
 - Amazon requires users to identify themselves to get an ebook.
 - In some countries, including the US, Amazon says the user cannot
   own the ebook.
 - Amazon requires the user to accept a restrictive license on use of
   the ebook.
 - The format is secret, and only proprietary user-restricting
   software can read it at all.
 - An ersatz “lending” is allowed for some books, for a limited time,
   but only by specifying by name another user of the same system. No
   giving or selling.
 - To copy the ebook is impossible due to Digital Restrictions
   Management in the player. and prohibited by the license, which is
   more restrictive than copyright law.
 - Amazon can remotely delete the ebook using a back door. It used
   this back door in 2009 to delete thousands of copies of George
   Orwell's 1984.

Even one of these infringements makes these ebooks a step backward
from printed books. We must reject ebooks that damage our freedom.

The ebook companies say denying our traditional freedoms is necessary
to continue to pay authors. The current copyright system supports
those companies handsomely, and most authors badly. We can support
authors better in other ways that don't require curtailing our
freedom, and even legalize sharing. Two methods I've suggested are:
 - To distribute tax funds to authors based on the cube root of each
   author's popularity[1]. 
 - To design players so users can send authors anonymous voluntary
   payments.

Ebooks don't have to attack our freedom (Project Gutenberg's ebooks
don't), but they will if companies get to decide. It's up to us to
stop them.

*Join our cause: sign up at* http://DefectiveByDesign.org/ebooks.html

URL of this handout: http://stallman.org/articles/ebooks.pdf

Copyright 2011, 2012 Richard Stallman \\
Released under Creative Commons Attribution 3.0.

* Footnotes

[1] http://stallman.org/articles/internet-sharing-license.en.html

Re: Emacs as word processor

[Allen S. Rout]

On 12/16/2013 12:19 PM, Richard Stallman wrote:

> 
> I think the problem is that it is trying to treat the file as an
> outline.  However, this is not an outline.  It is a document with a
> title and some lists of bullet points.
> 


It is a structured document. Some people would choose to _view_ it as an
outline. Others would choose to view as a block of pretty text, and yet
others would choose to view as a pile of plaintext with markup displayed
verbatim instead of interpreted.

So to attract "the type of users we're discussing here", the correct
paint job on the Org toolset would be org-mode and a stylized set of
startup variables, which defaulted to an expanded, pretty-printed display.

Does that sound reasonable?

Most importantly, it is an error to decide that this new use for the org
toolset is, all of a sudden, The Correct Interpretation Of Documents.


If we're going to deploy a swiss-army chainsaw for this, we've got the
"blind men and the elephant" problem writ pretty large.

http://en.wikipedia.org/wiki/Blind_men_and_an_elephant


- Allen S. Rout
- The Blind Men and the Chainsaw.... Hmmm.

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> I did that, and it showed me only the first line.
> I don't know what to do next.

TAB will expand it.

C-c C-e will start export to several formats. You should be presented
with alternatives. `h' is "html", `h' followed by a RET should open the
document in HTML form in a web browser.

> I think the problem is that it is trying to treat the file as an
> outline.  However, this is not an outline.  It is a document with a
> title and some lists of bullet points.

org-mode behaves like outline mode on steroids. TAB will show you the
entire document.

Re: Emacs as word processor

[Juan M. Gonzalez]

Richard Stallman <rms <at> gnu.org> writes:
> 
> I did that, and it showed me only the first line.


Yes, it's folded by default. One of the first customizations I did when
starting to use Org-mode was to change this behavior, since I use more
documents than outlines.

In the ~/.emacs init file:

;; No folding of any entries
(setq org-startup-folded "showall")

And then, when I wish, I can fold/unfold part or all with <tab> (visibility
cycling) or <S-tab> (global visibility cycling).

Another useful Org customization is:

;; Cleaner view
(setq org-startup-indented t)
(global-set-key (kbd "<f7>") 'org-indent-mode)

Etc...

Apart from this, I can say that Emacs Org is being indeed useful for me, and
for many others from what I've seen.

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    It is a structured document. Some people would choose to _view_ it as an
    outline.

MY document is text with a title, containing some lists with bullet
points.

Apparently your file is a structured document, which Org mode shows
_by default_ as an outline.

So they are considerably different.

Maybe some people would choose to view my document as an outline.  Who
knows?  It makes no sense, but if someone really wants to do it, I
will not object.

But showing my document as an outline by default is a bug.
It should appear as text with a title.  Tnat's how OpenOffice
shows it.

If you suggest representing my document as a certain file,
but Org mode's default handing of that file is to display an outline,
it follows that that file in Org mode doesn't properly represent my document.

Maybe some other different file in Org mode would properly represent
my document.

If not, maybe Org mode could use a change so that some file
would properly represent my document.

     Others would choose to view as a block of pretty text,

Org mode did not tell me how to choose anything but the outline.
Maybe there is a way to do it, but it did not tell me.

Anyway, if the document is meant to be text with a title,
it should be saved as a file which will appear, by default,
as text with a title.

    Most importantly, it is an error to decide that this new use for the org
    toolset is, all of a sudden, The Correct Interpretation Of Documents.

You lost me there.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I did that, and it showed me only the first line.
    > I don't know what to do next.

    TAB will expand it.

Indeed it does.  But it didn't tell me to type TAB.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Yes, it's folded by default. One of the first customizations I did when
    starting to use Org-mode was to change this behavior, since I use more
    documents than outlines.

Is it the case that Org mode applies one single policy to all documents,
and the user can choose which policy that is?

If so, maybe it should not do so.  Maybe the state of folding should be
saved in the file, so that when the file is read in again,
it will be folded or unfolded the same as when it was viewed before.

Or maybe the default should be "Initially totally unfolded".

Or maybe text documents should be distinguished from outlines.
An outline could be initially displayed folded, and a text document
could be initially displayed unfolded.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> But showing my document as an outline by default is a bug.

It's not a bug for org-mode.  It's the way it's supposed to be.

But when you opened it, you would see a couple of itemized lists and
also some bold face, in what's actually the org-mode markup.

> It should appear as text with a title.  Tnat's how OpenOffice
> shows it.

I think the reason so many people have been pushing org-mode, is that
they themselves use org-mode for the use case you have listed: create a
text document, formatted like an OpenOffice writer document would have
formatted it (that's what I would have used. Quickly outlined a document
and then exported it to the desired format).

And the people pushing org-mode in this thread don't care about having a
WYSWIG presentation of the result document when editing the document.

I know I don't care, the expected result is in my head as I type, and
the actual result rarely surprise me. Probably since the org-mode markup
is so simple.

Re: Emacs as word processor

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> Or maybe the default should be "Initially totally unfolded".

Others have suggested that as well.

As a longtime org user, I have no strong opinions either way.

Re: Emacs as word processor

[Achim Gratz]

Richard Stallman writes:
> Is it the case that Org mode applies one single policy to all documents,
> and the user can choose which policy that is?

Like many modes, there is a default policy which is controlled by the
custom variable org-startup-folded in this case.  The default can be
overruled on a per-file basis by either adding KEYWORDS to the file
(#+STARTUP: showeverything) or visibility PROPERTIES to a (sub-)tree.

> If so, maybe it should not do so.  Maybe the state of folding should be
> saved in the file, so that when the file is read in again,
> it will be folded or unfolded the same as when it was viewed before.

In the absence of such information it has to fall back on the default,
however.

> Or maybe the default should be "Initially totally unfolded".

A mode derived from Org would perhaps need to chose different defaults,
but for Org the default of folding the outline is appropriate.

> Or maybe text documents should be distinguished from outlines.
> An outline could be initially displayed folded, and a text document
> could be initially displayed unfolded.

To Org everything is an outline, it doesn't make a distinction between
outline and text.

To me it seems the discussion about Org has somehow drifted from the
original request in this thread.  Org has been mentioned as a format
that Emacs already understands and can produce different output formats
from.  It is not, in its current form, intended to do WYSIWYG editing
even though it might arguably form the basis for such a mode.  Even
then, some of the things that people often do with WYSIWYG are even
difficult to map to Org's syntax, which is geared towards making the
common things easy without introducing a lot of clutter.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Emacs as word processor

[Steinar Bang]

>>>>> Achim Gratz <Stromeko@nexgo.de>:

> To me it seems the discussion about Org has somehow drifted from the
> original request in this thread.  Org has been mentioned as a format
> that Emacs already understands and can produce different output formats
> from.  It is not, in its current form, intended to do WYSIWYG editing
> even though it might arguably form the basis for such a mode.  Even
> then, some of the things that people often do with WYSIWYG are even
> difficult to map to Org's syntax, which is geared towards making the
> common things easy without introducing a lot of clutter.

Agreed.

What prompted me to mention org mode, is that org mode is the way I
quickly create documents like RMS' sample pdf file.

I whip up a small .org file, fill it with content, and export it to the
desired format, and that's that.

So I overlooked the WYSWIG bit of the request since it's not something I
need, or even want, for the "small, nicely formatted PDFs, quickly
created" use case.

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > If so, maybe it should not do so.  Maybe the state of folding should be
    > saved in the file, so that when the file is read in again,
    > it will be folded or unfolded the same as when it was viewed before.

    In the absence of such information it has to fall back on the default,
    however.

    > Or maybe the default should be "Initially totally unfolded".

    A mode derived from Org would perhaps need to chose different defaults,
    but for Org the default of folding the outline is appropriate.

For outlines, the default might be appropriate.
It follows that Org mode, as such, is not right for documents such as this.

Telling the users, "Customize Org mode yourself" is unhelpful.

Providing a derived mode with different defaults might be helpful.

    To me it seems the discussion about Org has somehow drifted from the
    original request in this thread.  Org has been mentioned as a format
    that Emacs already understands and can produce different output formats
    from.  It is not, in its current form, intended to do WYSIWYG editing
    even though it might arguably form the basis for such a mode.

I agree.  I'm considering Org mode as a way to edit formatted documents,
which might be better than Text mode even though not WYSIWYG.

But it needs minor changes to be good for this purpose.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> For outlines, the default might be appropriate.
> It follows that Org mode, as such, is not right for documents such as this.

As Achim explained, a document like this one is displayed with all its
parts completely visible:

========================================================================
#+STARTUP: showeverything

* A section

Some text.
========================================================================

> Telling the users, "Customize Org mode yourself" is unhelpful.

This is not about customizing Org mode.

This is about specifying *within* your document whether it should be
read as a text or as an outline.

Org mode is primarily used as a tool to manage lists of tasks, with
notes possibly attached to the tasks.  In this case, displaying the
document as an outline is useful.

Org mode is also used as a tool to write documents.

If this is your use case and if you don't want people to see
the document as an outline, inserting #+STARTUP: showeverything
at the beginning of it is the way to go.

> But it needs minor changes to be good for this purpose.

I guess users would find the default folding behavior more useful
than a default "showeverything" behavior -- but I might be wrong.

If you have other ideas on how to improve Org mode, please share.

Thanks!

-- 
 Bastien

Re: Emacs as word processor

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    This is about specifying *within* your document whether it should be
    read as a text or as an outline.

I see.

Having it in the file is the right thing, but I think there should
be a variant of Org mode that initializes the file this way.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as word processor

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Having it in the file is the right thing, but I think there should
> be a variant of Org mode that initializes the file this way.

This variant already exists.

You can load it by adding this line in your .emacs:

  (setq org-startup-folded 'showeverything)

-- 
 Bastien

Re: Emacs as word processor

[Xue Fuqiao]

On Thu, Dec 19, 2013 at 3:28 PM, Bastien <bzg@gnu.org> wrote:
> I guess users would find the default folding behavior more useful
> than a default "showeverything" behavior.

+1

I like maintaining several large .org files instead of a lot of large
files because I can conveniently use isearch to find the stuff I want to
see/modify without switching the buffer(s).

-- 
http://www.gnu.org/software/emacs/