unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Milan Glacier <news@milanglacier.com>
To: Gottfried <gottfried@posteo.de>,
	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: Debunking Emacs merits over GUI - Re: package for Email
Date: Thu, 19 Jan 2023 11:10:30 -0500	[thread overview]
Message-ID: <20230119161030.vt4muwcdvuwdqmj7@zoho.com> (raw)
In-Reply-To: <Y8jP5pDoO9Cp7Gzr@protected.localdomain>

On 01/19/23 08:06, Jean Louis wrote:
>* 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.

Yes you are right. I am biased here. Keyboard-centric is not merit, it
is just a feature.

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

Generally vim/emacs are considered the most powerful editors to edit
text. With mutt you can easily edit those text within emacs/vim just in
one or two keystrokes. And with mu4e/gnus/wanderlast you can directly
edit them within emacs.

As you have said, if you want to edit mails from GUI client, you have to
firstly save a copy of messages and then open it in emacs/vim.

It has no benifit for average user. Yes. But the OP already uses emacs,
which means that easily using emacs to edit mail buffer as text buffer
may be a merit to him/her.

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

Thanks for your clarification, thunderbird does something pretty good
here. I don't use thunderbird but I believe you can't to those things
easily with other GUI email clients like say: Apple Mail.

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

You are right, xwidget is not a merit. I am just mentioning one of the
emacs' builtin feature. So that you can read your emails within emacs,
you don't need to open GUI browser. (The OP already uses emacs).

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

Yes you are right. Average users won't feel it is powerful than GUI
client. GUI client already satisfies the indexing and searching need for
most of the user. That is the price of powerfulness, it takes time to
learn. The same statement also applies to emacs and other text editor.
But an average user won't use emacs as its text editor. An average user
writes proses use MS Word.

> [...]

Starting from the following, I am talking about my own impression of the
email clients I am using. I didn't talk about the merit of CLI based
program and GUI client anymore. So any of my following statements
**doesn't imply "those things are better than that GUI client can do"**.

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

I didn't make comparison with GUI here. It is just my own impression.

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

Folding threads is the duty of a UI. And mu4e is the UI of the
mu indexer. Mu indexer has done all of its job: marking all of the
related messages into one thread. 

With the information of threads, the UI needs to: fold all of the
messages and only show you the head messages of the thread. Notmuch
(emacs frontend) and mutt did it pretty well.
>
>> - 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.

Yes you are right. But in the context I was speaking this, I implied
that I am making comparison between mutt and mu4e/notmuch. GUI clients
are not related to my statement here.



  parent reply	other threads:[~2023-01-19 16:10 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 13:56 package for Email Gottfried
2023-01-18 14:44 ` Eric Brown
2023-01-18 15:15 ` Jean Louis
2023-01-19  7:31   ` Tomas Hlavaty
2023-01-19  7:55     ` Jean Louis
2023-01-18 15:51 ` Tassilo Horn
2023-01-18 17:17   ` Eli Zaretskii
2023-01-18 17:58     ` andrés ramírez
2023-01-19  3:55       ` Jean Louis
2023-01-18 16:28 ` Andreas Eder
2023-01-18 18:03 ` Milan Glacier
2023-01-19  4:02   ` Jean Louis
2023-01-19  5:06   ` Debunking Emacs merits over GUI - " Jean Louis
2023-01-19  5:41     ` Emanuel Berg
2023-01-19 13:00       ` Jean Louis
2023-01-19 15:34         ` Marcin Borkowski
2023-01-20  8:27           ` Jean Louis
2023-01-19 16:10     ` Milan Glacier [this message]
2023-01-19 16:52       ` Jude DaShiell
2023-01-20  9:32         ` Jean Louis
2023-01-19 21:10       ` Bob Newell
2023-01-20  9:47         ` Jean Louis
     [not found]           ` <877cxgrc3e.mmmtqrm@thhcbmmmd.mijofcrcc.org>
2023-01-21  7:05             ` Jean Louis
2023-01-21  7:20               ` Emanuel Berg
2023-01-21  7:21               ` Eli Zaretskii
2023-01-21  7:28                 ` Emanuel Berg
2023-01-21 14:29                   ` Jean Louis
2023-01-21 14:28                 ` Jean Louis
2023-01-21 15:31                   ` Eli Zaretskii
2023-01-21 17:30                     ` Bob Newell
2023-01-22 15:40                       ` Jean Louis
2023-01-20  9:07       ` Jean Louis
2023-01-20 15:52         ` Milan Glacier
2023-01-21  6:04     ` History " David Masterson
2023-01-21  7:10       ` Eli Zaretskii
2023-01-21  7:21         ` Emanuel Berg
2023-01-21  7:34         ` tomas
2023-01-21 17:38         ` Bob Newell
2023-01-22  3:16           ` David Masterson
2023-01-22 15:48           ` Jean Louis
2023-01-22  3:08         ` David Masterson
2023-01-22  6:23           ` Eli Zaretskii
2023-01-22 19:33             ` David Masterson
2023-01-22 19:57               ` Eli Zaretskii
2023-01-22  7:45           ` Po Lu
2023-01-22 19:35             ` David Masterson
2023-01-21 14:35       ` Jean Louis
2023-01-22  3:33         ` David Masterson
2023-03-10 17:16       ` Emanuel Berg
2023-03-13  8:32         ` Po Lu
2023-01-18 18:10 ` Filipp Gunbin
2023-01-19  2:15 ` Emanuel Berg
2023-01-19 12:40   ` Jean Louis
2023-01-19 14:10   ` Martin Steffen
2023-01-19 16:20     ` Eric S Fraga
2023-01-19 16:39       ` Jude DaShiell
2023-01-20 10:05         ` Jean Louis
2023-01-19 17:00       ` Leo Butler
2023-01-19 17:35         ` Eric S Fraga
2023-01-20  6:48       ` Milan Glacier
2023-01-19  3:53 ` Jean Louis
2023-01-19  6:08 ` John Haman
2023-01-19 11:52   ` Emanuel Berg
2023-01-21 13:57     ` Jean Louis
2023-01-21 15:08       ` Jude DaShiell
2023-01-21 17:47       ` Bob Newell
2023-01-22  3:46         ` David Masterson
2023-01-22 19:52           ` Bob Newell
2023-01-22  3:34     ` David Masterson
2023-01-31  5:46       ` Emanuel Berg
2023-01-20  4:09   ` Milan Glacier
2023-01-20  7:31     ` Emanuel Berg
2023-01-20 10:26     ` Jean Louis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230119161030.vt4muwcdvuwdqmj7@zoho.com \
    --to=news@milanglacier.com \
    --cc=gottfried@posteo.de \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).