Emacs as a word processor

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 (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-12-25 07:38]:
> [[[ 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.

- in my opinion both Word and RFT are not necessary for Emacs as that
  just acknowledges proprietary formats and tells users message that
  shall not be told from GNU programs. But there are already
  possibilities to convert Word programs to and from, see below.
 
- there are Word importing capabilities by using other available free
  software. Emacs could advise users to install some external software
  to convert from Word.

- one of best for me personally is `antiword' it just extracts simple
  text. But I have no Word files on computer.

- another good one is Abiword which has Word import/export
  capabilities on the command line. So a simple Emacs function of few
  lines could already use Abiword as external convertor and import file
  into Emacs word processing

From Abiword manual page:

	-t DEST, --to=DEST
		Convert the  given file to another  format, writing the
		result to  DEST.  The format  of DEST is  determined by
		its extension.
		See also --to=FORMAT and --to-name.

	-t FORMAT, --to=FORMAT
		Convert the given files(s)  to the given format. Unless
		explicitly  specified  with   --to-name,  the  original
		filename will  be used (with a  different extension, if
		necessary). See also EXAMPLES.

		The more popular values for FORMAT include:

			lb	lx.
			abw	T{
			Abiword XML format (zabw for gzip, bzabw for bzip2 compression)
			T}
			dbk	DocBook XML
			doc	Microsoft Word binary format
			docx	T{
			Office Open XML (newer Microsoft Word versions)
			T}
			html	Hypertext Markup Language
			kwd	KWord
			odt	OpenDocument Text
			pdf	Portable Document Format
			rtf	Rich Text Format
			sxw	OpenOffice.org Writer 1.0
			txt	Plain text

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eli Zaretskii]

> Date: Fri, 25 Dec 2020 10:14:40 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> - there are Word importing capabilities by using other available free
>   software. Emacs could advise users to install some external software
>   to convert from Word.

There are also Free Software word processors out there, so why do we
insist on having such capabilities in Emacs?

I think you underestimate the amount of pressure applied on any
J.R. Hacker having a daytime job to use MS Office.  You cannot be a
useful and appreciated part of an organization without having to use
those tools, because all the correspondence and all the documentation
is based on that.  And there's no real Free Software alternative,
certainly not based on Emacs.

The alternative solutions you suggest are extremely impractical.  They
require people who know nothing about DOCX, DocBook, XML, ODT, and
other formats to become proficient enough in these to figure out
whether every feature of MS Office can be supported.  (Do _you_ know
if everything is supported?)  You further ask them to be able to
create for themselves a bunch of scripts or programs to convert the
Office files to something else, edit it in Emacs, then convert back
without losing important features of the original document.  You then
ask them to find Emacs packages that allow conveniently and reasonably
WYSIWYG-ly edit the converted Office documents.  (Are you aware of
packages to conveniently edit HTML or XML or DocBook or ODT? what are
they?)

Asking people to jump through such hoops to be able to read and edit a
document created by MS Office is a huge turn-off, and will be rejected
by most people, because in this aspect a word processor is just a tool
to do a job, and do it quickly and efficiently.  Most people don't
have the time and energy, let alone talent and skills, to do a
programming project each time they need to review a document or a
spreadsheet.

This is why it would be useful to have this kind of capabilities in
Emacs: to enable users to visit MS Office documents with "C-x C-f",
edit them in some specialized WYSIWYG Emacs mode, and finally save
them with "C-x C-s".  If under the hood this runs some converters, it
doesn't matter.

> - one of best for me personally is `antiword' it just extracts simple
>   text. But I have no Word files on computer.
> 
> - another good one is Abiword which has Word import/export
>   capabilities on the command line. So a simple Emacs function of few
>   lines could already use Abiword as external convertor and import file
>   into Emacs word processing

So you are saying that, from the Free Software philosophy POV, it is
not okay to have Emacs be able to access such files, but it _is_ okay
to use the likes of Abiword to do the same?  I don't think I see the
logic in that.  If you are opposed to using MS Office file formats,
you should refuse to look at them, in any form or shape, and instead
request that the person who sends them produces them in some free
format instead.  That would be a logical position which I can
understand and respect.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-25 11:15]:
> > Date: Fri, 25 Dec 2020 10:14:40 +0300
> > From: Jean Louis <bugs@gnu.support>
> > 
> > - there are Word importing capabilities by using other available free
> >   software. Emacs could advise users to install some external software
> >   to convert from Word.

> I think you underestimate the amount of pressure applied on any
> J.R. Hacker having a daytime job to use MS Office.  You cannot be a
> useful and appreciated part of an organization without having to use
> those tools, because all the correspondence and all the
> documentation is based on that.  And there's no real Free Software
> alternative, certainly not based on Emacs.

Since 21 years I use free software. Before that I used proprietary
Windows and various programs. Already back then I have found all the
free software to replace anything that I otherwise used on Windows. I
remember using LyX and writing books and HTML pages with it. That is
why I cannot share that opinion. I did find what I needed many years
ago, individually, so other users can also find it.

> The alternative solutions you suggest are extremely impractical.  They
> require people who know nothing about DOCX, DocBook, XML, ODT, and
> other formats to become proficient enough in these to figure out
> whether every feature of MS Office can be supported.  (Do _you_ know
> if everything is supported?)

Among priorities to have word processing or to have import/export with
Word format, than first would first to have word processing that users
may construct their pages in WYSIWYG fashion, and print it and get
nice results. As you mentioned enriched mode, and I am using it for
notes in the database, that could be good start (without knowing
technical background).

And I have not mentioned anything impractical. I was thinking it will
be natural to understand that such features of Abiword or antiword can
be used from Emacs functions. Recently we discussed using `curl' as
outside tool, it is not FSF copyrighted and we discuss it. I can think
that many other libraries are also used by Emacs that do not come from
FSF necessarily.

So you could bind/link or otherwise provide simple functions that
invoke Abiword on command line to provide import/export for various
documents. That is practical, not impractical. Otherwise as Abiword is
from Gnome project, you could include parts of it in Emacs. I really
did not look into those technicalities, the references I gave you are
for consideration and research.

Then visualize it:

Menu -> File -> Import -> Word Document, open up document in Dired and
run function with Abiword to convert it to format that Emacs will
understand.

Menu -> File -> Export -> Word Document, run function with Abiword to
convert the file Emacs is editing to be exported as Word document.

I hope you get better picture now.

> You further ask them to be able to create for themselves a bunch of
> scripts or programs to convert the Office files to something else,
> edit it in Emacs, then convert back without losing important
> features of the original document.

As the main target is GNU/Linux we need not ask people to keep any
compatibility with Word. Providing conversion functions as explained
above is enough.

Apropos asking, with Emacs we ask users ANYTHING POSSIBLE, including
to know Emacs Lisp and in comparison with outside software Emacs
configurations cannot be said to be user friendly. It is advanced text
editor and rather for advanced users.

Every user in Emacs and on mailing list is asked to create bunch of
scripts and programs to convert this and that, do this and that, just
look any mailing list and observe.

I am always supporting integration, it means connecting functions
together for users to have better accessible integrated environment.

> This is why it would be useful to have this kind of capabilities in
> Emacs: to enable users to visit MS Office documents with "C-x C-f",
> edit them in some specialized WYSIWYG Emacs mode, and finally save
> them with "C-x C-s".  If under the hood this runs some converters, it
> doesn't matter.

We both agree, you just went away from the yellow brick road. I just
pointed out that tools exist and they could be used to be integrated
in Emacs without reinventing the wheel. Just use available libraries
and programs. 

Also note that Libreoffice also has command line conversion.

	[--outdir output_dir] file...
		Batch  converts files.   If --outdir  is not  specified
		then  the  current working  directory  is  used as  the
		output directory  for the  converted files.  It implies
		--headless.

		Examples:

		--convert-to pdf *.doc

		Converts all .doc files to PDFs.

		--convert-to pdf:writer_pdf_Export  --outdir /home/user
		*.doc

		Converts all .doc  files to PDFs using  the settings in
		the  Writer  PDF  export  dialog  and  saving  them  in
		/home/user.

And that reference is NOT meant for users to make it manually but to
use it within Emacs to integrate it so that user can just open the
file and Emacs can convert it on the fly.

Customization options could say which converter to use:

- antiword
- abiword
- libreoffice
- openoffice
- etc.

> > - another good one is Abiword which has Word import/export
> >   capabilities on the command line. So a simple Emacs function of few
> >   lines could already use Abiword as external convertor and import file
> >   into Emacs word processing
> 
> So you are saying that, from the Free Software philosophy POV, it is
> not okay to have Emacs be able to access such files, but it _is_
> okay to use the likes of Abiword to do the same?

Yes, I do. I would say the same to Abiword would I be back in time
when they started with it. If option already exists, then I think that
focusing on handling or putting priority on Word files in Emacs is
total deviation from priorities.

> I don't think I see the logic in that.  If you are opposed to using
> MS Office file formats, you should refuse to look at them, in any
> form or shape, and instead request that the person who sends them
> produces them in some free format instead.  That would be a logical
> position which I can understand and respect.

I do refuse and never open such files. I send to people instructions
how to convert them and will not read it until they do, and they
do. 

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eli Zaretskii]

> Date: Fri, 25 Dec 2020 12:58:23 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> > I think you underestimate the amount of pressure applied on any
> > J.R. Hacker having a daytime job to use MS Office.  You cannot be a
> > useful and appreciated part of an organization without having to use
> > those tools, because all the correspondence and all the
> > documentation is based on that.  And there's no real Free Software
> > alternative, certainly not based on Emacs.
> 
> Since 21 years I use free software. Before that I used proprietary
> Windows and various programs. Already back then I have found all the
> free software to replace anything that I otherwise used on Windows. I
> remember using LyX and writing books and HTML pages with it. That is
> why I cannot share that opinion. I did find what I needed many years
> ago, individually, so other users can also find it.

We cannot tell our users to wait for another 21 years for a solution
that might emerge if they invest enough energy in their own private
collection of tools.

And your solutions are lacking, even by your own account.  You have
just complained elsewhere that using ps-print (which you say is the
solution for the "printing" part of WP) doesn't allow you to control
the place where each line is wrapped.  In addition, ps-print's support
for non-Latin-1 scripts is extremely poor (needs a lot of configuring
and looks ugly on paper).  And I don't even want to start talking
about R2L scripts.

So what you have, and claim is a satisfactory solution for the issue
at hand, is actually not a solution at all.  It may be good enough for
your personal needs (and even there you are not always satisfied), but
it definitely is not good enough for others, not unless they are in
cultures that are English-speaking or in some parts of Western Europe.

That is nowhere near the goal we want Emacs to be.

> Among priorities to have word processing or to have import/export with
> Word format, than first would first to have word processing that users
> may construct their pages in WYSIWYG fashion, and print it and get
> nice results. As you mentioned enriched mode, and I am using it for
> notes in the database, that could be good start (without knowing
> technical background).

Priorities are a separate issue.  I agree that we should have WYSIWYG
editing capabilities before we have interoperability with other
formats.  I was responding to the claim that interoperability with MS
Office is not needed, or that it's so bad we shouldn't even consider
it.

> Menu -> File -> Import -> Word Document, open up document in Dired and
> run function with Abiword to convert it to format that Emacs will
> understand.
> 
> Menu -> File -> Export -> Word Document, run function with Abiword to
> convert the file Emacs is editing to be exported as Word document.

That is already an unnecessary nuisance.  Users should be able to
visit such files as usual, with "C-x C-f" etc., and save them with the
likes of "C-x C-s".  Emacs has infrastructure for converting the file
under the hood for many years, see the node "Format Conversion" in the
ELisp manual.

And anyway, the conversion itself is not the issue.  The issue is how
to let our users edit the output of the conversion conveniently and
easily.  Currently, Emacs doesn't provide such facilities for any
format that Abiword can produce.  Someone has to code such facilities,
and that isn't get done by talking.

> > You further ask them to be able to create for themselves a bunch of
> > scripts or programs to convert the Office files to something else,
> > edit it in Emacs, then convert back without losing important
> > features of the original document.
> 
> As the main target is GNU/Linux we need not ask people to keep any
> compatibility with Word. Providing conversion functions as explained
> above is enough.

I think there's a misunderstanding wrt the meaning of "compatibility"
in this context.  From where I stand, it is immaterial whether we
convert the files under the hood or read them directly.  users will
not mind either way.  IOW, this is a non-issue.

> Every user in Emacs and on mailing list is asked to create bunch of
> scripts and programs to convert this and that, do this and that, just
> look any mailing list and observe.

That is definitely false.  Emacs can be used as a useful and powerful
editor without any tinkering or scripting.

> > I don't think I see the logic in that.  If you are opposed to using
> > MS Office file formats, you should refuse to look at them, in any
> > form or shape, and instead request that the person who sends them
> > produces them in some free format instead.  That would be a logical
> > position which I can understand and respect.
> 
> I do refuse and never open such files. I send to people instructions
> how to convert them and will not read it until they do, and they
> do. 

That's good for you, but asking others to behave like that is
impractical, let alone unnecessary.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-25 15:09]:
> And your solutions are lacking, even by your own account.  You have
> just complained elsewhere that using ps-print (which you say is the
> solution for the "printing" part of WP) doesn't allow you to control
> the place where each line is wrapped.  In addition, ps-print's support
> for non-Latin-1 scripts is extremely poor (needs a lot of configuring
> and looks ugly on paper).  And I don't even want to start talking
> about R2L scripts.

Yes, I said that it would be good to have the formula that makes
it. The only reason to use Emacs ps-print-buffer-with-faces would be
to print those enriched-mode notes that I have.

Otherwise I use LaTeX and I can fit it as I wish and use any
editor. Me personally I do not seek to use Emacs as word
processor. Word processors are waste of time. LaTeX and similar
systems like I mentioned LyX and TeXmacs they compute for me the
spaces, positions, indexes, item number. I would not like switching
from that position where I do not think about things computer should
think for me into position to do those things myself in a word
processor.

Document processor is fine, word processor is not useful
personally.

Libreoffice I open from time to time when I need to see somebody's
presentation, or to make my own poster, or to make multiplication
table for children. My use of it can be replaced with Gimp or with
Inkscape. For anything document related I am using LaTeX or Org mode
for simpler representations. Letters, faxes, agreements, books is by
LaTeX, simple projects of 50-100 pages is by Org mode.

Look at description here that applies to TeXmacs and to Emacs using
Org mode or LaTeX: https://www.lyx.org/

,----
| 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. This results in world-class support for
| creation of mathematical content (via a fully integrated equation
| editor) and structured documents like academic articles, theses, and
| books. In addition, staples of scientific authoring such as reference
| list and index creation come standard. But you can also use LyX to
| create a letter or a novel or a theatre play or film script. A broad
| array of ready, well-designed document layouts are built in.
| 
| LyX is for people who want their writing to look great, right out of
| the box. No more endless tinkering with formatting details, “finger
| painting” font attributes or futzing around with page boundaries. You
| just write. On screen, LyX looks like any word processor; its printed
| output — or richly cross-referenced PDF, just as readily produced —
| looks like nothing else .
`----

I do not want to think of formatting and positions, page boundaries,
etc. I want to tell what I mean and that I get the result.

Word processors never delivered it.

Emacs with LaTeX, LaTeX with any editor, Lout, Org mode, LyX deliver
what user wish and want.

Going back to word processor is regression for me, not progress.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eli Zaretskii]

> Date: Fri, 25 Dec 2020 16:11:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: emacs-devel@gnu.org
> 
> Going back to word processor is regression for me, not progress.

As someone who uses both word processors and Emacs almost every day,
and also gets to use (La)TeX quite frequently, I can only say that you
probably never got into using word processors enough to see their
advantages, if that is your opinion.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 16:11, Jean Louis <bugs@gnu.support> wrote:
> * Eli Zaretskii <eliz@gnu.org> [2020-12-25 15:09]:
>> And your solutions are lacking, even by your own account.  You have
>> just complained elsewhere that using ps-print (which you say is the
>> solution for the "printing" part of WP) doesn't allow you to control
>> the place where each line is wrapped.  In addition, ps-print's
>> support for non-Latin-1 scripts is extremely poor (needs a lot of
>> configuring and looks ugly on paper).  And I don't even want to start
>> talking about R2L scripts.

So far I have similar limitations in emacs-pdf but I would like to
improve that.

> Yes, I said that it would be good to have the formula that makes
> it. The only reason to use Emacs ps-print-buffer-with-faces would be
> to print those enriched-mode notes that I have.

When I tried enriched-mode I did not figure out how to use it.

If I implemented pdf-buffer-with-faces what kind of formatting stuff
would you find important?

> Libreoffice I open from time to time when I need to see somebody's
> presentation

You can do that in Emacs already.  Using emacs-framebuffer should work
automatically out of the box.  Using doc-view or pdf-tools might need
extra conversion to pdf.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-28 00:28]:
> So far I have similar limitations in emacs-pdf but I would like to
> improve that.

I will look into that software, I have these emails flagged as
important. 

> > Yes, I said that it would be good to have the formula that makes
> > it. The only reason to use Emacs ps-print-buffer-with-faces would be
> > to print those enriched-mode notes that I have.
> 
> When I tried enriched-mode I did not figure out how to use it.

You can open any file and M-x enriched-mode, and then you may use menu
Edit -> Text Properties to make background or foreground of letters,
bold, italic, etc.

When I mark it up as italic sadly I do not see italic on screen, that
may need some set up of fonts, I cannot know. Bold italic I also do
not see. And I use these keys below to quickly change those formats. 

(defvar hyperscope-enriched-mode-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map enriched-mode-map)
    (define-key map (kbd "s-b") 'facemenu-set-bold)
    (define-key map (kbd "s-d") 'facemenu-set-default)
    (define-key map (kbd "s-i") 'facemenu-set-italic)
    (define-key map (kbd "s-j") 'facemenu-set-bold-italic)
    (define-key map (kbd "s-u") 'facemenu-set-underline)
    (define-key map (kbd "s-r") 'facemenu-set-background)
    (define-key map (kbd "s-f") 'facemenu-set-foreground)
    map)
  "The Hyperscope enriched keymap")

You can also save the file and next time it is opened it will be
marked up with your formats, like bold, italic, foreground and
background colors.

> If I implemented pdf-buffer-with-faces what kind of formatting stuff
> would you find important?

What is necessary is what is in the Edit -> Text properties. Also note
that there can be some invisible Lisp in enriched mode, and I wish to
come to that, but if anything is invisible it should not be shown on
paper in my opinion.

Emacs has already good printing solution. And I get easily PDF
files. Now how would your solution be useful?

I am using below function, so I already get the PDF converted there
that remains in the directory and it also shows it in front of my
face.

#!/bin/bash
tmpdir=/home/data1/protected/tmp/muttprint/
mkdir -p $tmpdir
cd $tmpdir
file=$tmpdir/$(date +'%F-%T-%A')
#highlight --syntax=lisp --page-color -O pango | paps --markup --font="Monospace 11" > $file.ps
cat > $file.ps
#gv $file.ps
# paps --font="DejaVu Sans Mono 11" > $file.ps
ps2pdf14 $file.ps
exec zathura $file.pdf 2> /dev/null &

But printing with faces has some errors if one mixes colors with bold
letters, it will not come out same in the ps/pdf files. When I find
out more about errors I will report.

RE: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Drew Adams]

> When I mark it up as italic sadly I do not see italic on screen, that
> may need some set up of fonts, I cannot know. Bold italic I also do
> not see. 

A guess is that the font you're using doesn't show
bold or italic, or at least not well.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 10:26, Jean Louis <bugs@gnu.support> wrote:
> You can open any file and M-x enriched-mode, and then

Thanks, I'll have a look at your suggestions.

> Emacs has already good printing solution. And I get easily PDF
> files. Now how would your solution be useful?

emacs-pdf is written in pure elisp and requires no external
dependencies.

Anything else I have seen requires huge dependencies and painful
configuration (postscript, (la)tex, pandoc).

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-29 01:19]:
> On Mon 28 Dec 2020 at 10:26, Jean Louis <bugs@gnu.support> wrote:
> > You can open any file and M-x enriched-mode, and then
> 
> Thanks, I'll have a look at your suggestions.
> 
> > Emacs has already good printing solution. And I get easily PDF
> > files. Now how would your solution be useful?
> 
> emacs-pdf is written in pure elisp and requires no external
> dependencies.
> 
> Anything else I have seen requires huge dependencies and painful
> configuration (postscript, (la)tex, pandoc).

I see that. Good approach.

Just thinking.

pandoc is one huge dependency that people do not realize as we use
package managers, say "install" and it is just there. But if one wish
to reproduce software, the reproducible build for haskell compiler
from sources is almost impossible task. One has to use binary and then
load huge dependencies for simple conversion. TeX and convertors are
all huge depencies to generate PDF File.

Practically those dependencies are not really problem as we have it
easily accessible on GNU/Linux systems. They may be a problem on
Windoze.

For now `emacs-pdf' is usable for English language. For me using other
characters and other languages it does not work, just as Emacs's
`ps-print-buffer' does not work.

Maybe you could provide PDF printing of all possible characters as in
that case it becomes international.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Tue 29 Dec 2020 at 11:31, Jean Louis <bugs@gnu.support> wrote:
> Maybe you could provide PDF printing of all possible characters as in
> that case it becomes international.

It is on my TODO list:
https://logand.com/sw/emacs-pdf/file/README.html#l52

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 27 Dec 2020 22:28:03 +0100
> 
> When I tried enriched-mode I did not figure out how to use it.

What did you want to accomplish that you couldn't?  Did you look at
etc/enriched.txt?

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 15:47, Eli Zaretskii <eliz@gnu.org> wrote:
> Did you look at etc/enriched.txt?

I'll have a look, thanks.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Eli Zaretskii <eliz@gnu.org> [2020-12-25 11:15]:
>> > Date: Fri, 25 Dec 2020 10:14:40 +0300
>> > From: Jean Louis <bugs@gnu.support>
>> > 
>> > - there are Word importing capabilities by using other available free
>> >   software. Emacs could advise users to install some external software
>> >   to convert from Word.
>
>> I think you underestimate the amount of pressure applied on any
>> J.R. Hacker having a daytime job to use MS Office.  You cannot be a
>> useful and appreciated part of an organization without having to use
>> those tools, because all the correspondence and all the
>> documentation is based on that.  And there's no real Free Software
>> alternative, certainly not based on Emacs.
>
> Since 21 years I use free software. Before that I used proprietary
> Windows and various programs. Already back then I have found all the
> free software to replace anything that I otherwise used on Windows. I
> remember using LyX and writing books and HTML pages with it. That is
> why I cannot share that opinion. I did find what I needed many years
> ago, individually, so other users can also find it.
You know what every person need in every business, and how they use
their computer, and all use cases, businesses etc?

Since you enjoy eating bread and water every day, so should every other
person be happy by living just on bread and water?

>                 I did find what I needed many years
> ago, individually, so other users can also find it.

Because all other human beings have same needs as you? :-)

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

Definitely is possible for every person to fully switch to free software as that is what is GNU about. Not relevant to bread.

Am December 25, 2020 1:23:50 PM UTC schrieb Arthur Miller <arthur.miller@live.com>:
>Jean Louis <bugs@gnu.support> writes:
>
>> * Eli Zaretskii <eliz@gnu.org> [2020-12-25 11:15]:
>>> > Date: Fri, 25 Dec 2020 10:14:40 +0300
>>> > From: Jean Louis <bugs@gnu.support>
>>> > 
>>> > - there are Word importing capabilities by using other available
>free
>>> >   software. Emacs could advise users to install some external
>software
>>> >   to convert from Word.
>>
>>> I think you underestimate the amount of pressure applied on any
>>> J.R. Hacker having a daytime job to use MS Office.  You cannot be a
>>> useful and appreciated part of an organization without having to use
>>> those tools, because all the correspondence and all the
>>> documentation is based on that.  And there's no real Free Software
>>> alternative, certainly not based on Emacs.
>>
>> Since 21 years I use free software. Before that I used proprietary
>> Windows and various programs. Already back then I have found all the
>> free software to replace anything that I otherwise used on Windows. I
>> remember using LyX and writing books and HTML pages with it. That is
>> why I cannot share that opinion. I did find what I needed many years
>> ago, individually, so other users can also find it.
>You know what every person need in every business, and how they use
>their computer, and all use cases, businesses etc?
>
>Since you enjoy eating bread and water every day, so should every other
>person be happy by living just on bread and water?
>
>>                 I did find what I needed many years
>> ago, individually, so other users can also find it.
>
>Because all other human beings have same needs as you? :-)

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Yuri Khan]

On Fri, 25 Dec 2020 at 15:17, Eli Zaretskii <eliz@gnu.org> wrote:

> I think you underestimate the amount of pressure applied on any
> J.R. Hacker having a daytime job to use MS Office.  You cannot be a
> useful and appreciated part of an organization without having to use
> those tools, because all the correspondence and all the documentation
> is based on that.

As a single data point, I have not seen a Word document passed in a
mail attachment in a long time. Most collaboration is now happening in
Google Documents (and Sheets), Dropbox Paper, and Notion. I.e.:
systems where multiple participants can edit and/or comment the same
document simultaneously.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

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

  > As a single data point, I have not seen a Word document passed in a
  > mail attachment in a long time.

Good riddance, but

                                    Most collaboration is now happening in
  > Google Documents (and Sheets), Dropbox Paper, and Notion.

Google Docs is also bad -- because you have to run nonfree software to
talk to it, and you have to identify yourself and sign an unjust
contract ot be allowed to use it.

I never heard of the other three; are they any less bad?

It would be a good thing to write an Emacs interface that can talk to
Google Docs; but if it requires a Google account, I'd still say no.


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

Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[arthur miller]

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

> It would be a good thing to write an Emacs interface that can talk to
> Google Docs; but if it requires a Google account, I'd still say no.

I am affraid there is no way around that one.
________________________________
Från: Emacs-devel <emacs-devel-bounces+arthur.miller=live.com@gnu.org> för Richard Stallman <rms@gnu.org>
Skickat: den 26 december 2020 11:23
Till: Yuri Khan <yuri.v.khan@gmail.com>
Kopia: eliz@gnu.org <eliz@gnu.org>; bugs@gnu.support <bugs@gnu.support>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

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

  > As a single data point, I have not seen a Word document passed in a
  > mail attachment in a long time.

Good riddance, but

                                    Most collaboration is now happening in
  > Google Documents (and Sheets), Dropbox Paper, and Notion.

Google Docs is also bad -- because you have to run nonfree software to
talk to it, and you have to identify yourself and sign an unjust
contract ot be allowed to use it.

I never heard of the other three; are they any less bad?

It would be a good thing to write an Emacs interface that can talk to
Google Docs; but if it requires a Google account, I'd still say no.


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




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

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Yuri Khan]

On Sat, 26 Dec 2020 at 17:23, Richard Stallman <rms@gnu.org> wrote:

>                                     Most collaboration is now happening in
>   > Google Documents (and Sheets), Dropbox Paper, and Notion.
>
> Google Docs is also bad -- because you have to run nonfree software to
> talk to it, and you have to identify yourself and sign an unjust
> contract to be allowed to use it.

Of course you have to identify yourself. It’s a natural consequence of
collaboration, because:

* You want to let a small set of your coworkers to be able to see the
document and comment on it.
* You want an even smaller subset of those to be able to edit it.
* You want to know who made which comment or edit.

(Google also lets you share documents in a way that they can be read,
commented, or edited anonymously, but no one in their right mind will
do that for any kind of sensitive documentation.)

> I never heard of the other three; are they any less bad?

Pretty much the same level of badness. They let an authenticated user
create a document, and share it for viewing, commenting or editing
with other authenticated users. They also provide free-to-use non-Free
UIs for working with those documents, and HTTP-based APIs upon which
alternative clients could be created. Users of such clients would, of
course, have to authenticate themselves, and for security and
convenience reasons that authentication would require executing some
non-Free Javascript.

> It would be a good thing to write an Emacs interface that can talk to
> Google Docs; but if it requires a Google account, I'd still say no.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 18:03, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>> Google Docs is also bad -- because you have to run nonfree software
>> to talk to it, and you have to identify yourself and sign an unjust
>> contract to be allowed to use it.
>
> Of course you have to identify yourself. It’s a natural consequence of
> collaboration, because:
>
> * You want to let a small set of your coworkers to be able to see the
> document and comment on it.
> * You want an even smaller subset of those to be able to edit it.
> * You want to know who made which comment or edit.

None of those points cause having to identify myself to an overseas
entity.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-26 14:53]:
> On Sat 26 Dec 2020 at 18:03, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> >> Google Docs is also bad -- because you have to run nonfree software
> >> to talk to it, and you have to identify yourself and sign an unjust
> >> contract to be allowed to use it.
> >
> > Of course you have to identify yourself. It’s a natural consequence of
> > collaboration, because:
> >
> > * You want to let a small set of your coworkers to be able to see the
> > document and comment on it.
> > * You want an even smaller subset of those to be able to edit it.
> > * You want to know who made which comment or edit.
> 
> None of those points cause having to identify myself to an overseas
> entity.

I agree on that.

We have in Emacs various free software collaborative editing solutions
included latest crdt.el: https://code.librehq.com/qhong/crdt.el.git

There is also etherpad: https://etherpad.org/ for online
collaboration.

In general, supporting collaboration with non-free software based
solutions should always come after we have the free software solution
in the first place.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

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

  > > Of course you have to identify yourself. It’s a natural consequence of
  > > collaboration, because:...

  > None of those points cause having to identify myself to an overseas
  > entity.

It's natural that I should somehow identify myself to those I
collaborate with.  Maybe to an organization we are doing the work for.
But not for Google!

And we should not have to accept Google's terms.

-- 
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 (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

> This is why it would be useful to have this kind of capabilities in
> Emacs: to enable users to visit MS Office documents with "C-x C-f",
> edit them in some specialized WYSIWYG Emacs mode, and finally save
> them with "C-x C-s".  If under the hood this runs some converters, it
> doesn't matter.

Note that this will never be perfect so we need some nuance here and
perhaps address useful use-cases.

> And there's no real Free Software alternative, certainly not based on
> Emacs.

There are and there could be.

Here a rough list of use-cases with increasing complexity:

1) Reading abw, docx and odt documents as text is very simple in Emacs
   without any extra dependencies:
   https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html

2) Reading them as graphics documents is also pretty simple with some
   extra dependencies:
   https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html

3) Another use-case is to save a buffer to office document.  This should
   be pretty simple to implement too.

4) Another use-case is to open, edit and save existing office document
   and preserve as much original stuff as possible.  This should be
   possible but lots of work.

5) Another use-case is WYSIWYG 3).

6) Another use-case is WYSIWYG 4).

Dealing with office formats is not a pleasant experience so I am
skeptical that volunteers will devote so much time to the use-cases with
the highest complexity.  It would therefore be good to make Emacs useful
at least for the low complexity use-cases.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Arthur Miller]

Tomas Hlavaty <tom@logand.com> writes:

>> This is why it would be useful to have this kind of capabilities in
>> Emacs: to enable users to visit MS Office documents with "C-x C-f",
>> edit them in some specialized WYSIWYG Emacs mode, and finally save
>> them with "C-x C-s".  If under the hood this runs some converters, it
>> doesn't matter.
>
> Note that this will never be perfect so we need some nuance here and
> perhaps address useful use-cases.
>
>> And there's no real Free Software alternative, certainly not based on
>> Emacs.
>
> There are and there could be.
>
> Here a rough list of use-cases with increasing complexity:
>
> 1) Reading abw, docx and odt documents as text is very simple in Emacs
>    without any extra dependencies:
>    https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html
>
> 2) Reading them as graphics documents is also pretty simple with some
>    extra dependencies:
>    https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html
>
> 3) Another use-case is to save a buffer to office document.  This should
>    be pretty simple to implement too.
>
> 4) Another use-case is to open, edit and save existing office document
>    and preserve as much original stuff as possible.  This should be
>    possible but lots of work.
>
> 5) Another use-case is WYSIWYG 3).
>
> 6) Another use-case is WYSIWYG 4).

The problem with documents in MS office is not text extraction; it is
just xml nowadays anyway, the problem is countless VBA scripts that
business and organisations run in Excell/Access/Word that just can't be
translate to Libre. Libre has VB, but the underlaying objects are not
there and lots of tools out there that people use can't be just
automatically translated.

I have worked in big organisation and did lots of automation for MS
office and databases.

> Dealing with office formats is not a pleasant experience so I am
> skeptical that volunteers will devote so much time to the use-cases with
> the highest complexity.

What is not so pleasant? New formats (marked with x) at the end are all
xml, so it is just dealing with xml, sinilar to odt. I see nothing hard
there and it is not that I defend Microsoft, I just don't see what you
are talking about. That is part that alternatives you mention do.

>               there could be.

You are correct about one thing: there could be free alternative.
All that will probably change in next 20 ~ 30 years, but we are not
there yet.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 14:19, Arthur Miller <arthur.miller@live.com> wrote:
> The problem with documents in MS office is not text extraction; it is
> just xml nowadays anyway, the problem is countless VBA scripts that
> business and organisations run in Excell/Access/Word that just can't
> be translate to Libre. Libre has VB, but the underlaying objects are
> not there and lots of tools out there that people use can't be just
> automatically translated.
>
> I have worked in big organisation and did lots of automation for MS
> office and databases.

So what?  I do not understand what are you trying to say.

I tried to get the point across that it is not all or nothing problem.
There are use-cases which bring lots of value and are achievable with
reasonable effort.

>> Dealing with office formats is not a pleasant experience so I am
>> skeptical that volunteers will devote so much time to the use-cases
>> with the highest complexity.
>
> What is not so pleasant? New formats (marked with x) at the end are
> all xml, so it is just dealing with xml, sinilar to odt. I see nothing
> hard there and it is not that I defend Microsoft, I just don't see
> what you are talking about. That is part that alternatives you mention
> do.

Just because something is a zip file with some xml files inside does not
make it "not hard", "just dealing with xml".  It is complex to do
non-trivial stuff.  If you do not see what I am talking about, try to
implement something non-trivial (for example merge many docx documents
into one).  You'll understand why it is not a pleasant experience and
why I do not think anybody will do that in their free time.

>>               there could be.
>
> You are correct about one thing: there could be free alternative.
> All that will probably change in next 20 ~ 30 years, but we are not
> there yet.

It is not clear to me about which use-case are you talking in this
prediction.

1) There are use-cases, for which there are solutions now, as I already
   shown.

2) There are use-cases, for which solutions could be implemented with
   reasonable effort.

3) There are use-cases, which will very likely never have an
   alternative.

For 1) I did my best.

For 2) we'll see what I will do;-)

For 3) I wish you good luck!

Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[arthur miller]

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

> Just because something is a zip file with some xml files inside does not
> make it "not hard", "just dealing with xml".  It is complex to do
> non-trivial stuff.  If you do not see what I am talking about, try to
> implement something non-trivial (for example merge many docx documents
> into one).  You'll understand why it is not a pleasant experience and
> why I do not think anybody will do that in their free time.

We obviously have different understanding on what is hard. I considering something
to be hard if there is not a well-known solution you can take and apply to implement
the functionality. Or if there are very many  obscure details that have to be taken into
account. I don't consider working with standardized xml format to get into that
category. LibreOffice does quite good job of translating docx stuff you wrote about.

There is a difference between hard and labourus. I would say it is a lot of work not very
hard.

You should be able to open docx files, parse them with elisp and display text or even render
graphics to svg. I did some similar long time ago with Java.I think it is a lot of work, but not
very interesting. I wouldnt say it is unpleasant, it is certainly much better to work with a
documented standardized ooxml then with some undocumented old format. I probably
wouldn't say unpleasant, just very boring.

So if you are gonna go do it, please, it will be great thing if you implement it.

Good luck .
________________________________
Från: Tomas Hlavaty <tom@logand.com>
Skickat: den 25 december 2020 15:44
Till: Arthur Miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

On Fri 25 Dec 2020 at 14:19, Arthur Miller <arthur.miller@live.com> wrote:
> The problem with documents in MS office is not text extraction; it is
> just xml nowadays anyway, the problem is countless VBA scripts that
> business and organisations run in Excell/Access/Word that just can't
> be translate to Libre. Libre has VB, but the underlaying objects are
> not there and lots of tools out there that people use can't be just
> automatically translated.
>
> I have worked in big organisation and did lots of automation for MS
> office and databases.

So what?  I do not understand what are you trying to say.

I tried to get the point across that it is not all or nothing problem.
There are use-cases which bring lots of value and are achievable with
reasonable effort.

>> Dealing with office formats is not a pleasant experience so I am
>> skeptical that volunteers will devote so much time to the use-cases
>> with the highest complexity.
>
> What is not so pleasant? New formats (marked with x) at the end are
> all xml, so it is just dealing with xml, sinilar to odt. I see nothing
> hard there and it is not that I defend Microsoft, I just don't see
> what you are talking about. That is part that alternatives you mention
> do.

Just because something is a zip file with some xml files inside does not
make it "not hard", "just dealing with xml".  It is complex to do
non-trivial stuff.  If you do not see what I am talking about, try to
implement something non-trivial (for example merge many docx documents
into one).  You'll understand why it is not a pleasant experience and
why I do not think anybody will do that in their free time.

>>               there could be.
>
> You are correct about one thing: there could be free alternative.
> All that will probably change in next 20 ~ 30 years, but we are not
> there yet.

It is not clear to me about which use-case are you talking in this
prediction.

1) There are use-cases, for which there are solutions now, as I already
   shown.

2) There are use-cases, for which solutions could be implemented with
   reasonable effort.

3) There are use-cases, which will very likely never have an
   alternative.

For 1) I did my best.

For 2) we'll see what I will do;-)

For 3) I wish you good luck!

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

Re: Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Stefan Monnier]

> LibreOffice does quite good job of translating docx stuff you wrote about.

Last I checked, LibreOffice still wasn't able to edit a "docx" file
without losing significant formatting information in real-life cases.

And I don't mean it as a criticism of LibreOffice.
The "docx" format is not nearly as "documented" as you think it is.

As for the original problem: I'm pretty sure it'd be hard enough to
solve the problem for ODT documents, so I'd focus on that first (and
leave the compatibility with formats that are actively designed to be
hard to support (like docx) to other tools).


        Stefan

Sv: Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[arthur miller]

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

I didn't had to work with office documents for few years, so I can't tell how it looks like now,
but what parts of text formatting does not work? They use to convert it pretty decently
before. As I remember it was usually if forms and scripts and graphics were involved that
it didn't work well, but simple text formatting worked well. I never wanted to pay for MS
Office, so I used at home open/libre office and was rarely founding a troublesome file.

I have no opinion on what should be done first at all. I was just reflecting on "unpleasant to
work with". ODT might be easier to work with sure. Problem with ooxml is that MS is not
really sticking to the specification and is doing things differently themselves, so Libre has to
emulate parts that are different then the standard MS specified themselves.
________________________________
Från: Stefan Monnier <monnier@iro.umontreal.ca>
Skickat: den 25 december 2020 22:08
Till: arthur miller <arthur.miller@live.com>
Kopia: Tomas Hlavaty <tom@logand.com>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

> LibreOffice does quite good job of translating docx stuff you wrote about.

Last I checked, LibreOffice still wasn't able to edit a "docx" file
without losing significant formatting information in real-life cases.

And I don't mean it as a criticism of LibreOffice.
The "docx" format is not nearly as "documented" as you think it is.

As for the original problem: I'm pretty sure it'd be hard enough to
solve the problem for ODT documents, so I'd focus on that first (and
leave the compatibility with formats that are actively designed to be
hard to support (like docx) to other tools).


        Stefan


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

Re: Sv: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 16:08, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Last I checked, LibreOffice still wasn't able to edit a "docx" file
> without losing significant formatting information in real-life cases.

Exactly.

And it will likely never be able to do that.

One example: numbering restarts.  ODT cannot do stuff DOCX can.  Unless
LibreOffice works towards some kind of superset of both formats, this
will not work.

> The "docx" format is not nearly as "documented" as you think it is.

That's one important issue.  There are other as well.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

Thank you.

How do I download the software from:
https://logand.com/sw/ ?

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 16:49, Jean Louis <bugs@gnu.support> wrote:
> How do I download the software from:
> https://logand.com/sw/ ?

I usually document that in the el file:
https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html#l11
   
   Download: git clone https://logand.com/git/emacs-unoffice.git

For example:

   $ git clone https://logand.com/git/emacs-unoffice.git
   $ git clone https://logand.com/git/emacs-pdf.git
   $ git clone https://logand.com/git/emacs-framebuffer.git

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-25 18:02]:
> On Fri 25 Dec 2020 at 16:49, Jean Louis <bugs@gnu.support> wrote:
> > How do I download the software from:
> > https://logand.com/sw/ ?
> 
> I usually document that in the el file:
> https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html#l11
>    
>    Download: git clone https://logand.com/git/emacs-unoffice.git

I found it, thank you. First I tried logging the single script you
have shown, there was nothing about cloning written on the page, but
then I browsed up the hierarchy and found it.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eric S Fraga]

Your unoffice.el requires archive-zip-extract which I cannot
find.  Would you please point me to the right package to install to have
that?

Thank you,
eric

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.3 on Debian bullseye/sid

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 11:44, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Your unoffice.el requires archive-zip-extract which I cannot find.
> Would you please point me to the right package to install to have
> that?

Hmm, it is part of official emacs.  I can find it in
/nix/store/lhmscyq5a9ibspdhyivrdgkhla7lpi3q-emacs-26.3/share/emacs/26.3/lisp/arc-mode.el.gz
on my system and also greping the emacs repository.

Could you try

   (require 'arc-mode)

and then load emacs-unoffice.el again?

Maybe I just need to put the require there.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eric S Fraga]

On Monday, 28 Dec 2020 at 13:22, Tomas Hlavaty wrote:
> Could you try
>    (require 'arc-mode)

This does the job.  Thank you.  Maybe add this line to
emacs-unoffice.el?  I would have thought that it would be good to have
dependencies automatically included.

thank you,
eric

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.3 on Debian bullseye/sid

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 12:37, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> On Monday, 28 Dec 2020 at 13:22, Tomas Hlavaty wrote:
>> Could you try
>>    (require 'arc-mode)
>
> This does the job.  Thank you.  Maybe add this line to
> emacs-unoffice.el?  I would have thought that it would be good to have
> dependencies automatically included.

It is fixed now.  I have added require for arc-mode and xml.  You can
git pull and reload emacs-unoffice.el and it should work.  Thanks for
letting me know.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Eric S Fraga]

On Monday, 28 Dec 2020 at 17:25, Tomas Hlavaty wrote:
> It is fixed now.

Excellent.  Thank you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.3-152-g713b3b

[pandoc] (was: Emacs as a word processor (ways to convert Word/RTF proprietary files))

[Uwe Brauer]

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

>>> "TH" == Tomas Hlavaty <tom@logand.com> writes:

   > git clone https://logand.com/git/emacs-unoffice.git

I was forced since some years to inter-operate with xlsx and docx files.

    1. xlsx files can usually very easily be converted to org mode (without
       the excel formulas)

    2. The best solution to convert docx was usually via pandoc
       (sometimes libreoffice gave better results).

    3. I wrote some trival lisp wrappers for that purpose.

    4. However while xlsx-->org-->xlsx work reasonable well, the same
       cannot be said for docx-->org-->docx

Seems to me more useful that this short lisp hack that I tested with a
couple of docx files and most of them resulted in not very useful buffers.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: [pandoc] (was: Emacs as a word processor (ways to convert Word/RTF proprietary files))

[Stefan Kangas]

Uwe Brauer <oub@mat.ucm.es> writes:

>     2. The best solution to convert docx was usually via pandoc
>        (sometimes libreoffice gave better results).

Thanks, this is useful information.

Does pandoc convert from docx to org-mode?

Does libreoffice?

>     4. However while xlsx-->org-->xlsx work reasonable well, the same
>        cannot be said for docx-->org-->docx

What problems did you encounter with docx-->org-->docx?

Did you try odt-->org-->odt?

Perhaps Someone (TM) should write up a GNU ELPA package that does all
the required steps with pandoc transparently.  Provided it works well
enough with at least odt, it would at least solve most of my needs.

Re: [pandoc]

[Uwe Brauer]

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

>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> 2. The best solution to convert docx was usually via pandoc
>> (sometimes libreoffice gave better results).

> Thanks, this is useful information.

> Does pandoc convert from docx to org-mode?

Yes of course.

> Does libreoffice?

Of course, there is even a command line command.

>> 4. However while xlsx-->org-->xlsx work reasonable well, the same
>> cannot be said for docx-->org-->docx

> What problems did you encounter with docx-->org-->docx?


Loss of formats, especially colors (I am talking here about a real wired
document that looks fine in MS Word (but in no other processor I have
knowledge of). The reason it is was created in 1996, by a visual
approach without any styles. This situation is more common than one
might think.


> Did you try odt-->org-->odt?

Again, it depends on the original document, if it contains sophisticated
headers, a lot of colors etc, then no, if its a simple well structured
document with different sections, table of contents and tables then yes.

> Perhaps Someone (TM) should write up a GNU ELPA package that does all
> the required steps with pandoc transparently.  Provided it works well
> enough with at least odt, it would at least solve most of my needs.


I will look later what I have, and can send it to your privately if you desire.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: [pandoc] (was: Emacs as a word processor (ways to convert Word/RTF proprietary files))

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 14:37, Uwe Brauer <oub@mat.ucm.es> wrote:
> that I tested with a couple of docx files and most of them resulted in
> not very useful buffers.

Could you be more specific?

Re: [pandoc]

[Uwe Brauer]

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

>>> "TH" == Tomas Hlavaty <tom@logand.com> writes:

> On Mon 28 Dec 2020 at 14:37, Uwe Brauer <oub@mat.ucm.es> wrote:
>> that I tested with a couple of docx files and most of them resulted in
>> not very useful buffers.

> Could you be more specific?

Well I obtained an empty buffer. However, I restarted emacs and then, at
least for the docx I tested, I see simple completely unformatted text.
Tables are converted into single column etc. But it works, somehow (no
insult intended).

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: [pandoc]

[Tomas Hlavaty]

On Mon 28 Dec 2020 at 18:07, Uwe Brauer <oub@mat.ucm.es> wrote:
> Well I obtained an empty buffer. However, I restarted emacs and then,

Restarting Emacs should not be needed.

> at least for the docx I tested, I see simple completely unformatted
> text.  Tables are converted into single column etc. But it works,
> somehow (no insult intended).

Yes, it shows docx as plain text and the only formatting it tries to do
is to separate paragraphs.

Maybe tables could be added and formatted using org-table-align.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 16:57, Jean Louis <bugs@gnu.support> wrote:
> I could git clone some of them, I was thinking to download single
> file. Useful software really.

Those packages are single el file.

If you do not want to use git:

M-x eww
https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html

and then cut out the header and left rectangle and save it as
emacs-unoffice.el

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-25 18:07]:
> On Fri 25 Dec 2020 at 16:57, Jean Louis <bugs@gnu.support> wrote:
> > I could git clone some of them, I was thinking to download single
> > file. Useful software really.
> 
> Those packages are single el file.
> 
> If you do not want to use git:
> 
> M-x eww
> https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html
> 
> and then cut out the header and left rectangle and save it as
> emacs-unoffice.el

I know how to do that and that was exactly that I wanted to avoid, now
I found the way.

By the way, git clone --depth 1 is not working well.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 09:35, Jean Louis <bugs@gnu.support> wrote:
> By the way, git clone --depth 1 is not working well.

Interesting, thanks for letting me know.

$ git clone --depth 1 https://logand.com/git/emacs-unoffice.git
Cloning into 'emacs-unoffice'...
fatal: dumb http transport does not support shallow capabilities

Not sure what I can do about that.  Seems like git limitation.

   --depth <depth>
       Create a shallow clone with a history truncated to the
       specified number of commits.

I don't think you need to worry about that.  The repositories are tiny.

I hope you find it useful.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Amin Bandali]

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

Tomas Hlavaty writes:

> On Sat 26 Dec 2020 at 09:35, Jean Louis <bugs@gnu.support> wrote:
>> By the way, git clone --depth 1 is not working well.
>
> Interesting, thanks for letting me know.
>
> $ git clone --depth 1 https://logand.com/git/emacs-unoffice.git
> Cloning into 'emacs-unoffice'...
> fatal: dumb http transport does not support shallow capabilities
>
> Not sure what I can do about that.  Seems like git limitation.
>
[...]

More precisely, a limitation of git's 'dumb http' mode of transport.
To remedy that, you can configure your web server to pass git-related
requests through git-http-backend for 'smart http', which among other
things, has the benefit of displaying the progress of the various stages
of cloning as well.  I'd be happy to chat more about this off-list.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 20:39, Amin Bandali <bandali@gnu.org> wrote:
> More precisely, a limitation of git's 'dumb http' mode of transport.
> To remedy that, you can configure your web server to pass git-related
> requests through git-http-backend for 'smart http', which among other
> things, has the benefit of displaying the progress of the various
> stages of cloning as well.  I'd be happy to chat more about this
> off-list.

Thanks for the info.  I am not sure I want to install that on the
server.  http seems enough.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[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 think you underestimate the amount of pressure applied on any
  > J.R. Hacker having a daytime job to use MS Office.

I am sure you know what you're talking about, but I've been able to
convince everyone who sends me a document to send it to me in a non-Word
format.

So you should not give up without an effort.

-- 
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 (ways to convert Word/RTF proprietary files)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bugs@gnu.support, emacs-devel@gnu.org
> Date: Sat, 26 Dec 2020 05:23:00 -0500
> 
>   > I think you underestimate the amount of pressure applied on any
>   > J.R. Hacker having a daytime job to use MS Office.
> 
> I am sure you know what you're talking about, but I've been able to
> convince everyone who sends me a document to send it to me in a non-Word
> format.
> 
> So you should not give up without an effort.

I didn't.

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

[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 sure you know what you're talking about, but I've been able to
  > > convince everyone who sends me a document to send it to me in a non-Word
  > > format.
  > > 
  > > So you should not give up without an effort.

  > I didn't.

I am glad you didn't.  I am urging others to give it a good try, too.

-- 
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 (ways to convert Word/RTF proprietary files)

[Stefan Monnier]

> I am sure you know what you're talking about, but I've been able to
> convince everyone who sends me a document to send it to me in a non-Word
> format.

Indeed, it's usually easy to do that when the one who sends it wants
something from you.  OTOH it's often much harder when it's the other
way around.


        Stefan

Re: Emacs as a word processor (ways to convert Word/RTF proprietary files)

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

  > Indeed, it's usually easy to do that when the one who sends it wants
  > something from you.  OTOH it's often much harder when it's the other
  > way around.

You're right, of course, but I've succeeded even in other kinds of
situations.

I'm not saying it is always possible -- but one may as well try.

-- 
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 (ways to convert Word/RTF proprietary files)

[Uwe Brauer]

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

>>> "RS" == 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. ]]]

>> I think you underestimate the amount of pressure applied on any
>> J.R. Hacker having a daytime job to use MS Office.

> I am sure you know what you're talking about, but I've been able to
> convince everyone who sends me a document to send it to me in a non-Word
> format.

I envy you for that. 
It might work, if you don't have to modify these files.

But I have, unfortunately, to collaborate in my department sometimes
with docx files, that are sent to me and I have to open, modify and send
them back. 

All conversions to open formats were not completely faithful (no wounder
if the format is not even properly specified to the public).

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

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