Re: Emacs as a word processor

Re: Emacs as a word processor

[Pedro Andres Aranda Gutierrez]

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

No, please!!
I don't want to waist CPU cycles in making things look as I want. Mainly
because I trust LaTEX to do that. Even against colleagues. The only thing I
need when writing is a spellchecker (flyspell) and a nice snippet
combination for the more complex "quirks" in LaTEX (using yasnippet).
Everything else is distraction. I concur with people pointing out that ORG
makes a nice combination with LaTEX (I scarcely ever use Beamer directly
for lectures, org-mode is perfect for that).
In some sense, this is back to the origins, using venerable WordStar for
text-processing and programming. And yes, if you need some sense of
WYSIWYH2G
(H2G=hope to get) then use any of the programs mentioned in the thread

Best wishes for 2021,
My .02 cents
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: Emacs as a word processor

[Christopher Dimech]

[-- Attachment #1: Type: text/html, Size: 1990 bytes --]

Emacs as a word processor

[James Lu]

WYSIWYG editors are popular among normal people. Emacs as word
processor will expand the reach of Emacs, and thus software freedom
too.

________________________________
From:Richard Stallman
Subject:Emacs as word processor
Date:Sun, 17 Nov 2013 02:28:51 -0500
________________________________

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.

Emacs as a word processor

[Gregory Heytings via Emacs development discussions.]

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


Daniel Martín:
>>> I've been trying for more than 10 years to urge people to work toward 
>>> giving Emacs the document capabilities of a word processor, but I have 
>>> not convinced people to do this work.
>>
>> What do you mean by this?  I'm probably biased, but I don't see what 
>> important "capability of a word processor" is lacking in Emacs.
>
> Something that works like LibreOffice, where you can write a document, 
> select parts of it, mark them in bold, justify them, etc.  All of that 
> while you see the results in a WYSIWYG fashion.  The closest thing there 
> is now is enriched-mode, but that mode does not offer the same level of 
> features as LibreOffice.
> 
> There is more context about this potential new feature in /etc/TODO 
> under the section "Emacs as a word processor".
>

Eli Zaretskii:
> The WYSIWYG part is missing.  See the etc/TODO entry about that for a 
> pointer to a discussion about this.
>

Yes, I know about that entry in etc/TODO, in which RMS expresses the same 
wish.  I've read the discussion again, and it's still not clear at all to 
me what features are really missing.  I'm not sure characterizing them 
under the acronym WYSIWYG or referring to LibreOffice is more precise.

My impression (but I could very well be wrong) is that what RMS would like 
to have is not a truly WYSIWYG word processor that would compete with 
LibreOffice, but something simpler.  And that a detailed list of features 
would make that TODO entry more concrete.  Hence my question.

An attempt to list features a user could expect from a word processor :

[ ] import / export Microsoft Word files
[ ] import / export Open Document Format (.odt) files
[ ] import / export RTF files
[ ] export to a PDF file
[ ] select a font and its size
[ ] apply a bold / italic / underline / strikethrough effect
[ ] superscripts / subscripts
[ ] apply a left / center / right / justified effect
[ ] change the font color and the background color
[ ] create a list
[ ] insert and change a table
[ ] insert a picture
[ ] define / use / modify styles
[ ] print preview / print
[ ] use footnotes
[ ] multiple columns
[ ] change page headers and footers

Re: Emacs as a word processor

[Eli Zaretskii]

> Date: Tue, 22 Dec 2020 18:22:00 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: emacs-devel@gnu.org
> 
> [ ] import / export Microsoft Word files
> [ ] import / export Open Document Format (.odt) files
> [ ] import / export RTF files
> [ ] export to a PDF file
> [ ] select a font and its size
> [ ] apply a bold / italic / underline / strikethrough effect
> [ ] superscripts / subscripts
> [ ] apply a left / center / right / justified effect
> [ ] change the font color and the background color
> [ ] create a list
> [ ] insert and change a table
> [ ] insert a picture
> [ ] define / use / modify styles
> [ ] print preview / print
> [ ] use footnotes
> [ ] multiple columns
> [ ] change page headers and footers

All of them, I guess.  Plus pixelwise text-fill and justification.
And sectioning commands.

Re: Emacs as a word processor

[Eli Zaretskii]

> Date: Tue, 22 Dec 2020 20:39:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, rms@gnu.org, mardani29@yahoo.es
> 
> > [ ] import / export Microsoft Word files
> > [ ] import / export Open Document Format (.odt) files
> > [ ] import / export RTF files
> > [ ] export to a PDF file
> > [ ] select a font and its size
> > [ ] apply a bold / italic / underline / strikethrough effect
> > [ ] superscripts / subscripts
> > [ ] apply a left / center / right / justified effect
> > [ ] change the font color and the background color
> > [ ] create a list
> > [ ] insert and change a table
> > [ ] insert a picture
> > [ ] define / use / modify styles
> > [ ] print preview / print
> > [ ] use footnotes
> > [ ] multiple columns
> > [ ] change page headers and footers
> 
> All of them, I guess.  Plus pixelwise text-fill and justification.
> And sectioning commands.

And pixel-level indentation (so that one could use variable-pitch
fonts).

Re: Emacs as a word processor

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> And pixel-level indentation (so that one could use variable-pitch
> fonts).

In short, write a brand new Emacs display layer.  I would suggest
starting this endeavour by first re-writing Emacs as an Electron
application.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs as a word processor

[Stefan Monnier]

> In short, write a brand new Emacs display layer.  I would suggest
> starting this endeavour by first re-writing Emacs as an Electron
> application.

Emajs!


        Stefan

Re: Emacs as a word processor

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 22 Dec 2020 20:37:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And pixel-level indentation (so that one could use variable-pitch
> > fonts).
> 
> In short, write a brand new Emacs display layer.

Our existing display engine already supports that, via the :align-to
and :width display properties.

Re: Emacs as a word processor

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-12-22 21:22]:
> An attempt to list features a user could expect from a word processor :
> 
> [ ] import / export Microsoft Word files

I would not include any inter-operability with proprietary formats. I
do not find Microsoft Word as prime example of a word processor, there
are so many others before Microsoft Word and after. I am sure you know
it, but for clarification: word processor does not mean and is not
equal to Microsoft Word. The word "word" does not related to Microsoft
Word.

Also see: https://en.wikipedia.org/wiki/Word_processor as the term
need not mean something today what it meant before.

As it says on Wikipedia:

"A word processor (WP) is a device or computer program that provides
for input, editing, formatting and output of text, often with some
additional features."

If somebody asks me, in GNU project we have already GNU TeXmacs which
is not Emacs, but is a word processor with pretty good WYSIWYG
interface: https://www.texmacs.org/tmweb/home/welcome.en.html in terms
that user may get pretty visual representation of the formatting on
the screen. It is extensible by using scheme.

In my opinion Emacs could be word processor in a simple manner,
without WYSIWIG if the text properties such as formatting, could be
interpreted for good output such as PDF. This is quite possible in my
opinion. It need not have variety of True Type fonts on the screen. I
am sure pictures can be inserted. It all could be then saved and
become exportable to various other formats.

Org mode already does that. It allows for basic text formatting and
export. In that sense Emacs is already word processor.

> [ ] import / export Open Document Format (.odt) files

I would say yes.

> [ ] import / export RTF files

Definitely no need as it is proprietary format that is today rarely
used anyway.

> [ ] export to a PDF file

Yes.

> [ ] select a font and its size

Even if font is selected without WYSIWYG, that it may be previewed in
a separate Emacs window or frame or in external PDF viewer, if there
is True Type and other font selection and formatting, I guess it would
make Emacs a word processor. Even if the text would not be visually
shown as output on the paper.

> [ ] apply a bold / italic / underline / strikethrough effect
> [ ] superscripts / subscripts
> [ ] apply a left / center / right / justified effect
> [ ] change the font color and the background color
> [ ] create a list
> [ ] insert and change a table
> [ ] insert a picture
> [ ] define / use / modify styles
> [ ] print preview / print
> [ ] use footnotes
> [ ] multiple columns
> [ ] change page headers and footers

Yes, yes and yes. And all that is already supported and provided in
the beautiful GNU project named TeXmacs:
https://www.texmacs.org/tmweb/home/welcome.en.html


Jean

Re: Emacs as a word processor

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

>> [ ] apply a bold / italic / underline / strikethrough effect
>> [ ] superscripts / subscripts
>> [ ] apply a left / center / right / justified effect
>> [ ] change the font color and the background color
>> [ ] create a list
>> [ ] insert and change a table
>> [ ] insert a picture
>> [ ] define / use / modify styles
>> [ ] print preview / print
>> [ ] use footnotes
>> [ ] multiple columns
>> [ ] change page headers and footers
>
> Yes, yes and yes. And all that is already supported and provided in
> the beautiful GNU project named TeXmacs:
> https://www.texmacs.org/tmweb/home/welcome.en.html
>
Isn't it also all provided in LibreOffice, KOffice, Abi Word and
probably 1000 other applications? :-)

What is the point of saying it is provided in application X?

Re: Emacs as a word processor

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-12-22 22:41]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> [ ] apply a bold / italic / underline / strikethrough effect
> >> [ ] superscripts / subscripts
> >> [ ] apply a left / center / right / justified effect
> >> [ ] change the font color and the background color
> >> [ ] create a list
> >> [ ] insert and change a table
> >> [ ] insert a picture
> >> [ ] define / use / modify styles
> >> [ ] print preview / print
> >> [ ] use footnotes
> >> [ ] multiple columns
> >> [ ] change page headers and footers
> >
> > Yes, yes and yes. And all that is already supported and provided in
> > the beautiful GNU project named TeXmacs:
> > https://www.texmacs.org/tmweb/home/welcome.en.html
> >
> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
> probably 1000 other applications? :-)
> 
> What is the point of saying it is provided in application X?

Because it is GNU project.

Re: Emacs as a word processor

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-12-22 22:41]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> >> [ ] apply a bold / italic / underline / strikethrough effect
>> >> [ ] superscripts / subscripts
>> >> [ ] apply a left / center / right / justified effect
>> >> [ ] change the font color and the background color
>> >> [ ] create a list
>> >> [ ] insert and change a table
>> >> [ ] insert a picture
>> >> [ ] define / use / modify styles
>> >> [ ] print preview / print
>> >> [ ] use footnotes
>> >> [ ] multiple columns
>> >> [ ] change page headers and footers
>> >
>> > Yes, yes and yes. And all that is already supported and provided in
>> > the beautiful GNU project named TeXmacs:
>> > https://www.texmacs.org/tmweb/home/welcome.en.html
>> >
>> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
>> probably 1000 other applications? :-)
>> 
>> What is the point of saying it is provided in application X?
>
> Because it is GNU project.

Ok :-).

So we can switch all to texmacs? Does it syntax highlight C/C++ and run
Helm? :-)

Re: Emacs as a word processor

[Qiantan Hong]

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

I like the idea of TeXMacs, especially using a tree (like DOM)
instead of sequential array.
I think DOM tree is the right way to make a word processor.
One example that sequential array doesn’t do well
is wrapping text around a figure, or two column text inside
a one column document.
There’s more example about other kind of layout.

However there’s so many things in Emacs that won’t run
on TeXMacs.
Maybe we could wait for guile-emacs and then write
some wrapper in scheme to run Emacs packages on TeXMacs?

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Emacs as a word processor

[Arthur Miller]

Qiantan Hong <qhong@mit.edu> writes:

> I like the idea of TeXMacs, especially using a tree (like DOM)
> instead of sequential array.
> I think DOM tree is the right way to make a word processor.
> One example that sequential array doesn’t do well
> is wrapping text around a figure, or two column text inside
> a one column document.
> There’s more example about other kind of layout.
>
> However there’s so many things in Emacs that won’t run
> on TeXMacs.
> Maybe we could wait for guile-emacs and then write
Guile-emacs still comming? :-)

Re: Emacs as a word processor

[Gregory Heytings via Emacs development discussions.]

Thanks to all for your reactions.  Just to be clear, I do not need and 
would not use any of those features myself.  But I would like to 
understand / clarify what RMS wants.  So here is the list again, with 
checkboxes:

[ ] import / export Microsoft Word files
[ ] import / export Open Document Format (.odt) files
[ ] import / export RTF files
[ ] export to a PDF file
[ ] select a font and its size
[ ] apply a bold / italic / underline / strikethrough effect
[ ] use superscripts / subscripts
[ ] apply a left / center / right / justified effect
[ ] apply pixel-level fill / justification / indentation effects
[ ] change the font color and the background color
[ ] create / edit lists (with numbers / letters / bullets)
[ ] insert and change tables
[ ] insert pictures
[ ] define / use / modify styles
[ ] print preview / print
[ ] use footnotes
[ ] use multiple columns
[ ] change page headers and footers
[ ] operate on sections

Richard?

Re: Emacs as a 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. ]]]

  > [ ] import / export Microsoft Word files

Not crucial in my opinion, since I say we should refuse to look at or
create Word files.  See https://gnu.org/philosophy/no-word-attachments.html.

But I think lots of users would want this feature.

  > [ ] import / export Open Document Format (.odt) files

Very important.

  > [ ] import / export RTF files

Nice but not crucial

  > [ ] export to a PDF file

Very important.

The rest are all formatting features.  The program could start to be
useful with only some of these, but all of them are important.

  > [ ] select a font and its size
  > [ ] apply a bold / italic / underline / strikethrough effect
  > [ ] use superscripts / subscripts
  > [ ] apply a left / center / right / justified effect
  > [ ] apply pixel-level fill / justification / indentation effects
  > [ ] change the font color and the background color
  > [ ] create / edit lists (with numbers / letters / bullets)
  > [ ] insert and change tables
  > [ ] insert pictures
  > [ ] define / use / modify styles
  > [ ] print preview / print
  > [ ] use footnotes
  > [ ] use multiple columns
  > [ ] change page headers and footers
  > [ ] operate on sections

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[chad]

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

A few years ago, I moved from programming to a creative/prose-based career
where I interact almost exclusively with people who use computers as
mostly-replaceable appliances. In this world, interop with MS Word is a
baseline assumption. In my experience, there are many fields that share
this characteristic.

If Emacs wants to be usable for people living in this world, it's not
necessary that Emacs supports all of the various features of doc, docx, or
odt files, but it is necessary that files not be corrupted (to use
Richard's term) by passing through Emacs. Several years ago I cobbled
together a partial solution that used a set of external (Java-based)
converters, but it proved to be fragile and eventually bit-rotted. I
believe that system was based on the idea that the XML-based doc variants
would end up being more open (not free, but published specs) than they
actually were.

From my experience, the next-most important feature for interop is support
for "track changes", as its use is standard practice in many fields, and
anything that doesn't support it is not workable. When last I looked, the
details here were never published by MS, and would need to be
reverse-engineered.

I hope this helps,
~Chad

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

Re: Emacs as a 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'm not going to fight against support for Word files.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[David Masterson]

Arthur Miller <arthur.miller@live.com> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> * Arthur Miller <arthur.miller@live.com> [2020-12-22 22:41]:
>>> Jean Louis <bugs@gnu.support> writes:
>>> 
>>> >> [ ] apply a bold / italic / underline / strikethrough effect
>>> >> [ ] superscripts / subscripts
>>> >> [ ] apply a left / center / right / justified effect
>>> >> [ ] change the font color and the background color
>>> >> [ ] create a list
>>> >> [ ] insert and change a table
>>> >> [ ] insert a picture
>>> >> [ ] define / use / modify styles
>>> >> [ ] print preview / print
>>> >> [ ] use footnotes
>>> >> [ ] multiple columns
>>> >> [ ] change page headers and footers
>>> >
>>> > Yes, yes and yes. And all that is already supported and provided in
>>> > the beautiful GNU project named TeXmacs:
>>> > https://www.texmacs.org/tmweb/home/welcome.en.html
>>> >
>>> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
>>> probably 1000 other applications? :-)
>>> 
>>> What is the point of saying it is provided in application X?
>>
>> Because it is GNU project.
>
> Ok :-).
>
> So we can switch all to texmacs? Does it syntax highlight C/C++ and run
> Helm? :-)

Perhaps the two can be integrated?  That is a menu entry in Emacs that
would spawn TeXmacs in such a way that TeXmacs would save it's file in
Latex form which could then be imported into Auctex/Emacs?  In other
words, let Emacs do Emacs and TeXmacs do TeXmacs in a way that
communicates well.

-- 
David Masterson

Re: Emacs as a word processor

[Christopher Dimech]

A few years ago I used Texmacs but found in it some serious problems that
could potentially get you to loose your work, ending up with an empty file.

I stopped using it.


> Sent: Wednesday, December 23, 2020 at 10:23 AM
> From: "David Masterson" <dsmasterson92630@outlook.com>
> To: "Arthur Miller" <arthur.miller@live.com>
> Cc: "Richard Stallman" <rms@gnu.org>, "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org, "Gregory Heytings" <ghe@sdf.org>, "Eli Zaretskii" <eliz@gnu.org>, "Daniel Martín" <mardani29@yahoo.es>
> Subject: Re: Emacs as a word processor
>
> Arthur Miller <arthur.miller@live.com> writes:
> 
> > Jean Louis <bugs@gnu.support> writes:
> >
> >> * Arthur Miller <arthur.miller@live.com> [2020-12-22 22:41]:
> >>> Jean Louis <bugs@gnu.support> writes:
> >>> 
> >>> >> [ ] apply a bold / italic / underline / strikethrough effect
> >>> >> [ ] superscripts / subscripts
> >>> >> [ ] apply a left / center / right / justified effect
> >>> >> [ ] change the font color and the background color
> >>> >> [ ] create a list
> >>> >> [ ] insert and change a table
> >>> >> [ ] insert a picture
> >>> >> [ ] define / use / modify styles
> >>> >> [ ] print preview / print
> >>> >> [ ] use footnotes
> >>> >> [ ] multiple columns
> >>> >> [ ] change page headers and footers
> >>> >
> >>> > Yes, yes and yes. And all that is already supported and provided in
> >>> > the beautiful GNU project named TeXmacs:
> >>> > https://www.texmacs.org/tmweb/home/welcome.en.html
> >>> >
> >>> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
> >>> probably 1000 other applications? :-)
> >>> 
> >>> What is the point of saying it is provided in application X?
> >>
> >> Because it is GNU project.
> >
> > Ok :-).
> >
> > So we can switch all to texmacs? Does it syntax highlight C/C++ and run
> > Helm? :-)
> 
> Perhaps the two can be integrated?  That is a menu entry in Emacs that
> would spawn TeXmacs in such a way that TeXmacs would save it's file in
> Latex form which could then be imported into Auctex/Emacs?  In other
> words, let Emacs do Emacs and TeXmacs do TeXmacs in a way that
> communicates well.
> 
> -- 
> David Masterson
> 
>

Re: Emacs as a word processor

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-23 08:26]:
> A few years ago I used Texmacs but found in it some serious problems that
> could potentially get you to loose your work, ending up with an empty file.
> 
> I stopped using it.

I can understand it.

Back in time somewhere 1999-2000 several times I had to stop using
Emacs as it was crashing and there were several various versions and I
did not want risking losing my files. Maybe there were backups which I
did not know about it.

I have also used LyX extensively the Document Processor:
https://www.lyx.org/ and I would use it today if I wish to write
another book, it exports in various programs.

Org mode is very much degraded or basic set of formatting options that
are offered by LyX and TeXmacs as visual document processors.

Document processor is little different than a word processor.

Emacs is already a tool that does or integrates features that belong
to a document processor.

From:
https://en.wikipedia.org/wiki/Document_processor

Quote:

A document processor is a computer application that superficially
resembles a word processor—but emphasizes the visual layout of the
document's components,[1][2] above creation and formatting of
text. Document processor components are not just typical document
elements—paragraphs, lists, headers, etc. The primary attraction of a
document processor is the ability to program documents with strong
layout controls and powerful conditional automatic formatting rules
that creates structured documents. This facilitates creating large
numbers of similar elements generated and reformatted for different
media with little human effort.

Examples of document processors include programs and technologies such
as PTC Arbortext APP (formerly Advent 3B2,) Adobe FrameMaker, LyX,
BroadVision QuickSilver (formerly Interleaf TPS), Syntext Serna, and
the Wolfram notebook interface. Examples of markup languages used for
non-graphical document processing include SGML/XML, LaTeX, GNU TeXmacs
and troff.

Re: Emacs as a word processor

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-12-22 22:58]:
> >> > Yes, yes and yes. And all that is already supported and provided in
> >> > the beautiful GNU project named TeXmacs:
> >> > https://www.texmacs.org/tmweb/home/welcome.en.html
> >> >
> >> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
> >> probably 1000 other applications? :-)
> >> 
> >> What is the point of saying it is provided in application X?
> >
> > Because it is GNU project.
> 
> Ok :-).
> 
> So we can switch all to texmacs? Does it syntax highlight C/C++ and run
> Helm? :-)

I know is fun but let us think about it.

Probably it does not offer syntax highlight, but it is not impossible
as it can use scheme as extension language.

From there I can just think that scheme could provide communication
with Emacs.

My personal way of writing a book would be to rather write it as text
and THEN to format the chapters, text, justifications, etc. In general
I would let TeX and LaTeX decide about those issues.

Jean

Re: Emacs as a word processor

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-12-22 22:58]:
>> >> > Yes, yes and yes. And all that is already supported and provided in
>> >> > the beautiful GNU project named TeXmacs:
>> >> > https://www.texmacs.org/tmweb/home/welcome.en.html
>> >> >
>> >> Isn't it also all provided in LibreOffice, KOffice, Abi Word and
>> >> probably 1000 other applications? :-)
>> >> 
>> >> What is the point of saying it is provided in application X?
>> >
>> > Because it is GNU project.
>> 
>> Ok :-).
>> 
>> So we can switch all to texmacs? Does it syntax highlight C/C++ and run
>> Helm? :-)
>
> I know is fun but let us think about it.
>
> Probably it does not offer syntax highlight, but it is not impossible
> as it can use scheme as extension language.
Sceme, CL, EL, NL, PL ... its just lists anyway. I don't think should
focus too much on the lisp dialect. Compiler might make a difference,
but now you are getting native compiler for Elisp via gcc backend, so I
think it is option for performance then guile.

> From there I can just think that scheme could provide communication
> with Emacs.
Scheme is probably not mandatory for the communication with Emacs. You
can do communication via pipes or files or similar. But it is not much
of wyiswyin *in emacs* if you open another application. If that would be
the case user can just open Libre Office and use it. To be honest, I
don't see why Emacs needs to become another word processor, but if it is a
desire, it would be a fun to implement it :-).

> My personal way of writing a book would be to rather write it as text
> and THEN to format the chapters, text, justifications, etc. In general
> I would let TeX and LaTeX decide about those issues.
You are probably correct about that. I have never written a book, but if
I ever would I probably wouldn't use either Word or Writer, I would
probably use some tool based on Emacs.

Re: Emacs as a word processor

[yarnton--- via Emacs development discussions.]

You could probably implement all these functions with a minimal layer on top of org-mode, as it does support a lot of functionality already. Interoperability with docx and odt is harder unless you go down the rabbit hole of getting close to feature parity with them. Otherwise it will be one-way only.

IMHO, since Emacs is mostly plain text oriented it is going to be hard to go beyond supporting what Org already offers. Which is quite a lot: Hierarchical structure, different text formats, figures, tables, footnotes, metadata, very flexible exporting capabilities...

I would rather see Org getting more polished, friendlier and better documented. It's pretty well known and it has the potential to attract more Emacs users because it offers some unique features. But people tend to get scared away by it's apparent complexity. And frankly, the basics are really simple.

One area that could benefit from some improvements is reference management. Org offers footnotes, which are not quite the same as proper first-class references or citations.

Re: Emacs as a word processor

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 7:18 AM
> From: "yarnton--- via Emacs development discussions." <emacs-devel@gnu.org>
> To: "Gregory Heytings" <ghe@sdf.org>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>, "Richard Stallman" <rms@gnu.org>, "Daniel Martín" <mardani29@yahoo.es>
> Subject: Re: Emacs as a word processor
>
> You could probably implement all these functions with a minimal layer on top of org-mode, as it does support a lot of functionality already. Interoperability with docx and odt is harder unless you go down the rabbit hole of getting close to feature parity with them. Otherwise it will be one-way only.
> 
> IMHO, since Emacs is mostly plain text oriented it is going to be hard to go beyond supporting what Org already offers. Which is quite a lot: Hierarchical structure, different text formats, figures, tables, footnotes, metadata, very flexible exporting capabilities...
> 
> I would rather see Org getting more polished, friendlier and better documented. It's pretty well known and it has the potential to attract more Emacs users because it offers some unique features. But people tend to get scared away by it's apparent complexity. And frankly, the basics are really simple.

I support the idea.  Org-Mode is more appropriate.  Then keep Standard Emacs as a plain text
programming editor.
 
> One area that could benefit from some improvements is reference management. Org offers footnotes, which are not quite the same as proper first-class references or citations.
> 
> 
>

Re: Emacs as a word processor

[Stefan Kangas]

yarnton--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Interoperability with docx and odt is harder unless you go down the
> rabbit hole of getting close to feature parity with them. Otherwise it
> will be one-way only.

I don't see why the options are limited to "feature parity" or "one-way
only".  I think there can exist a useful half-way house of "two way
support for odt" even if it is vastly more basic than "feature parity".

> IMHO, since Emacs is mostly plain text oriented it is going to be hard
> to go beyond supporting what Org already offers. Which is quite a lot:
> Hierarchical structure, different text formats, figures, tables,
> footnotes, metadata, very flexible exporting capabilities...

FWIW, my ideal UI would be: open an odt file and edit it in Org-mode,
save it again as an odt file.  It doesn't matter much to me if some
formatting is removed, as long as the most basic is preserved such as
italics, bold, headings, blockquotes and maybe links.

> One area that could benefit from some improvements is reference
> management. Org offers footnotes, which are not quite the same as
> proper first-class references or citations.

Indeed, this is one of the worst parts of Org-mode now.  But I have a
hard time even conceptually dreaming up what an ideal UI would look
like here.

Re: Emacs as a word processor

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

>> One area that could benefit from some improvements is reference
>> management. Org offers footnotes, which are not quite the same as
>> proper first-class references or citations.
>
> Indeed, this is one of the worst parts of Org-mode now.  But I have a
> hard time even conceptually dreaming up what an ideal UI would look
> like here.

What about the UI developed by Prof. Kitchin [1]?

[1] https://github.com/jkitchin/org-ref

Re: Emacs as a word processor

[yarnton--- via Emacs development discussions.]

>>> One area that could benefit from some improvements is reference
>>> management. Org offers footnotes, which are not quite the same as
>>> proper first-class references or citations.
>>>
>>
>> Indeed, this is one of the worst parts of Org-mode now.  But I have a
>> hard time even conceptually dreaming up what an ideal UI would look
>> like here.
>>
>
> What about the UI developed by Prof. Kitchin [1]?
>
> [1] https://github.com/jkitchin/org-ref
>

It's a great starting point, but I think references should be an integral part of Org. Otherwise, there is a lot of fragmentation: Using footnotes as references, org-ref references, other systems...

Re: Emacs as a word processor

[Stefan Monnier]

> What about the UI developed by Prof. Kitchin [1]?
> [1] https://github.com/jkitchin/org-ref

I don't have an opinion on its UI, but last time I checked, I found this
package to have way too many dependencies (several of them literally
not necessary).

I think it would benefit from a bit of help in improving the code and
the packaging.


        Stefan

Re: Emacs as a word processor

[Ihor Radchenko]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What about the UI developed by Prof. Kitchin [1]?
>> [1] https://github.com/jkitchin/org-ref
>
> I don't have an opinion on its UI, but last time I checked, I found this
> package to have way too many dependencies (several of them literally
> not necessary).

I agree about the excessive dependencies. I was only referring to UI.

Specifically:

1. Incremental search across all the references by
   title/author/publisher/keywords
2. Support of org-links with proper exporting (i.e., org links to
   articles are replaced to \cite in LaTeX)
3. Auto-generating bibliography
4. Ability to insert links to non-org buffers (text style references in
   emails/text documents or even reference pdfs as email attachments)
5. Auto-retrieving meta-data from URL or DOI
6. Bibliography notes

> I think it would benefit from a bit of help in improving the code and
> the packaging.

For now, I am working some things that are not good enough for me in
org-ref. See github.com/yantar92/org-capture-ref.

I plan to work on reference management in org with distant aim to
integrate it into org core. It would be helpful if you open feature
request in org-mode mailing list listing the features you expect.

Best,
Ihor

Re: Emacs as a 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 about the UI developed by Prof. Kitchin [1]?
  > > [1] https://github.com/jkitchin/org-ref

  > I don't have an opinion on its UI, but last time I checked, I found this
  > package to have way too many dependencies (several of them literally
  > not necessary).

Would you like to summarize in 10 lines what job it does?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:
>   > > What about the UI developed by Prof. Kitchin [1]?
>   > > [1] https://github.com/jkitchin/org-ref
>
>   > I don't have an opinion on its UI, but last time I checked, I found this
>   > package to have way too many dependencies (several of them literally
>   > not necessary).
>
> Would you like to summarize in 10 lines what job it does?

If you are asking about what org-ref does (in regard to reference
management), I tried to list the most important (for me) features in my
other email. Copying the relevant part of the email below:

1. Incremental search across all the references by
   title/author/publisher/keywords
2. Support of org-links with proper exporting (i.e., org links to
   articles are replaced to \cite in LaTeX)
3. Auto-generating bibliography
4. Ability to insert links to non-org buffers (text style references in
   emails/text documents or even reference pdfs as email attachments)
5. Auto-retrieving meta-data from URL or DOI
6. Bibliography notes

Best,
Ihor

Re: Emacs as a word processor

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:
>   > > What about the UI developed by Prof. Kitchin [1]?
>   > > [1] https://github.com/jkitchin/org-ref
>
>   > I don't have an opinion on its UI, but last time I checked, I found this
>   > package to have way too many dependencies (several of them literally
>   > not necessary).
>
> Would you like to summarize in 10 lines what job it does?

If you are asking about what org-ref does (in regard to reference
management), I tried to list the most important (for me) features in my
other email. Copying the relevant part of the email below:

1. Incremental search across all the references by
   title/author/publisher/keywords
2. Support of org-links with proper exporting (i.e., org links to
   articles are replaced to \cite in LaTeX)
3. Auto-generating bibliography
4. Ability to insert links to non-org buffers (text style references in
   emails/text documents or even reference pdfs as email attachments)
5. Auto-retrieving meta-data from URL or DOI
6. Bibliography notes

Best,
Ihor

Re: Emacs as a 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. ]]]

  org-ref does
  > 5. Auto-retrieving meta-data from URL or DOI

This may be an example of a dangerous practice: communicating over the
network as a silent subtask of something else the user asks to do.

Or maybe it isn't.  After all, I don't know the details -- I can't
reach any certain conclusions.  What I am doing is extrapolating to a
possible danger.  That's my job ;-).  So the next step is to learn
some more.

Could you please show us concretely what org-ref does in regard
to this meta-data?  What would the user specify, and what would
it do in response?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > 5. Auto-retrieving meta-data from URL or DOI
>
> This may be an example of a dangerous practice: communicating over the
> network as a silent subtask of something else the user asks to do.
>
> Or maybe it isn't.  After all, I don't know the details -- I can't
> reach any certain conclusions.  What I am doing is extrapolating to a
> possible danger.  That's my job ;-).  So the next step is to learn
> some more.
>
> Could you please show us concretely what org-ref does in regard
> to this meta-data?  What would the user specify, and what would
> it do in response?

AFAIK, org-ref provides ways to get BiBTeX entry
(author/title/publication year/journal/etc) using digital object
identifier (DOI) [1]. DOI metadata is available through doi.org website,
which is ran by non-profit International DOI Foundation. This is done
when the user explicitly request to retrieve that data and add it to
bibtex file (or insert at point). Internally, the metadata needed to
format BiBTeX entry is retrieved using doi.org http API (via
url-retrieve-synchronously + json-read-from-string).

Further, the user can request to download pdf of the article using the
article DOI. This is also done through doi.org that provides information
about the URL where the article is published. Such URL typically points
to scientific journal website (all of such websites that I am aware of
contain javascript). However, org-ref overcomes the need to open the
publisher websites by providing a way to construct direct link to
download the pdf without a need to open browser. Not all the publishers
are supported, but it is already much better than nothing.

For ISBN, it is actually not supported. Though I thought it is.

Best,
Ihor

[1] https://en.wikipedia.org/wiki/Digital_object_identifier

Re: Emacs as a word processor

[Kévin Le Gouguec]

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

Stefan Kangas <stefankangas@gmail.com> writes:

>> One area that could benefit from some improvements is reference
>> management. Org offers footnotes, which are not quite the same as
>> proper first-class references or citations.
>
> Indeed, this is one of the worst parts of Org-mode now.  But I have a
> hard time even conceptually dreaming up what an ideal UI would look
> like here.

In terms of UI, I find RefTeX's selection buffers pretty ergonomic.

For intra-document references:
- C-c ) RET
- s for subsections, t for tables, etc.
- A pop-up buffer shows an outline of all matching labels in the
  document; the user can pick one with n/p and RET.

For citations:
- C-c [
- type in a regular expression
- A pop-up buffer shows the list of all BibTeX entries where a field
  matches the regexp; the user can pick one with n/p and RET.

Cf. [1] for a sample document and instructions to try out the UI.

RefTeX's implementation is probably heavily tailored to BibTeX
bibliographies; FWIW I think it'd make sense to reuse its "presentation
layer", or at least take inspiration from it for a new UI.


[1] Install AUCTeX from GNU ELPA, then evaluate the following:

#+begin_src elisp
(put 'TeX-auto-save 'safe-local-variable 'booleanp)
(put 'TeX-parse-self 'safe-local-variable 'booleanp)
(add-hook 'LaTeX-mode-hook 'turn-on-reftex)
(setq reftex-plug-into-AUCTeX t)
#+end_src

Save the attachments in $SOME_DIRECTORY; add this to
$SOME_DIRECTORY/.dir-locals.el:

#+begin_src elisp
((latex-mode
  . ((TeX-auto-save . t)
     (TeX-parse-self . t)))
 (bibtex-mode
  . ((TeX-auto-save . t)
     (TeX-parse-self . t))))
#+end_src

Open the .tex attachment: C-c ) RET should allow you to pick any label
defined inside the file; C-c [ should let you pick any citation defined
in the .bib attachment.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: example.tex --]
[-- Type: text/x-tex, Size: 728 bytes --]

\documentclass{article}

\usepackage{float}

\title{
  Example document to showcase RefTeX UI
}

\begin{document}
\maketitle

\section{Introduction}
\label{sec:intro}

\section{Background}
\label{sec:bg}

See~\cite{rmsemacs}\cite{nativecomp}\cite{evolutionelisp}.

\section{Methodology}
\label{sec:method}

\section{Results}
\label{sec:results}

\begin{table}[H]
  \centering
  \begin{tabular}{l|l|l}
    \textbf{Column 1} & \textbf{Column 2} & \textbf{Column 3} \\
    \hline
    1                 & 2                 & 3                 \\
  \end{tabular}
  \caption{Example table}
  \label{tab:results}
\end{table}

\section{Conclusion}
\label{sec:conclusion}

\bibliographystyle{alpha}
\bibliography{biblio}

\end{document}

[-- Attachment #3: biblio.bib --]
[-- Type: text/x-bibtex, Size: 4338 bytes --]

@article{rmsemacs,
    author = {Stallman, Richard M.},
    title = {{EMACS the Extensible, Customizable Self-Documenting Display Editor}},
    year = {1981},
    issue_date = {June 1981},
    publisher = {Association for Computing Machinery},
    address = {New York, NY, USA},
    volume = {16},
    number = {6},
    issn = {0362-1340},
    url = {https://doi.org/10.1145/872730.806466},
    doi = {10.1145/872730.806466},
    abstract = {EMACS is a display editor which is implemented in an interpreted high level language. This allows users to extend the editor by replacing parts of it, to experiment with alternative command languages, and to share extensions which are generally useful. The ease of extension has contributed to the growth of a large set of useful features. This paper describes the organization of the EMACS system, emphasizing the way in which extensibility is achieved and used.This report describes work done at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for the laboratory's research is provided in part by the Advanced Research Projects Agency of the Department of Defense under Office of Naval Research contract N00014-80-C-0505.},
    journal = {SIGPLAN Not.},
    month = apr,
    pages = {147–156},
    numpages = {10}
}

@inproceedings{nativecomp,
    author = {Corallo, Andrea and Nassi, Luca and Manca, Nicola},
    year = {2020},
    month = {04},
    pages = {},
    title = {{Bringing GNU Emacs to Native Code}},
    doi = {10.5281/zenodo.3736363}
}

@article{evolutionelisp,
    author = {Monnier, Stefan and Sperber, Michael},
    title = {{Evolution of Emacs Lisp}},
    year = {2020},
    issue_date = {June 2020},
    publisher = {Association for Computing Machinery},
    address = {New York, NY, USA},
    volume = {4},
    number = {HOPL},
    url = {https://doi.org/10.1145/3386324},
    doi = {10.1145/3386324},
    abstract = {While Emacs proponents largely agree that it is the world’s greatest text editor, it is almost as much a Lisp machine disguised as an editor. Indeed, one of its chief appeals is that it is programmable via its own programming language. Emacs Lisp is a Lisp in the classic tradition. In this article, we present the history of this language over its more than 30 years of evolution. Its core has remained remarkably stable since its inception in 1985, in large part to preserve compatibility with the many third-party packages providing a multitude of extensions. Still, Emacs Lisp has evolved and continues to do so. Important aspects of Emacs Lisp have been shaped by concrete requirements of the editor it supports as well as implementation constraints. These requirements led to the choice of a Lisp dialect as Emacs’s language in the first place, specifically its simplicity and dynamic nature: Loading additional Emacs packages or changing the ones in place occurs frequently, and having to restart the editor in order to re-compile or re-link the code would be unacceptable. Fulfilling this requirement in a more static language would have been difficult at best. One of Lisp’s chief characteristics is its malleability through its uniform syntax and the use of macros. This has allowed the language to evolve much more rapidly and substantively than the evolution of its core would suggest, by letting Emacs packages provide new surface syntax alongside new functions. In particular, Emacs Lisp can be customized to look much like Common Lisp, and additional packages provide multiple-dispatch object systems, legible regular expressions, programmable pattern-matching constructs, generalized variables, and more. Still, the core has also evolved, albeit slowly. Most notably, it acquired support for lexical scoping. The timeline of Emacs Lisp development is closely tied to the projects and people who have shaped it over the years: We document Emacs Lisp history through its predecessors, Mocklisp and MacLisp, its early development up to the “Emacs schism” and the fork of Lucid Emacs, the development of XEmacs, and the subsequent rennaissance of Emacs development.},
    journal = {Proc. ACM Program. Lang.},
    month = jun,
    articleno = {74},
    numpages = {55},
    keywords = {History of programming languages, Lisp, Emacs Lisp}
}

Re: Emacs as a 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 don't see why the options are limited to "feature parity" or "one-way
  > only".  I think there can exist a useful half-way house of "two way
  > support for odt" even if it is vastly more basic than "feature parity".

I agree.  In addition, it would be possible to support reading and writing
files that use features that Emacs does not actually handle.

  > FWIW, my ideal UI would be: open an odt file and edit it in Org-mode,
  > save it again as an odt file.  It doesn't matter much to me if some
  > formatting is removed, as long as the most basic is preserved such as
  > italics, bold, headings, blockquotes and maybe links.

It is fine to provide a way to do that, but it would be very limiting.
It would mean that if your ODT file does anything sophisticated,
Emacs would not only be unable to edit those aspects of it.
but passing the file through Emacs would lose all that information!
You could not use Emacs to do a few tweaks to the simple aspects
of the file, because that would corrupt it.

If you'd like to edit the file in Org format, then you should save it
in Org format, and convert it to ODT at the end if you wish to.
That will be simpler and will run faster.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[Arthur Miller]

yarnton--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You could probably implement all these functions with a minimal layer on top of
> org-mode, as it does support a lot of functionality already.
Org is another markup language, org is little higher than say md or rtf
or xml/html which are other markup languages, but it would be much more
work then "minimal layer". It is just half-wysiwyg. It is not
impossible, but is not that minimal either.

> IMHO, since Emacs is mostly plain text oriented it is going to be hard to go
> beyond supporting what Org already offers.
What would be a problem there? Probably every text manipulation program
has some kind of plain text storage in it's backend somewhere; be it an
array as in Emacs or some linked structure.

Emacs has Lisp which has lists which lets you build arbitrary structures.

It is trivial to implement hierarchical structures like DOM tree or a
scene graph in Lisp since n-ary trees can be easily created with
lists. Likewise key-value properties like CSS properties are also easily
represented with lists; I guess that is what Emacs text properties
already are.

One could use buffer just as a memory storage and index into it, so
"plain text" is really not a problem. And by the way, it is not so plain
anymore, is utf8, so big part of the work is already done (encoding/decoding).

The only problem I see is Emacs renderer. It just needs a little bit
more flexibility so it can render stuff in layers, on top of each other,
so we could for example render some nice rectangle for a page,  markers where
text on paper starts, ends etc. Also a pixel aligned dragging of objects
with mouse might be useful to have in a wysiwyg application, but is not necessary.

I think print view could already be implemented by simply rendering
buffer to svg image and displaying it in another buffer.

Re: Emacs as a 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. ]]]

  > My impression (but I could very well be wrong) is that what RMS would like 
  > to have is not a truly WYSIWYG word processor that would compete with 
  > LibreOffice, but something simpler.

Ideally it would compete with LibreOffice.

However, if it can handle editing ODT files the same as LibreOffice,
but fails to display them as nicely, that would be a big step
along the way.

I suspect that displaying ODT files properly requires figuring out exactly
how they should render in LibreOffice.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs as a word processor

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 9:51 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Gregory Heytings" <ghe@sdf.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org, mardani29@yahoo.es
> Subject: Re: Emacs as a word processor
>
> [[[ 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. ]]]
>
>   > My impression (but I could very well be wrong) is that what RMS would like
>   > to have is not a truly WYSIWYG word processor that would compete with
>   > LibreOffice, but something simpler.
>
> Ideally it would compete with LibreOffice.
>
> However, if it can handle editing ODT files the same as LibreOffice,
> but fails to display them as nicely, that would be a big step
> along the way.
>
> I suspect that displaying ODT files properly requires figuring out exactly
> how they should render in LibreOffice.

Couldn't a major mode for that work.  For Org-Mode I have seen that Protesilaos
Stavrou has worked on Focused Editing and Proportionately Spaced Typeface.

> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>