Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Milan Glacier <news@milanglacier.com> [2023-01-18 21:06]:
> I don't use gnus.
> 
> > 11. What are the benefits compared to thunderbird?
> > A. Only the keybindings of Emacs I can use and in knowing them it will      
> > be easier in future to handle it?
> > B. It is within emacs and uses less CPU
> > C......
> 
> I don't use thunderbird. But emacs/cli based emails clients generally
> have common merits over GUI client:
> 
> - They are keyboard centric.

That some application is "keyboard centric" is not a merit over GUI
client which is maybe assumed not to be keyboard centric. In fact,
being "keyboard centric" impairs usability. 

Doug Engelbart invented mouse device for people to speed up with
work. Using mouse is just fine.

And among all Thunderbird has all the keys that user may need:
https://support.mozilla.org/en-US/kb/keyboard-shortcuts-thunderbird?redirectslug=keyboard-shortcuts&redirectlocale=en-US

Thunderbird as application is out of Emacs world. Not comparable
really. While I find Thunderbird bloated, its usability is high, can't
be compared to impaired Emacs.

> - You can manipulate emails buffers just like normal text buffers.

And? How is that merit over Thunderbird or general GUI clients? You
can make text snapshot of the buffer and save it, while in Thunderbird
user can make screenshot and save it. That is of no benefit for
average user.

> - Integration with other emacs facilities like orgmode, pdftools,
>   xwidget stuff.

Any Thunderbird user may configure it fast to open Org files with
Thunderbird. Thunderbird user may use Emacs to edit e-mails. 

I can't see why would be "merit over GUI mail clients" to use
xwidgets, those are programmer tools.

If we speak of various "integrations", then first count the number of
Thunderbird extensions like 1621 on:
https://addons.thunderbird.net/en-US/thunderbird/search/?q=&cat=1%2C0&appver=&platform=

and then review what is really "merit" among mail clients.

> - They offer you more flexible and powerful way to manipulate, search
>   and index your emails.

It is way too exaggerated and generalized statement. The "powerful
way" in any software comes with experience. To learn what you think is
powerful requires maybe decades. 

GUI clients like Thunderbrd have their ways to manipulate, search and
index emails just as well -- and without confronting users who wish to
read and send emails to learn about what? Xapian database, indexing,
etc. They simply do it for the user.

While there is great joy in programming for programmers, not everybody
is.

Purpose of computer is to help human life. 

Purpose of communication program is to help in human communicaton.

While I may have joy in understanding how that communication is
transferred, my auntie has not get time for that, and she simply wish
to greet her grandchildren.

"powerful way" may waste years, decades of life, and will recursively
ask for its re-confirmation because of that waste of time. 

Then a kid will sit on computer and show you that things can be done
with GUI mail clients.
 
> - It has pretty decent integration with notmuch (that is: you can index
>   your emails efficiently).

Memory works by association. Relations. Connections. The purpose of
indexing is to help human who knows some of keys relevant to
association to find other keys or other objects.

That is for reason that they do not follow most natural principles of
sorting and order, something that grandmothers knew how to do it.

Open up address book in Thunderbird, find an entry something like:

,----
| WRITE    SEARCH
| 
| Joe Doe
`----

There will be two hyperlinks to WRITE e-amil and SEARCH, which means
user clicks on Joe Doe and almost in instant gets e-mails related to
Joe Doe, and may include other terms to find relevant emails. It means
it is already indexed. Thunderbird knows about it.

That people shall see conversation related to person Joe Doe is such a
natural notion, too often forgotten by many e-mail programs.

That indexing feature exist is feature for 2000, not for 2023, where
it is expected that those features exist.

It is impairment that user needs to think of those
features. Impairments come back from time where things were not much
integrated and because console programs do not develop speedy, they
more or less remain in their original design.

About writing in "Org mode", there is no special advantage for people
who use e-mail unless those people are Emacs users. To draw somebody
to be Emacs user into Org mode is getting person in trouble. 

E-mails in general do not arrive in Org mode. 

Greater benefit would be for Emacs users to be able to visually edit
HTML mode, that would be comparatively good.

> * mu4e
> 
> - It has decent integration with orgmode. (store links to email in
>   orgmode, open email links in orgmode, and compose html emails by
>   orgmode).

Storing links to email is important feature that only few mail clients
support. 

Though any storage to any references shall be independent of the
tool, independent of Emacs or mail clients, so that any mail client
can use the hyperlink stored somewhere to open the referenced email,
not only emails but all kinds of stored hyperlinks.

Sadly we are not that far, maybe 100 years before that would ever
happen.

Composing HTML emails by Org mode is not some special feature. As
whatever can be done in external editors, can also be included in
Thunderbird, Kmail, Evolution, they allow usage of external editors,
including Emacs, can edit buffers with external editor.

I was editing this e-mail in Emacs just to test some of my functions,
with the external editor. Try it out. Often user may feel relief by
using other editors, that feeling may be helpful to discover what is
wrong in Emacs.

(defcustom rcd-external-editor "mousepad"
  "The external editor as an option for some functions."
  :group 'rcd
  :type 'string)

(defun string-to-file-force (string file)
  "Prints string into file, matters not if file exists. Return FILE as file 
name."
  (with-temp-file file
    (insert string))
  file)

(defun rcd-edit-with-external-editor (&optional text)
  "Editing with external editor as defined in `rcd-external-editor'.

It will either edit the optional TEXT as string
argument. Otherwise it will edit the current buffer and replace
it with the result."
  (interactive)
  (let* ((buffer-or-text (not text))
         (text (if buffer-or-text (buffer-substring-no-properties (point-min) 
(point-max)) text))
         (point (point))
         ;; (mode major-mode)
         (file (concat (or (getenv "TMPDIR") "/tmp/") "temp-file")))
    (string-to-file-force text file)
    (call-process rcd-external-editor nil nil nil file)
    (if buffer-or-text 
        (progn
          (erase-buffer)
          (insert-file-contents file)
          (goto-char point))
      (file-to-string file))))

> - It **can't** fold threads. If you are reading mailing list, you
>   probably will get overwhelmed by the incoming flood of emails. This is
>   the only cons I have with mu4e.

mu4e is not meant to be e-mail client, rather interface to mu indexer,
but it developed in good direction. 

> - It renders html emails pretty decent (Say thanks to shr.el). In case
>   you are not satisfied, you can also open the HTML emails by GUI
>   browser or even emacs' xwidget.

In the mail client world people don't even know that there is HTML,
they simply see it and don't think about it.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/