package for Email

package for Email

[Gottfried]

[-- Attachment #1.1.1: Type: text/plain, Size: 1266 bytes --]

Hi everybody,

I am using thunderbird for emails.
My question:

1. Which Email package do you use?
Can you tell your experience with your email package?

2. Does it make sense for me as an emacs-newbie to change from using 
thunderbird to an emacs email package?

3. There are
Rmail, GNU, Wanderlust, Mu4e etc...

4. I prefer to habe folders because I like to have an overview.
Mu4e doesn't have folders.

5. I want IMAP.
Do all of them provide IMAP? (does Rmail now provide IMAP)?

6. Wanderlust seems to be more difficult to set up, and I still have 
trouble because I am an Emacs-newbie.

7. Which one is easier to use?

8. Should I start with Rmail? and later switch to GNU?

At the moment I don't need GNU for reading news etc...

9. Or is it useful to start with GNU because it has more options and I 
have to learn it anyhow? and I can use it with org-mode?

10. Do all of them have the same or similar keybindings or do I have to 
learn for each one separate keybindings?

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


Kind regards

Gottfried


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3191 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: package for Email

[Eric Brown]

Gottfried <gottfried@posteo.de> writes:

> Hi everybody,
>
> I am using thunderbird for emails.
> My question:
>
> 1. Which Email package do you use?
> Can you tell your experience with your email package?
>

I enjoy using Emacs for email. The main issue is that (corporate/work)
providers seem to be locking down user/password access which precludes
easy connection.

> 2. Does it make sense for me as an emacs-newbie to change from using thunderbird
> to an emacs email package?
>

Not unless you need:

* Advanced Email Processing
* Text-based interface to email (where GUI-restricted thunderbird is not
* an option)

> 3. There are
> Rmail, GNU, Wanderlust, Mu4e etc...
>

I've used all of them, and they are all pretty good. I use Gnus because
I started emacs when Usenet was big.  Gnus can (fortuitously) manage
IMAP and other mail box formats.

I use Gnus for my "email" and Rmail I usually configure to manage the
mail on the current system that I am working on, i.e. the mail spool

> 4. I prefer to habe folders because I like to have an overview.
> Mu4e doesn't have folders.
>

You have to evaluate for yourself if this is a blocker, but that would
sound like one to me.  I'd confirm this to be the case though.

> 5. I want IMAP.
> Do all of them provide IMAP? (does Rmail now provide IMAP)?
>

Yes, practically for Rmail you need mailutils compiled with tls support.

> 6. Wanderlust seems to be more difficult to set up, and I still have trouble
> because I am an Emacs-newbie.
>

No comment.

> 7. Which one is easier to use?
>

No comment, I tried and failed to get Gnus going, but eventually it
clicked and I haven't bothered migrating.

> 8. Should I start with Rmail? and later switch to GNU?
>

They are not alternatives. Rmail has been asserted by at least one
expert to be the default program.  I use both but I could probably do
everything in Gnus, and do so day-to-day.

> At the moment I don't need GNU for reading news etc...
>
> 9. Or is it useful to start with GNU because it has more options and I have to
> learn it anyhow? and I can use it with org-mode?
>

Yes, and yes.  You can draft in org and convert to HTML-based email.
Nice for tables, etc.   I also use org-contacts to TAB-populate To:

> 10. Do all of them have the same or similar keybindings or do I have to learn
> for each one separate keybindings?
>

They share emacs navigation. But I would say Gnus has a more "modal"
keybinding, with a leader key and then another more specific.

G t (Groups)
A t (Articles)
T n (Topics)

etc.

> 11. What are the benefits compared to thunderbird?

It is different.  I also use thunderbird because I like to check email
on my tablet with a stylus.

These are not alternatives.

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

When Gnus threads (sorts by conversation) it can take a while on groups
with large messages, e.g. loading emacs-help and emacs-devel and
requesting all messages.  e.g. historical research.

Emacs with native-comp has completely changed the game for me, and
allows pretty much care-free browsing of groups without worry about a
lockup during processing.

(I actually use a separate Emacs process for doing this, so my other
activities aren't blocked.)

Best regards,
Eric

Re: package for Email

[Jean Louis]

* Gottfried <gottfried@posteo.de> [2023-01-18 16:57]:
> 1. Which Email package do you use?

Best Email package for Emacs is program `mutt' https://www.mutt.org --
it's joke, is not Emacs but is console program. You may see features
here: https://www.mutt.org/#features -- don't worry about SSL
certificate, maintainer forgot to renew it. It even has mini-Lisp
built-in.

Mutt invokes Emacs and I answer E-mails. If I wish to compose E-mails
I use Emacs. But I am fast in using it. I do not use M-x, rather I
think of "Gottfried" and find person, then I just press key and
e-mail is composed with my proper return identity to recipient.

Try:

M-x compose-mail

When you set variables:

user-full-name, user-mail-address

Then here is the strategy for e-mails that I use for decades, which
minimizes 

- your e-mail program shall be set in such way that you save ALL
  e-mails to and from recipient's email address in a single Maildir
  type of email folders (I think Thunderbird does not support it)

- If your main e-mail folder is in ~/Maildir I strongly suggest
  everybody to save e-mails in this structure:

  ~/Maildir/gottfried@example1.com
  ~/Maildir/joedoe@gmail.com
  ~/Maildir/jane@yahoo.com

  Which means ALL e-mails related to that e-mail address to be in
  single Maildir folder. Maildir folders have cur, new, tmp,
  directories, so the structure is as following:

  ~/Maildir/jane@yahoo.com/cur
  ~/Maildir/jane@yahoo.com/tmp
  ~/Maildir/jane@yahoo.com/new

  Maildir folder is most error free. See:

  cr.yp.to/proto/maildir.html:
  http://cr.yp.to/proto/maildir.html
  
  You do not think about saving e-mails and where and how. When e-mail
  client is set correctly, then I just press single key, and e-mail is
  saved in proper e-mail folder.

  Greatest benefit of this is that in an instant, in less than a
  second, you are able to see all previous conversation related to
  that person's e-mail address!

  Many people use indexed databases to search for e-mails, but because
  you first can see all the conversation for single person, you can
  use quick search by using e-mail client (mutt).

> Can you tell your experience with your email package?

I have tried them all. They can't handle my e-mails. If you think you
will never do business with e-mail, then most powerful package I know
is:

;; MH (Message Handler) is a powerful mail reader. See
;; https://rand-mh.sourceforge.io/.

But I do not use it, as it waste my time. Mutt is fastest, most
handy. I can't wait in other packages.

`mu' for Emacs can't handle my e-mails! I have got too many. Just
Maildir folders are there 59848, that means at least that many
recipients. Despite the number of recipients, it is very easy to find
all conversation for single recipient. In my case I just click, or
press key on a person's entry, or in console I do like:

$ emailsof gottfried@example.com

and in Emacs similarly.

It is possible to run Mutt in terminal inside of Emacs, looks like
Emacs almost.

> 2. Does it make sense for me as an emacs-newbie to change from using
> thunderbird to an emacs email package?

No. I don't recommend. Thunderbird has good features, multiple
accounts, multiple identities, templates, I can just suggest using
external editor if you wish to try out functions in e-mails like
these:

https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/

> 3. There are
> Rmail, GNU, Wanderlust, Mu4e etc...

You should look in your personal requirements:

- rmail -- I don't believe it supports multiple identities, but is
  really fine mail client

- Gnus -- forget it (sorry Lars), is not worth effort long term

- Wanderlust -- is usable, but why too much hassle when you already
  have Thunderbird

- mu4e -- is really nice but only if you don't have too many
  e-mails. It can't handle my number of Maildirs, and indexing is in
  background, as long as you don't really have many e-mails, it will
  be good. But it works with mix or large number of emails, without
  any order.

Remember, using one folder per recipient is strong principle that is
useful to see any previous conversation related to some e-mail
address. Mu4e can't do that for you.

Thunderbird is for slow motion, Mutt is for speedy work. 

> 4. I prefer to habe folders because I like to have an overview.
> Mu4e doesn't have folders.

It has, it supports Maildir folders, you need to enable strategy.

And remember, any kind of folders you have, you can convert them later
to other folders.

> 5. I want IMAP.

IMAP is way how you fetch e-mails.

I read IMAP with Mutt, but sometimes I fetch e-mails from IMAP to
local computer first, then process them.

> Do all of them provide IMAP? (does Rmail now provide IMAP)?

If I remember well, first you fetch e-mails from IMAP to local folder
then you read that local folder.

Example settings:

(setq rmail-default-file "/home/data1/protected/Mail/xmail")
(setq rmail-movemail-program "movemail-p")
(setq rmail-use-spam-filter t)

> 7. Which one is easier to use?

Mutt is easiest to use on long term, it will use Emacs in console and
graphical environment, and it can be run from within Emacs in terminal.

> 8. Should I start with Rmail? and later switch to GNU?

IMHO, you stay with Thunderird.

> At the moment I don't need GNU for reading news etc...

Gnus

> 9. Or is it useful to start with GNU because it has more options and I have
> to learn it anyhow? and I can use it with org-mode?

It is very good if you wish to waste time. Better watch movies.

> 10. Do all of them have the same or similar keybindings or do I have to
> learn for each one separate keybindings?

Yes, they are all different.

> 11. What are the benefits compared to thunderbird?

Greatest benefit using Emacs is extensibility. But it also requires
learning Emacs Lisp. Thunderbird is also extensible, that is why there
are extensions. It is just different way of using them.

In my opinion Thunderbird is way more ergonomic, so I would only use
similar KMail or other programs, where you can use mouse and have
faster access to options. Emacs does not offer fast access to all
options, mouse usage is not enough developed in many Emacs
programs. So if you are mouse user, you will quickly get stuck with
those email programs in Emacs.

> A. Only the keybindings of Emacs I can use and in knowing them it
> will be easier in future to handle it?

That is process that may never end.

I use Mutt, so major keybindings are up, and down, with "j" "k" and
arrows, and then "r" to reply or "g" for group reply, and "y" or "q",
not much. Major issue is speed, it can speedily open up Maildir folder
and show me.

And often I bookmark e-mails, like here entry of single bookmark:

                           Name   "EIEIO for simple databases"
                      Hyperlink   "~/Maildir/michael_heerdegen@web.de"
                      Arguments   "87h7pwgbg1.fsf@web.de"

Then on single click I get to that e-mail related to EIEIO. It is one
of reasons I use Mutt.

> B. It is within emacs and uses less CPU

They don't spend CPU, but some of those e-mail programs will start
complaining when you start handling many e-mails.

-- 
Jean

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

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

Re: package for Email

[Tomas Hlavaty]

I would recommend notmuch as an email client.

On Wed 18 Jan 2023 at 18:15, Jean Louis <bugs@gnu.support> wrote:
> Mutt invokes Emacs and I answer E-mails.

or the other way round:

   (term "mutt")

or if you have several different mutt configuration:

   (defun term2 (program &rest args)
     (let ((x (apply 'make-term
                     (format "%s" (cons 'term2 (cons program args)))
                     program nil args)))
       (set-buffer x)
       (term-mode)
       (term-char-mode)
       (switch-to-buffer x)))

   (term2 "mutt" "-F" "~/.muttrc2")

I never understood, why term does not have args like term2.  Such little
change with so mucht impact.  It is so convenient, e.g.

   (term2 "mtr" "1.1.1.1")

Re: package for Email

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2023-01-19 10:31]:
> I would recommend notmuch as an email client.
> 
> On Wed 18 Jan 2023 at 18:15, Jean Louis <bugs@gnu.support> wrote:
> > Mutt invokes Emacs and I answer E-mails.
> 
> or the other way round:
> 
>    (term "mutt")
> 
> or if you have several different mutt configuration:
> 
>    (defun term2 (program &rest args)
>      (let ((x (apply 'make-term
>                      (format "%s" (cons 'term2 (cons program args)))
>                      program nil args)))
>        (set-buffer x)
>        (term-mode)
>        (term-char-mode)
>        (switch-to-buffer x)))
> 
>    (term2 "mutt" "-F" "~/.muttrc2")
> 
> I never understood, why term does not have args like term2.  Such little
> change with so mucht impact.  It is so convenient, e.g.
> 
>    (term2 "mtr" "1.1.1.1")

It is useful function for me as it provides safer way to provide
arguments.

-- 
Jean

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

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

Re: package for Email

[Tassilo Horn]

Gottfried <gottfried@posteo.de> writes:

Hi Gottfried,

> 1. Which Email package do you use?

I use mu4e.

> Can you tell your experience with your email package?

It's great.  Basically, you have to use a tool like mbsync to
synchronize your remote IMAP accounts with local maildirs which are then
indexed by mu.  The good thing is that you can do crazy searches like
"all mails from Gottfried in the period 2020-2021 mentioning apples and
having an attachment" in almost an instant.  Downsides are that you have
to configure mbsync or offlineimap or something alike which can get
complicated depending on your email provider, e.g., when you need 2FA.
And of course, you can spend a life configuring mu4e to your liking,
too.

Before mu4e I've used Gnus for more than a decade which is great, too.
It's just slower when you access IMAP accounts directly with the nnimap
backend.  But one of Gnus very strong points are (adaptive) scoring,
e.g., sorting the message overview such that threads interesting to you
are on top and the boring stuff at the bottom.  That's a thing I miss.

> 2. Does it make sense for me as an emacs-newbie to change from using
> thunderbird to an emacs email package?

The good thing is, you can use thunderbird AND some emacs package.

> 3. There are
> Rmail, GNU, Wanderlust, Mu4e etc...

It's Gnus, not GNU.

> 4. I prefer to habe folders because I like to have an overview.  Mu4e
> doesn't have folders.

Not true.  Its main concept is having searches and results for searches
but its maildir shortcuts are searches for mails in a specific maildir.

> 5. I want IMAP.
> Do all of them provide IMAP? (does Rmail now provide IMAP)?

Gnus can do IMAP, mu4e does only maildirs and you need another tool like
mbsync to synchronize your IMAP accounts to local maildirs.  I think
Rmail does just Rmail, a variant of the MBOX format, but I might be
wrong.

> 6. Wanderlust seems to be more difficult to set up, and I still have
> trouble because I am an Emacs-newbie.

I think it's niche, indeed.  If you want support, go for Gnus, Rmail, or
mu4e.

> 7. Which one is easier to use?

I think they are all efficient to use after you have taught them your
way to deal with mail in years and years of configuration, like it's the
case with emacs in general. ;-)

I can only speak for Gnus and mu4e: if you have a helping hand like this
list, you should be able to get the basics working in no time.

> 8. Should I start with Rmail? and later switch to GNU?

I don't know.

> 9. Or is it useful to start with GNU because it has more options and I
> have to learn it anyhow? and I can use it with org-mode?

What does "use with org-mode" mean?

> 10. Do all of them have the same or similar keybindings or do I have
> to learn for each one separate keybindings?

I think all of them have mostly different bindings.

> 11. What are the benefits compared to thunderbird?

If you need to handle and write tons of text-only mail, or apply patches
from mails to code bases, then that's probably much better in any emacs
mail client.

If on the other hand, you need to do HTML-mailing like it's ubiquitous
today, then thunderbird is probably better.

> A. Only the keybindings of Emacs I can use and in knowing them it will
> be easier in future to handle it?

Maybe.

> B. It is within emacs and uses less CPU

Probably.

> C......

Having fun just by doing it!  As said, there's nothing wrong with using
thunderbird, your email provider's web client, Fairmail or K9 Mail on
your Android phone, and multiple emacs clients.

Bye,
Tassilo

Re: package for Email

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 18 Jan 2023 16:51:39 +0100
> 
> > 5. I want IMAP.
> > Do all of them provide IMAP? (does Rmail now provide IMAP)?
> 
> Gnus can do IMAP, mu4e does only maildirs and you need another tool like
> mbsync to synchronize your IMAP accounts to local maildirs.  I think
> Rmail does just Rmail, a variant of the MBOX format, but I might be
> wrong.

Rmail uses movemail to get the email and save it as mbox file, so if
you have GNU Mailutils installed, movemail will get you email using
almost any protocol, and I think IMAP is one of the supported one.
But I don't use IMAP with Rmail, so I may be wrong here.

Re: package for Email

[andrés ramírez]

Hi.
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


[...]


    Eli> Rmail uses movemail to get the email and save it as mbox file, so if you have GNU Mailutils
    Eli> installed, movemail will get you email using almost any protocol, and I think IMAP is one
    Eli> of the supported one.  But I don't use IMAP with Rmail, so I may be wrong here.

Be aware that movemail delete all the messages from the maildir when
doing its job.

Best Regards
ps: on emacs-devel mailing list there was a thread about adding support
for maildir on rmail

Re: package for Email

[Jean Louis]

* andrés ramírez <rrandresf@hotmail.com> [2023-01-18 21:00]:
> Hi.
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
> [...]
> 
> 
>     Eli> Rmail uses movemail to get the email and save it as mbox file, so if you have GNU Mailutils
>     Eli> installed, movemail will get you email using almost any protocol, and I think IMAP is one
>     Eli> of the supported one.  But I don't use IMAP with Rmail, so I may be wrong here.
> 
> Be aware that movemail delete all the messages from the maildir when
> doing its job.

With option "preserve true" it will not remove messages from
server. On command line the option is 

-p, --[no-]preserve, --keep-messages
                             preserve the source mailbox

-- 
Jean

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

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

Re: package for Email

[Andreas Eder]

On Mi 18 Jan 2023 at 13:56, Gottfried <gottfried@posteo.de> wrote:

> Hi everybody,
>
> I am using thunderbird for emails.
> My question:
>
> 1. Which Email package do you use?
mu4e

> 2. Does it make sense for me as an emacs-newbie to change from using
> thunderbird to an emacs email package?
certainly

> 3. There are
> Rmail, GNU, Wanderlust, Mu4e etc...
It is gnus not GNU.
And there is also notmuch and VM and probably some others.

> 4. I prefer to habe folders because I like to have an overview.
> Mu4e doesn't have folders.
You can have folders with mu4e, I do!

> 5. I want IMAP.
> Do all of them provide IMAP? (does Rmail now provide IMAP)?
Look at mbsync or offline-imap.

> 6. Wanderlust seems to be more difficult to set up, and I still have
> trouble because I am an Emacs-newbie.
I have no experience with wanderlust.

> 7. Which one is easier to use?
That depends on who you ask.

> 8. Should I start with Rmail? and later switch to GNU?
I'd advise zou to start with mu4e. Have a look at the emacs wiki and
other instructions.

> 9. Or is it useful to start with GNU because it has more options and I
> have to learn it anyhow? and I can use it with org-mode?
gnus has a totally different way of handling mail. Use it only if you
are also using for reading usenet news.

> 10. Do all of them have the same or similar keybindings or do I have to
> learn for each one separate keybindings?
They have different keybindings by default, but you can change the bindings.

> 11. What are the benefits compared to thunderbird?
You are inside emacs!

'Andreas

Re: package for Email

[Milan Glacier]

On 01/18/23 13:56, Gottfried wrote:
>Hi everybody,
>
>I am using thunderbird for emails.
>My question:
>
>1. Which Email package do you use?
>Can you tell your experience with your email package?

I have experience with 3 email clients, mu4e, notmuch, and neomutt.

My personal experience suggests that overall I like neomutt best, but
the others have their own merits. And all of them they are very good.
YMMV.

>
>2. Does it make sense for me as an emacs-newbie to change from using 
>thunderbird to an emacs email package?

It depends on your usage. If you use emails primarily just for reading
HTML emails from advertisement. Then no. But other than that, yes.

>3. There are
>Rmail, GNU, Wanderlust, Mu4e etc...
>
>4. I prefer to habe folders because I like to have an overview.
>Mu4e doesn't have folders.

What do you mean by "mu4e doesn't have folders"? Mu4e can read emails
from folders ad move emails between folders. What else do you need?

>
>5. I want IMAP.
>Do all of them provide IMAP? (does Rmail now provide IMAP)?

You probably need offlienimap or isync(mbsync) as a mail synchronization
(fetch emails from server and push local changes to the server) backend.

All of notmuch, mu4e, and neomutt are just just frontends that
read/change your local maildir.

>6. Wanderlust seems to be more difficult to set up, and I still have 
>trouble because I am an Emacs-newbie.

I don't use wanderlust but I have read some other's feedback. They
suggests that wanderlust is implemented in pure elisp and has very fast
IMAP sync speed (in comparison with Gnus). If you are using Windows
where mbsync is not possible to use. Then wanderlust may be a good
choice.

As for configuration, yes, the configuration syntax for wanderlust is a
bit complex, it uses DSL rather than elisp to configure.

>7. Which one is easier to use?

Notmuch, neomutt, and mu4e are all easy to use. LMO. But again YMMV. My
personal configuration steps include:

- configure mbsync to fetch/push emails changes.
- configure msmtp to send emails.
- configure mu4e/neomutt/notmuch to read the local maildirs.

>8. Should I start with Rmail? and later switch to GNU?
>
>At the moment I don't need GNU for reading news etc...
>
>9. Or is it useful to start with GNU because it has more options and I 
>have to learn it anyhow? and I can use it with org-mode?
>
>10. Do all of them have the same or similar keybindings or do I have 
>to learn for each one separate keybindings?

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.
- You can manipulate emails buffers just like normal text buffers.
- Integration with other emacs facilities like orgmode, pdftools,
   xwidget stuff.
- They offer you more flexible and powerful way to manipulate, search
   and index your emails.

Let me show my feedback on all of three emails client I used:

* Neomutt

- It is a standalone cli app. You can use emacs to compose your emails
   and use emacs to read/edit your inbox emails with some very simple
   configuration.
- It is folder-based.
- It has pretty decent integration with notmuch (that is: you can index
   your emails efficiently).
- It can fold threads, which is very useful for reading mailing list.
- When reading HTML emails (especailly advertisement emails), typically
   you do two steps:
   + using w3m/lynx like terminal based termianl to dump the renderd HTML
     emails into text. And neomutt shows you the text in the reading
     page. And for advertisement emails, w3m/lynx generally gives you
     rendered output that is not ideal.
   + If you are not satisfied with the rendered plain text by w3m/lynx,
     you can directly open the HTML using your GUI browser in neomutt
     (two keystrokes "v RET").

* mu4e

- It has decent integration with orgmode. (store links to email in
   orgmode, open email links in orgmode, and compose html emails by
   orgmode).
- 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.
- 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.

* notmuch

- It has a conversation view (show all emails within a thread in one
   text buffer).
- HTML emails rendering is decent (also say thanks to shr.el).
- It cannot **manipulate** emails. That is: notmuch doesn't provide you
   an official way to delete emails and move emails between folders.
   However you can do that with some "hack" scripts.

>
>Kind regards
>
>Gottfried
>

Re: package for Email

[Jean Louis]

* Milan Glacier <news@milanglacier.com> [2023-01-18 21:06]:
> It depends on your usage. If you use emails primarily just for reading
> HTML emails from advertisement. Then no. But other than that, yes.

HTML e-mails may be tricks, wanting to track user. With mutt it is
single or double key to see HTML e-mails, as the file ~/.mailcap may
decide how to open it, like in the browser. I don't know if Mutt can
see embedded pictures, usually it does not matter much as all pictures
as attachment can be seen anyway. One way I found here:

https://shallowsky.com/blog/tech/email/mutt-viewing-html-mail.html

But I prefer seeing text first.

> Notmuch, neomutt, and mu4e are all easy to use. LMO. But again YMMV. My
> personal configuration steps include:
> 
> - configure mbsync to fetch/push emails changes.
> - configure msmtp to send emails.
> - configure mu4e/neomutt/notmuch to read the local maildirs.

Too often I invoke msmtp manually from Emacs:

(defun msmtp-count-remaining ()
  "Count and send any remaining MSMTP messages in the queue"
  (interactive)
  (let ((default-directory (rcd-my-home))
	(msmtp-runqueue (executable-find "msmtp-runqueue.sh")))
    (rcd-general-log "Function `msmtp-count-remaining' invoked" nil 1 nil nil nil 6)
    (let ((count (length (directory-files "~/.msmtpqueue" nil "\\.mail"))))
      (if (> count 0)
	  (progn
	    (start-process msmtp-runqueue "RCD MSMTP" msmtp-runqueue)
	    (rcd-message "MSMTP: There is %s e-mails in queue." count))
	(rcd-message "MSMTP: No emails.")))))

or like this:

(defun msmtp-run-queue ()
  (async-shell-command "msmtp-runqueue.sh"))

or simply running it with Emacs timer:

(defun msmtp-with-timer ()
  (interactive)
  (let ((timer (run-with-timer 1 3600 'msmtp-run-queue)))
    (message "MSMTP: running queue with timer: %s" timer)))


-- 
Jean

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

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

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/

Re: Debunking Emacs merits over GUI - Re: package for Email

[Emanuel Berg]

Jean Louis wrote:

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

It's a matter of styles; either that or the keyboard is
preferable to most stuff where the mouse don't have an apparat
advantage, e.g. GFX, CAD, GIS, FPS ...

Not OpenSCAD, maybe ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-19 14:47]:
> It's a matter of styles; either that or the keyboard is
> preferable to most stuff where the mouse don't have an apparat
> advantage, e.g. GFX, CAD, GIS, FPS ...
> 
> Not OpenSCAD, maybe ...

In computing subject it's purpose is to help human.  

I don't know why we did not yet advance to the motion communication
with computer just as it is shown in movie, if I remember well,
Minority Report, where Tom Cruise moves his fingers in the air and
hologram objects get here and there. 

I similar communication between human and computer available for games
on modern game consoles.

Btw, here is one way how we can implement in Emacs speech recognition:

voice2json | Command-line tools for speech and intent recognition on Linux:
https://voice2json.org/

Then we can command Emacs with speech, that means: keyboard, mouse
plus speech.

It cries for the Emacs package, enabling user to train Emacs by speech
and assign commands, just imagine "tetris", "left", "left", "turn",
"turn", "tuuurn", "f..."

Then there are those mouse motion packages. But not enough.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Marcin Borkowski]

On 2023-01-19, at 14:00, Jean Louis <bugs@gnu.support> wrote:

> Btw, here is one way how we can implement in Emacs speech recognition:
>
> voice2json | Command-line tools for speech and intent recognition on Linux:
> https://voice2json.org/
>
> Then we can command Emacs with speech, that means: keyboard, mouse
> plus speech.
>
> It cries for the Emacs package, enabling user to train Emacs by speech
> and assign commands, just imagine "tetris", "left", "left", "turn",
> "turn", "tuuurn", "f..."

:-)

One datapoint: https://yewtu.be/watch?v=8SkdfdXWYaI
(note that he used some proprietary voice recognition software).

> Then there are those mouse motion packages. But not enough.

What packages do you mean?

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2023-01-19 18:34]:
> One datapoint: https://yewtu.be/watch?v=8SkdfdXWYaI
> (note that he used some proprietary voice recognition software).

Emacs follows his voice well. I wish we could have that sooner in
Emacs to program by talking. So that is already available.

Are you sure it is proprietary voice recognition underlying?

By using voice2json as free software, we may teach Emacs to code by
voice. And I do not mean that that training is something difficult,
there are already many languages and people who natively speak
supported language will be comforted the most.

He speaks of dragonfly and dictation, it seems that software is free:

dictation-toolbox:
https://github.com/dictation-toolbox

dictation-toolbox/Caster: Dragonfly-Based Voice Programming and Accessibility Toolkit:
https://github.com/dictation-toolbox/Caster

Then he says "Emacs is supported". So I wish to use that. I hope it is
not too difficult to install.

> > Then there are those mouse motion packages. But not enough.
> 
> What packages do you mean?

I only heard of it, not that I use them.

Mouse Tracking (GNU Emacs Lisp Reference Manual):
https://www.gnu.org/savannah-checkouts/gnu/emacs/manual/html_node/elisp/Mouse-Tracking.html

Motion Events (GNU Emacs Lisp Reference Manual):
https://www.gnu.org/savannah-checkouts/gnu/emacs/manual/html_node/elisp/Motion-Events.html

What would be useful in Emacs is dragging left or right with mouse, or
touchpad, to move buffer left or right, swiping it away.

Then it would be possible to control Emacs by using simply eyes:

Projects/MouseTrap - GNOME Wiki!:
https://wiki.gnome.org/action/show/Projects/MouseTrap?action=show&redirect=MouseTrap

SITPLUS project | SITPLUS:
http://sitplus.crea-si.com/node/118/

Then pointing gestures:

Dasher Manual - GNOME Library:
https://help.gnome.org/users/dasher/

And then there are hand gesture controls.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Milan Glacier]

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.

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jude DaShiell]

Being keyboardcentric enhances productivity over mouse users.  Time and
motion studies in the area of production organization and management have
proved that.  Keyboardcentric impairs useability for the teddy bears on
wall paper set that barely use keyboards and get confused when they have
to use an interface without eye candy.  The favoring of mouse and eye
candy interfaces ended up making a very bad career for me working for the
Government as a screen reader user and java script was no help either.
emacspeak on a computer is in the Smithsonian and it's a screen reading
environment that uses emacs as its base and that was in the Smithsonian in
1995 if I have my time lines correct.  Windows accessibility started
getting better when nvda became available but Windows most assuredly was
not accessible even for jaws until a correct jaws.jcf file got written so
jaws could have a chance at being able to work with windows.  For many
years it wasn't possible for totally blind users of windows to install it
until several iterations of narrator arrived and narrator is worse than
jaws in terms of features.  Had everyone gone forward with emacs or emacs
with emacspeak rather than windows there'd likely be lots more totally
blind programmers employed these days.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Thu, 19 Jan 2023, Milan Glacier wrote:

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Jude DaShiell <jdashiel@panix.com> [2023-01-19 19:53]:
> Being keyboardcentric enhances productivity over mouse users.

For blind users yes. 

Though general statement about it is rather difficult.

Graphics designers like keyboard shortcuts. Then in same time without
mouse they could not almost do their work!

"Modal" usage of applications comforts users even more. In that case
there is no need for complex key bindings.

We can see resurgence of computer keyboard usage in last years.

Though majority find it easier to use mouse, let us say for browsing,
adding calendar events, getting directions on the map, accessing
menus, and so many other very common actions.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Bob Newell]

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

Certainly it is.  But remember it is a matter of choice and user
preference.  I find having to reach for the mouse and remove hands
from keyboard very disruptive.

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

Again, depending on the point of vue of the user.

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

Well, actually you can in GNUS and probably other Emacs clients.

Not to say Thunderbird isn't good.  I actually think it's a very good
client.  It is just not what I prefer as I like to stay within Emacs.

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

This is something I've stressed before.  Serious tools for craftsmen
require serious effort.  No one starts out as a master craftsman.
Everyone starts as a novice.  Does that mean that the tools of the
master are inferior because the novice is not yet skilled with them?
Hardly.

> But an average user won't use emacs as its text editor. An average user
> writes proses use MS Word.

And that's fine.  To each his own.

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

I will again say something I've said before.  Emacs is not for
everyone, and I don't mean that in an elitist sense.  For many of us
it is an indispensible tool, which we've spent a long while learning
how to use to best advantage.  For others it may just be a big bother
when simpler and easier tools may work just fine for their needs.

I am not out there telling people "learn Emacs" without first knowing
what their interests and inclinations may be.  That indeed could be
unproductive.  I think people who can make use of Emacs find their way
to it eventually.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Bob Newell <bobnewell@bobnewell.net> [2023-01-20 00:13]:
> > >Doug Engelbart invented mouse device for people to speed up with
> > >work. Using mouse is just fine.
> 
> Certainly it is.  But remember it is a matter of choice and user
> preference.  I find having to reach for the mouse and remove hands
> from keyboard very disruptive.

That is why makers of Thinkpad placed that red dot button somewhere in
the middle of the keyboard.

> Not to say Thunderbird isn't good.  I actually think it's a very good
> client.  It is just not what I prefer as I like to stay within
> Emacs.

Me too, I stay in `mutt' within or outside Emacs, though can't
recommed that to anybody, I recommed to people who do not know about
terminal applications, only graphicsl Kmail, Evolution or Thunderbird.

> > >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.
> 
> This is something I've stressed before.  Serious tools for craftsmen
> require serious effort.  No one starts out as a master craftsman.
> Everyone starts as a novice.  Does that mean that the tools of the
> master are inferior because the novice is not yet skilled with them?
> Hardly.

> I will again say something I've said before.  Emacs is not for
> everyone, and I don't mean that in an elitist sense.  For many of us
> it is an indispensible tool, which we've spent a long while learning
> how to use to best advantage.  For others it may just be a big bother
> when simpler and easier tools may work just fine for their needs.
> 
> I am not out there telling people "learn Emacs" without first knowing
> what their interests and inclinations may be.  That indeed could be
> unproductive.  I think people who can make use of Emacs find their way
> to it eventually.

That is very right.

I think that it is exaggeration with masters and novices, and we
exaggerate with Emacs features, because we love it. But that does not
give realistic picture to people.

Though better be objective towards those users who search for better
e-mail client.

Objectively, Emacs is not an option as e-mail client for anybody.

To understand that reality, simply prepare Emacs with whatever e-mail
client of your choice and bring it to any organization, tell them to
try it out, and then to tell you if they wish to replace  their
ordinary use of e-mail with that one of Emacs. 

Then repeat that with other 2 organizations, then we know what is real
to people.

It is matter of many coincidences and interests and work over periods
of time that somebody becomes "Master in Emacs", and that alone, while
pleasure for those masters, may be pain and impairment for those
considered "novices".

In general people who already use computer are not novices, unless
maybe novices in Emacs. 

Drawing them into that world by saying that Emacs handles better
e-mail is IMHO less productive for their life.

When user starts maintaining e-mail server, of course that user may
start learning about IMAP, about `procmail', or `sieve' and maybe some
users maintain multiple servers, for that type of users is alright to
engage into complexities as they can handle it. It does not mean they
are "masters" just because they maintain web servers, there are many
GUI interfaces for web servers, mail servers and similar. 

When user handles e-mails with family and business, then graphical
programs like Thunderbird may be appropriate.

So we always better start from human, from people, instead from
a program (Emacs vs Thunderbird).

Human is the reason for program. Programs are made with purpose to
assist human.

Not other way around.

Emacs, Thunderbird itself is not reason in itself for human to use
them. People should not use programs because their underlying power is
demonstratable, but because programs will help them handling their
life.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Bob Newell <bobnewell@bobnewell.net> [2023-01-21 03:08]:
> > Objectively, Emacs is not an option as e-mail client for anybody.
> 
> I must differ as I think "anybody" is too broad.  There are
> thousands of Gnus users, myself included.  Gnus enables me to
> do things--- things important to my work and pursuits--- that
> would be much more laborious or maybe not even possible with
> other clients.

You are right, it is generalization, which I did not intend. I have
expressed me in the way how I did not want. I am myself using Emacs to
start composing e-mails, and to manage e-mails in combination with
various tools, and sometimes I use Emacs e-mail package.

I wanted to say that objectively when somebody is looking for e-mail
client, it is not good to recommend Emacs in first place.

Any e-mail client enable people to do important tasks. So it is `mail'
too! 

I bet you do not use `mail' on command line. And me too, I do not use
it often on command line, but I may use it sometimes, and I use it
hundreds of thousands of times from within Emacs! 

However, that I use `mail' in that particular way is very specific to
me. We make thousands and thousands of dollars by using `mail' and the
packge 

Emacs Lisp: rcd-mail.el package as bindings to GNU Mailutils "mail" program:
https://hyperscope.link/3/8/3/0/3/rcd-mail-el-GNU-Mailutils-mail-program.html

My personal use is related to integration with other packages in
Emacs, for example, I don't like composing e-mails, and I prefer to
simply write e-mail, while everything else is handled for me: 

- e-mail subject, to be automatically handled (or customized when
  necessary)

- greetings, to be automatically handled,

- my identity towards recipient, to be automatically handled,

- my signature to be automatically handled

All of the messages are where? In the table `messages'. I can easily
find any message sent in that automated manner. And messages have
their types:

 1          E-mail
 2          SMS
 3          XMPP
 4          Call
 5          Talk

Now imagine a list of communication lines, like e-mail, SMS, XMPP:

Bob, e-mail, bob@example.com
Bob, SMS, +1234567890
bob, XMPP, bob@xmpp.example

I don't think of e-mails, I think of "Bob" and that I have to tell him
something, so I mark those above three lines, and write single
message. 

Single message is then sent to all of those communication lines,
alerting person on what we have to talk about.

Why think of invoking XMPP client?
Why think of getting phone in my hand and type?
Why think of invoking e-mail client?

What I think of is that what I have to communicate to person.

So in my environment I find myself efficient as I keep working on
integration of functions for human need.

It is very easy to teach staff member to:
-----------------------------------------

- find person among many people in Emacs or other tool (because there
  is universally accessible database in background)

- click on "l c" for "List Communication Lines"

- mark communication lines

- send message or prepared document


Instead of teaching people:
---------------------------

- to use Thunderbird, Emacs mail client, etc. too much of software and
  hand work

- to teach people how to use Gajim, Pidgin, Dino, Conversations, you
  name it, hand work

- to teach them how to enter one person's contacts in each of the
  above software as they do not have integrated access to contacts
  database 

- to teach them how to attach documents, upload files, etc. way too
  much

- then to give them task to send information to those people, all one
  by one.

I find that approach efficient.

Am I ever going to recommend it to acquaintance or person on mailing
list as the way of handling e-mails? Rather no, because that is not
the environment and need or demand by that person.

IMHO, Emacs is last environment I would recommend average person.

When person is let us say in GNU/Linux environment, than it becomes
closer to recommendation.

My staff members learned `mutt' and were using it properly. They have
installed Hyperbola GNU/Linux-libre by following my advise on a
Thinkpad computer. They however, were compelled into it. And they used
it fine, because they took little time to learn basic functions.

However, to recommend people to start with tools I am personally
using, I say rather no, as that would waste their time.

When person is willing to learn and wish to become efficient in some
specific areas of life, I would again try to find what is the best
fitting or best matching computing solution for that person. 

I am aware that my habits, experiences, skills, efficiency is all
personal. 

It is not universal and applicable to everybody.

> But that doesn't mean that some people find Gnus etc. to be a
> very powerful productivity tool.

Yes, I understand, sure. Me too, I was using it back in time, I don't
remember when, maybe before 20 years, who knows. I was reading `news'
with it.

> I would like to generalize "human" to "requirements" based on
> the job at hand, the capabilities and desires of the user, and
> so on, to create a wholistic solution.  Choosing software
> prior to understanding what is needed is folly.  Yet it is
> done very often.  (Queue entry of salespeople wearing suits
> who talk only to corporate executives and never to end-users
> about their multi-million dollar product.  Said conversations
> to take place on a private golf course.)

That is right.

Thanks for exchanging!

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Emanuel Berg]

Jean Louis wrote:

> I wanted to say that objectively when somebody is looking
> for e-mail client, it is not good to recommend Emacs in
> first place.

On the contrary, Emacs Gnus is a very powerful e-mail client -
and more - and to a person who is already an Emacs user it
absolutely makes sense recommending it if s/he looks for
a client ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Debunking Emacs merits over GUI - Re: package for Email

[Eli Zaretskii]

> Date: Sat, 21 Jan 2023 10:05:31 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> I wanted to say that objectively when somebody is looking for e-mail
> client, it is not good to recommend Emacs in first place.

Forgive me my bluntness, but that's baloney!  Emacs-based email
clients are very adequate, and some of them much more than just
adequate.  I'm surprised to even see this in an Emacs forum, let alone
coming from such a veteran Emacs user.

I challenge you to post a list of tasks people do with email clients
that Emacs-based MUA don't support.

Re: Debunking Emacs merits over GUI - Re: package for Email

[Emanuel Berg]

Eli Zaretskii wrote:

> I challenge you to post a list of tasks people do with email
> clients that Emacs-based MUA don't support.

Probably some smartphone hangup Jean has ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-21 16:47]:
> Eli Zaretskii wrote:
> 
> > I challenge you to post a list of tasks people do with email
> > clients that Emacs-based MUA don't support.
> 
> Probably some smartphone hangup Jean has ...

Because you knew I will come up with it. I was busy making another
package.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2023-01-21 10:22]:
> > Date: Sat, 21 Jan 2023 10:05:31 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > I wanted to say that objectively when somebody is looking for e-mail
> > client, it is not good to recommend Emacs in first place.
> 
> Forgive me my bluntness, but that's baloney!  Emacs-based email
> clients are very adequate, and some of them much more than just
> adequate.  I'm surprised to even see this in an Emacs forum, let alone
> coming from such a veteran Emacs user.
> 
> I challenge you to post a list of tasks people do with email clients
> that Emacs-based MUA don't support.

OK I understand that you love Emacs, as you are the one making it.

I also love some girls, but I can't recommend them to others.

What is mine and lovable is not necessary so for other people.

I handle bunch of tasks with rudimentary email functions, the
technical challenge is not what ordinary people are interested in.

What matters is usability.

Do you know that less and less people use e-mail? This is because of
proprietary WhatsApp and other applications that makes it clear to
user that communication may be straightforward.

People tend to use what is straightforward.

If person is in other room, chances to write e-mail to that person are
very low, yelling over or going to talk in that that other room is
more probable.

It is because people want to communicate straightforward.

List of tasks people do with email clients that Emacs-based MUA don't support:
------------------------------------------------------------------------------

Let us compare it from Thunderbid:

Thunderbird Features — Thunderbird:
https://www.thunderbird.net/en-US/features/

1. Mail Account Setup Wizard (IMHO all accounts should be specified
   straight in main configuration, but programs in packages each ask
   for program specific settings)
2. One-click Address Book (most important lack of feature in Emacs,
   huge subject)
3. Attachment Reminder
4. Notifications of e-mails
5. Quick Filter
6. Search tools (indexing is there in Emacs, but is different concept) this
   refers to straight search without user thinking about indexing)
7. Robust privacy (this is included in Emacs only concidentally and due to lack of
   features)
8. Phishing Protection
9. Automated Update (yes, why should user bother about it?)
10. Cutting Out the Junk
11. Sharing of mail folders
12. Searching messages on IMAP server
13. Synchronization of folders (Emacs uses only external and difficult
    to setup command line tools, this is huge subject)
14. Automated deletion of IMAP message by user's policy
15. Selection of IMAP folders to be searched or not (IMAP offers fast search)
16. Integrated encrypted XMPP chat (jabber.el does not support OMEMO
    yet, I offer US $100 for that.)
17. Integrated calendar (M-x calendar is not integrated to e-mail)
18. Move/copy of e-mails from folder to other folder by using mouse
19. Convert e-mail to event
20. Convert e-mail to task
21. Drag and drop of attachments
22. HTML based e-mail writing
23. Attachment of WWW hyperlinks
24. Publish integrated calendar events/tasks
25. Automatic collection of e-mail addresses

--
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Eli Zaretskii]

> Date: Sat, 21 Jan 2023 17:28:21 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > Forgive me my bluntness, but that's baloney!  Emacs-based email
> > clients are very adequate, and some of them much more than just
> > adequate.  I'm surprised to even see this in an Emacs forum, let alone
> > coming from such a veteran Emacs user.
> > 
> > I challenge you to post a list of tasks people do with email clients
> > that Emacs-based MUA don't support.
> 
> OK I understand that you love Emacs, as you are the one making it.
> 
> I also love some girls, but I can't recommend them to others.

Nice method of technical argument, congratulations!

> List of tasks people do with email clients that Emacs-based MUA don't support:
> ------------------------------------------------------------------------------
> 
> Let us compare it from Thunderbid:
> 
> Thunderbird Features — Thunderbird:
> https://www.thunderbird.net/en-US/features/
> 
> 1. Mail Account Setup Wizard (IMHO all accounts should be specified
>    straight in main configuration, but programs in packages each ask
>    for program specific settings)
> 2. One-click Address Book (most important lack of feature in Emacs,
>    huge subject)
> 3. Attachment Reminder
> 4. Notifications of e-mails
> 5. Quick Filter
> 6. Search tools (indexing is there in Emacs, but is different concept) this
>    refers to straight search without user thinking about indexing)
> 7. Robust privacy (this is included in Emacs only concidentally and due to lack of
>    features)
> 8. Phishing Protection
> 9. Automated Update (yes, why should user bother about it?)
> 10. Cutting Out the Junk
> 11. Sharing of mail folders
> 12. Searching messages on IMAP server
> 13. Synchronization of folders (Emacs uses only external and difficult
>     to setup command line tools, this is huge subject)
> 14. Automated deletion of IMAP message by user's policy
> 15. Selection of IMAP folders to be searched or not (IMAP offers fast search)
> 16. Integrated encrypted XMPP chat (jabber.el does not support OMEMO
>     yet, I offer US $100 for that.)
> 17. Integrated calendar (M-x calendar is not integrated to e-mail)
> 18. Move/copy of e-mails from folder to other folder by using mouse
> 19. Convert e-mail to event
> 20. Convert e-mail to task
> 21. Drag and drop of attachments
> 22. HTML based e-mail writing
> 23. Attachment of WWW hyperlinks
> 24. Publish integrated calendar events/tasks
> 25. Automatic collection of e-mail addresses

My conclusion is that you don't have a very good idea of what Emacs
MUAs can do, because these tasks are all available.  Some are
available with any Emacs MUA, others with only some of them, but they
are available.

Re: Debunking Emacs merits over GUI - Re: package for Email

[Bob Newell]

>> I also love some girls, but I can't recommend them to others.
>
> Nice method of technical argument, congratulations!

I actually DID like that argument!  Don't you think that Emacs
is sexy?

>> List of tasks people do with email clients that Emacs-based MUA don't support:
>> ------------------------------------------------------------------------------

(long list deleted)

> My conclusion is that you don't have a very good idea of what Emacs
> MUAs can do, because these tasks are all available.  Some are
> available with any Emacs MUA, others with only some of them, but they
> are available.

Yes, every single thing on the list can be done in Emacs,
likely a combination of Gnus and some elisp packages or
coding (although HTML mail?  who wants to do that :) !!!).
And a lot more besides, for example, my favorite thing, in
conjunction with BBDB, when I write to certain mail
recipients, Emacs is set into French, German, or Hawaiian
input mode as appropriate.  Try to do that in Thunderbird!

However the other side of the coin is that doing many of the
things on Jean's list is automatic or easier with Thunderbird
or an equivalent.  A lot of people just aren't going to
conquer Gnus for these tasks nor would I expect or necessarily
encourage it.

As long-time Emacs users we have learned to develop our own
styles and it has become indispensible --- for us.  I noted
earlier that people find their way to Emacs if Emacs is for
them, certainly with help along the way.  Would you recommend
Emacs to a Facebook and Twitter and WhatsUp devotee?  While
it's possible, it's less likely to be a match.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Bob Newell <bobnewell@bobnewell.net> [2023-01-21 22:34]:
> And a lot more besides, for example, my favorite thing, in
> conjunction with BBDB, when I write to certain mail recipients,
> Emacs is set into French, German, or Hawaiian input mode as
> appropriate.  Try to do that in Thunderbird!

I find that as good integration. In my RCD Notes there is contact
management and people may have "communication language" assigned, in
turn language may have input method set.

What about relations? Person may be member of team A which has main
languag German, but in the list of people B, the main language is
English, so every relation also requires possible designation of the
language. 

We could say "anything is possible" to program with almost any
programming language.

But what we do not have is integration. Integration of small features
into one.

Thunderbid shows how integration works, it helps in usability.

Emacs is full of disintegrated interesting small packages, minimizing
usability.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Milan Glacier <news@milanglacier.com> [2023-01-19 19:12]:
> 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.

Sounds like Deja-Vu. 

I am Emacs user and it is for reasons of being extensible. I am using
it because I am dependant. Not because "it is powerful".

That editor is "powerful" may not be understood by public. And there
are contrary opinions:

5 Powerful Text Editors for Windows - Lifehack:
https://www.lifehack.org/articles/technology/6-powerful-text-editors-for-windows.html

some of them not even mentioning Emacs:

Best text editors of 2023 | TechRadar:
https://www.techradar.com/best/best-text-editors

The power of Emacs stem from its extensibility, as it has programming
language built in, users may extend it how they need. On the other
hand, today many editor have plugins, extensibility is for me the
major thing.

On the other hand, some things simply can't be done in Emacs due it
sluggish performance. Let us say listings in sql-mode, is so much
slower than in XTerm, or putting very many items in
tabulated-list-mode, or handling large font-lock-mode code, or
handling large number of Maildirs.

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

OK fine, and I think opposite, person would just waste his time. 

Emacs just as mutt comes from old times, it has it's design from
terminals.

Thunderbird has been designed to be graphical application from it's
beginning.

When user already know Thunderbird, I can't recommend using something
like Emacs where there is almost no mouse support for management of
e-mails. There is no decent or modern contact management in
Emacs. E-mails and contact management are must, this is 2023, not
1994.

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

Just that Apple Mail is proprietary software, not an option to
recommend to any users of GNU mailing list, as such we don't support
it.

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

Personally, I am aware, and I use myself `mutt' as I can't allow me
sluggish work with Thunderbird. Though objectively users would be
better comforted by using KMail or Thunderbird or Evolution e-mail
clients.

By the way I use `mail' also, to read and send e-mails I need nothing
but `mail' and `ed' editor. 

And too often I edit with `ed' from within Emacs on remote servers.

I can't wait for Tramp in Emacs to load, and finish it's
functions. Entering into remote server and editing files by using
Emacs shell is more convenient. Speeding the connection with SSH
sockets is convenient. Editing e-mail aliases with `ed' and system
files, is convenient and less error prone.

How can I recommend that type of usage to people who are used to
personal computer and graphical applications?

My personal preference would impair their life. They could not
possibly become efficient or speedy with it. 

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

When system is truly powerful it will be ergonomic to human. There
will be hand gestures, and speech recognition. Display may be on a
large TV screen or when user walks to kitchen to fetch a sandwich,
monitor in the kitchen would recognize it and turn itself on, and keep
running the video or editing of the programming code.

Almost any programming language ins powerful for programmer.

But for user of the program, that is for majority of no meaning. What
people need is assistance in their life.

I remember watching 1994 or 1995, perfectly functional speech
recognition software in Germany, and I was thinking alright, that is
what we have to have. It was writing text in German language straight
into some word processing program.

And now is 2023, and we don't have it. There is software, but it is
all in parts and not integrated.

People need integration.

The non-free Android system shows pretty good integration of programs
and assistive technologies for human. It can speak, it can become
accessible, it provides sharing of almost anything to any
communication channel.

E-macs provides e-mails, and there is XMPP/Jabber chat, and IRC, it
possible to connect it to communication channels, but it is all in
parts as it comes from terminal world, not graphical world.

I could imagine nice graphical choice of packages with recognizable
identity icons, and simple descriptions, where user only need to click
once to install it. 

All kinds of sharing to communication channels should be implemented
just as the non-free Android system demonstrates it. 

Then the various assistive computer control like hand gestures, mouse
gestures, eye control, speech recognition -- and THEN we can say it is
powerful.

And that is only two of features we need. Remember 2001: A Space
Odyssey from 1968? That is what I consider how it should be, there
shall be analogous "Hal" computer that listens to human, not only
listens, but knows what is to be done after some training, without any
talks. 

"When I wake up", "every morning", "open up doors, windows, and put my
bed in order". Prepare my toothbrush with toothpaste ready in
bathroom. When I enter bathroom, in the morning, give me middle stream
of water of 19 degree temperature.

When we think of objects in semantic triplets, the above statements
are not hard to define by using speech or text.

https://en.wikipedia.org/wiki/Semantic_triple

Thus programs have to be powerful from human users' view point, not
just from programmers view point.

-- 
Jean

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

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

Re: Debunking Emacs merits over GUI - Re: package for Email

[Milan Glacier]

You have mentioning a good vision.This is the next step of the
Human-Computer Interaction revolution for sure.

However this is something too far away, maybe off the topic too much. I
don't know if there are any free email clients (either GUI or TUI) that
could do what you say. And if so, this is the revolution. There's no need
to recommend them, because they are destined to rule the world.

I once encounter with a proprietary email client that has some
elementary speech interaction support. And again since we are talking at
GNU mailing list I don't recommend it. I only mentions non-free software
when I am making comparison with others such that those non-free
softwares are inferior.

On 01/20/23 12:07, Jean Louis wrote:
>* Milan Glacier <news@milanglacier.com> [2023-01-19 19:12]:
>
>> 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.
>
>When system is truly powerful it will be ergonomic to human. There
>will be hand gestures, and speech recognition. Display may be on a
>large TV screen or when user walks to kitchen to fetch a sandwich,
>monitor in the kitchen would recognize it and turn itself on, and keep
>running the video or editing of the programming code.
>
>Almost any programming language ins powerful for programmer.
>
>But for user of the program, that is for majority of no meaning. What
>people need is assistance in their life.
>
>I remember watching 1994 or 1995, perfectly functional speech
>recognition software in Germany, and I was thinking alright, that is
>what we have to have. It was writing text in German language straight
>into some word processing program.
>
>And now is 2023, and we don't have it. There is software, but it is
>all in parts and not integrated.
>
>People need integration.
>
>The non-free Android system shows pretty good integration of programs
>and assistive technologies for human. It can speak, it can become
>accessible, it provides sharing of almost anything to any
>communication channel.
>
>E-macs provides e-mails, and there is XMPP/Jabber chat, and IRC, it
>possible to connect it to communication channels, but it is all in
>parts as it comes from terminal world, not graphical world.
>
>I could imagine nice graphical choice of packages with recognizable
>identity icons, and simple descriptions, where user only need to click
>once to install it.
>
>All kinds of sharing to communication channels should be implemented
>just as the non-free Android system demonstrates it.
>
>Then the various assistive computer control like hand gestures, mouse
>gestures, eye control, speech recognition -- and THEN we can say it is
>powerful.
>
>And that is only two of features we need. Remember 2001: A Space
>Odyssey from 1968? That is what I consider how it should be, there
>shall be analogous "Hal" computer that listens to human, not only
>listens, but knows what is to be done after some training, without any
>talks.
>
>"When I wake up", "every morning", "open up doors, windows, and put my
>bed in order". Prepare my toothbrush with toothpaste ready in
>bathroom. When I enter bathroom, in the morning, give me middle stream
>of water of 19 degree temperature.
>
>When we think of objects in semantic triplets, the above statements
>are not hard to define by using speech or text.
>
>https://en.wikipedia.org/wiki/Semantic_triple
>
>Thus programs have to be powerful from human users' view point, not
>just from programmers view point.
>
>-- 
>Jean

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Jean Louis <bugs@gnu.support> writes:

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

I think this thread is kind of missing a key point -- history.  I've
been around Emacs for ~40 years (yes, TECO Emacs), but I'm, by no means,
close to being a "Master of Emacs" (we used to call them Gurus).  I
never had time to learn Elisp programming, so I just hacked Elisp code
together to try out new things (basically setq and add-to-hook and,
maybe, advise until packages came along) to help me with my work.

There's a lot of history behind what I just said:

1. The PC Revolution

Mainframes became the backroom land of COBOL that no self-respecting
college grad would go to.  Minis slowly disappeared as PCs began making
their mark.  The problem was that it would be 15-25 years before
affordable PCs that were powerful enough to really support Emacs (and
Linux) became available.  But PCs were the market, so programmers moved
there.

2. Free Software

While RMS' goal may have been laudable, many (most) programmers could
not see how to monetize their work in a free software environment and,
so, went where the money was more plentiful.  Without the investment of
big bucks that copyrighted software could command, development of Emacs
in the 90s slowed to a crawl and depended on the programmer "with an
itch".  Good stuff was done, but it could've been so much more.  This is
why Emacs development took 40 years whereas things might've happened
faster in the more capitalistic world (but Emacs would've been very
different beast!).

3. WWW

The web brought Linux to the forefront in the 1990s because it had the
power for the server applications that DOS and Windows didn't (for
awhile).  The competition for programmers was on, but PCs still had a
huge lead.  Programmers appreciated the Emacs environment, but often had
to use specific tools.

4. Gaming PCs

Games built a big market for more powerful PCs (and vice versa).  Linux
could steadily take advantage of the new power, but PC applications had
a huge lead. Although Linux may have had cross-platform development
capabilities, the preference was for native (MS-Windows) tools, so Emacs
didn't get a lot of attention.

5. Smartphones

The iPhone is still not capable of supporting Emacs and I don't know how
well Android could support Emacs.  Even if they could support Emacs,
Smartphones are GUI-intensive, so not really an environment for a text
editor. So the next generation of users/programmers are going to be
"non-GUI challenged".

6. AI

This is an area that I wasn't in, so I can't say much.  I assume it
will lead to more server systems and Linux (and Emacs) can ride the
coattails.  The tools for AI may be more in the Linux world, so the
landscape could change.

The editor wars are long over -- Visual Studio (and it's ilk) won.
Everything else is just trying to fit in around the edges...

(But I still like Emacs!)

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Cc: Gottfried <gottfried@posteo.de>,  "help-gnu-emacs@gnu.org"
>  <help-gnu-emacs@gnu.org>
> Date: Fri, 20 Jan 2023 22:04:08 -0800
> 
> 2. Free Software
> 
> While RMS' goal may have been laudable, many (most) programmers could
> not see how to monetize their work in a free software environment and,
> so, went where the money was more plentiful.  Without the investment of
> big bucks that copyrighted software could command, development of Emacs
> in the 90s slowed to a crawl and depended on the programmer "with an
> itch".

The "slowed to a crawl" part doesn't match the facts: the rate of
commits in the 90s doesn't fall below that of 2000s or 2010s.  In
particular, addition of GUI X frames and m18n (a.k.a. "MULE") to Emacs
belong to the 90s: hardly a non-development.  And the development of
the current display engine started in 1998 and ended in 2000, so
technically also a "90s" feature.  Not bad for "capital-deprived"
project!

> 5. Smartphones
> 
> The iPhone is still not capable of supporting Emacs and I don't know how
> well Android could support Emacs.

See the feature/android branch in the Emacs Git repository.

> Even if they could support Emacs, Smartphones are GUI-intensive, so
> not really an environment for a text editor.

Not true, at least not in such an absolute wording.  Smartphones do
provide apps to edit text, and many people would like access to their
Org and TODO lists on the smartphone, let alone read email.

Bottom line: when you are trying to make a point, don't overdo it, and
always check against the actual facts.

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Emanuel Berg]

Eli Zaretskii wrote:

> Bottom line: when you are trying to make a point, don't
> overdo it, and always check against the actual facts.

Do it yourself, Eli ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[tomas]

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

On Sat, Jan 21, 2023 at 09:10:15AM +0200, Eli Zaretskii wrote:

[...]

> Bottom line: when you are trying to make a point, don't overdo it, and
> always check against the actual facts.

In short: "all generalizstions suck" (anonymous ;-)

And yes, people don't seem to be aware how lively Emacs's repository
is.

Cheers
-- 
t

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

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Bob Newell]

>> The iPhone is still not capable of supporting Emacs and I don't know how
>> well Android could support Emacs.

I don't know anything about iPhones but my Android phones run
the Termux subsystem and support Emacs and all of my
text-mode working environment at the 100% level.  I can be
just as productive[1] on my Android phones as I can on the Dell
desktop running Arch Linux that I'm using at the moment.
-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

[1] Limitations being mostly text only[2] (not much of a limitation for
most of my work), and of course as a certified Old Person, the
small phone screens don't appeal to my poor vision. Also, an
external keyboard is really, really a good thing.

[2] Things like PDF readers, image viewers, etc., are easily
invoked from within Emacs on my Android devices.

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Bob Newell <bobnewell@bobnewell.net> writes:

>>> The iPhone is still not capable of supporting Emacs and I don't know how
>>> well Android could support Emacs.

> I don't know anything about iPhones but my Android phones run the
> Termux subsystem and support Emacs and all of my text-mode working
> environment at the 100% level.  I can be just as productive[1] on my
> Android phones as I can on the Dell desktop running Arch Linux that
> I'm using at the moment.

iPhones are not there.  If I set it up, I suppose I could SSH to my
laptop, but that's not the same -- seems too much against the grain.

Which is kind of my point that Linux (and Emacs) might have been much
bigger if the AT&T UnixPC had won out over DOS/Windows in the mid-80s.

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* Bob Newell <bobnewell@bobnewell.net> [2023-01-21 22:45]:
> I don't know anything about iPhones but my Android phones run
> the Termux subsystem and support Emacs and all of my
> text-mode working environment at the 100% level.  I can be
> just as productive[1] on my Android phones as I can on the Dell
> desktop running Arch Linux that I'm using at the moment.

I have wireless keyboard that is easily attached to the table, so it
helps me write stuff on the go.

> [1] Limitations being mostly text only[2]

I am sure that graphical Emacs works as well, I just did not install
it yet.

You may see if you can run this package and install Emacs under some
of GNU/Linux distributions on Android:

AnLinux | F-Droid - Free and Open Source Android App Repository
https://f-droid.org/en/packages/exa.lnx.a/

and it will work with external keyboard well.

-- 
Jean

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

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

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Masterson <dsmasterson@gmail.com>
>> Cc: Gottfried <gottfried@posteo.de>,  "help-gnu-emacs@gnu.org"
>>  <help-gnu-emacs@gnu.org>
>> Date: Fri, 20 Jan 2023 22:04:08 -0800
>> 
>> 2. Free Software
>> 
>> While RMS' goal may have been laudable, many (most) programmers could
>> not see how to monetize their work in a free software environment and,
>> so, went where the money was more plentiful.  Without the investment of
>> big bucks that copyrighted software could command, development of Emacs
>> in the 90s slowed to a crawl and depended on the programmer "with an
>> itch".
>
> The "slowed to a crawl" part doesn't match the facts: the rate of
> commits in the 90s doesn't fall below that of 2000s or 2010s.  In
> particular, addition of GUI X frames and m18n (a.k.a. "MULE") to Emacs
> belong to the 90s: hardly a non-development.  And the development of
> the current display engine started in 1998 and ended in 2000, so
> technically also a "90s" feature.  Not bad for "capital-deprived"
> project!

You're right. That was impertinent of me.  While I used it in my work, I
was not on the development of Emacs.

Wasn't the display engine derived from Lucid Emacs?

>> 5. Smartphones
>> 
>> The iPhone is still not capable of supporting Emacs and I don't know how
>> well Android could support Emacs.
>
> See the feature/android branch in the Emacs Git repository.

Ooo  8)

>> Even if they could support Emacs, Smartphones are GUI-intensive, so
>> not really an environment for a text editor.
>
> Not true, at least not in such an absolute wording.  Smartphones do
> provide apps to edit text, and many people would like access to their
> Org and TODO lists on the smartphone, let alone read email.

True.  BeOrg provides a bridge, but it's certainly not Emacs.  The base
of Emacs seems keyboard-driven and you're not going to do a lot of
keyboarding on a smartphone (thus the GUI remark).

> Bottom line: when you are trying to make a point, don't overdo it, and
> always check against the actual facts.

Good point

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 21 Jan 2023 19:08:26 -0800
> 
> Wasn't the display engine derived from Lucid Emacs?

No, it was coded by Gerd Möllmann from scratch.  Some features were
borrowed from XEmacs, but only as far as the specification, behavior,
and UX are concerned; no code was taken, AFAIR.

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Masterson <dsmasterson@gmail.com>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Sat, 21 Jan 2023 19:08:26 -0800
>> 
>> Wasn't the display engine derived from Lucid Emacs?
>
> No, it was coded by Gerd Möllmann from scratch.  Some features were
> borrowed from XEmacs, but only as far as the specification, behavior,
> and UX are concerned; no code was taken, AFAIR.

My memory is faulty as well.  I remember JamieZ wanting to get the Lucid
Emacs code into Gnu Emacs and Stallman having a problem with (IIRC) the
proprietariness of it, but the details were too "in the weeds" for me to
follow.  I thought there was a "meeting of minds" (of a sort) that
allowed the Lucid code to be used to some degree, but I suppose your
recollection is more proper.

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 22 Jan 2023 11:33:54 -0800
> 
> >> Wasn't the display engine derived from Lucid Emacs?
> >
> > No, it was coded by Gerd Möllmann from scratch.  Some features were
> > borrowed from XEmacs, but only as far as the specification, behavior,
> > and UX are concerned; no code was taken, AFAIR.
> 
> My memory is faulty as well.  I remember JamieZ wanting to get the Lucid
> Emacs code into Gnu Emacs and Stallman having a problem with (IIRC) the
> proprietariness of it, but the details were too "in the weeds" for me to
> follow.

That was about 10 years before the Emacs 21 display engine was
designed and implemented.

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Po Lu]

David Masterson <dsmasterson@gmail.com> writes:

> You're right. That was impertinent of me.  While I used it in my work, I
> was not on the development of Emacs.
>
> Wasn't the display engine derived from Lucid Emacs?

No, it was written by the maintainer at the time for GNU Emacs 21.

> True.  BeOrg provides a bridge, but it's certainly not Emacs.  The base
> of Emacs seems keyboard-driven and you're not going to do a lot of
> keyboarding on a smartphone (thus the GUI remark).

I suggest you keep an eye on the feature/android branch over the next
week or so.

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Po Lu <luangruo@yahoo.com> writes:

> David Masterson <dsmasterson@gmail.com> writes:
>
>> True.  BeOrg provides a bridge, but it's certainly not Emacs.  The base
>> of Emacs seems keyboard-driven and you're not going to do a lot of
>> keyboarding on a smartphone (thus the GUI remark).
>
> I suggest you keep an eye on the feature/android branch over the next
> week or so.

8-)

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Jean Louis]

* David Masterson <dsmasterson@gmail.com> [2023-01-21 09:10]:
> While RMS' goal may have been laudable, many (most) programmers could
> not see how to monetize their work in a free software environment and,
> so, went where the money was more plentiful.  Without the investment of
> big bucks that copyrighted software could command, development of Emacs
> in the 90s slowed to a crawl and depended on the programmer "with an
> itch".  Good stuff was done, but it could've been so much more.  This is
> why Emacs development took 40 years whereas things might've happened
> faster in the more capitalistic world (but Emacs would've been very
> different beast!).

I agree to your points. Though if you say that Emacs could have been
more suitable to general public if it would be proprietary, maybe yes,
but it would not be extensible.

As proprietary decisions would lead to control of people, and
extensibility features are not part of it. 

And proprietary Emacs would not include too many features, as they
would be wasting resources, and not bringing money, as you said.

> 5. Smartphones
> 
> The iPhone is still not capable of supporting Emacs and I don't know how
> well Android could support Emacs.  Even if they could support Emacs,
> Smartphones are GUI-intensive, so not really an environment for a text
> editor. So the next generation of users/programmers are going to be
> "non-GUI challenged".

Right.

Emacs runs without problem in Termux for Replicant/Android and similar
systems. There is nice tap-keyboard, with CTRL, ALT, etc. which is
locked, user can basically use single finger to get all Emacs
commands. 

There is effort on Emacs Development mailing list to make Emacs for
Android with GUI.


-- 
Jean

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

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

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[David Masterson]

Jean Louis <bugs@gnu.support> writes:

> * David Masterson <dsmasterson@gmail.com> [2023-01-21 09:10]:
>> While RMS' goal may have been laudable, many (most) programmers could
>> not see how to monetize their work in a free software environment and,
>> so, went where the money was more plentiful.  Without the investment of
>> big bucks that copyrighted software could command, development of Emacs
>> in the 90s slowed to a crawl and depended on the programmer "with an
>> itch".  Good stuff was done, but it could've been so much more.  This is
>> why Emacs development took 40 years whereas things might've happened
>> faster in the more capitalistic world (but Emacs would've been very
>> different beast!).
>
> I agree to your points. Though if you say that Emacs could have been
> more suitable to general public if it would be proprietary, maybe yes,
> but it would not be extensible.

Not necessarily.  The ELisp engine in Emacs would've continued being
developed in a proprietary way, but Elisp packages could continue to be
developed by anybody.  The company might even see value in hosting
package libraries.

The value-add might be faster development of things like multi-threading
Emacs exposed to Elisp, portability to more platforms (smartphones),
better support (theoretically!), and so on.

The downside is a repeat of TECO Emacs on DEC mainframes when DEC died
in the early 80s.

>> 5. Smartphones
>> 
>> The iPhone is still not capable of supporting Emacs and I don't know how
>> well Android could support Emacs.  Even if they could support Emacs,
>> Smartphones are GUI-intensive, so not really an environment for a text
>> editor. So the next generation of users/programmers are going to be
>> "non-GUI challenged".
>
> Right.
>
> Emacs runs without problem in Termux for Replicant/Android and similar
> systems. There is nice tap-keyboard, with CTRL, ALT, etc. which is
> locked, user can basically use single finger to get all Emacs
> commands. 
>
> There is effort on Emacs Development mailing list to make Emacs for
> Android with GUI.

Really?!?  Sounds interesting.  I've used iPhones, but I might have to
look into an Android.

-- 
David Masterson

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Emanuel Berg]

David Masterson wrote:

> I think this thread is kind of missing a key point --
> history. I've been around Emacs for ~40 years (yes,
> TECO Emacs), but I'm, by no means, close to being a
> "Master of Emacs" (we used to call them Gurus). I never had
> time to learn Elisp programming, so I just hacked Elisp code
> together to try out new things (basically setq and
> add-to-hook and, maybe, advise until packages came along) to
> help me with my work.

Interesting, please write more computer history whenever and
as much as you feel like! <3

> There's a lot of history behind what I just said:
>
> 1. The PC Revolution
>
> Mainframes became the backroom land of COBOL that no
> self-respecting college grad would go to. Minis slowly
> disappeared as PCs began making their mark. The problem was
> that it would be 15-25 years before affordable PCs that were
> powerful enough to really support Emacs

Really, that long? :O

> 2. Free Software
>
> While RMS' goal may have been laudable, many (most)
> programmers could not see how to monetize their work in
> a free software environment and, so, went where the money
> was more plentiful. Without the investment of big bucks that
> copyrighted software could command, development of Emacs in
> the 90s slowed to a crawl and depended on the programmer
> "with an itch". Good stuff was done, but it could've been so
> much more. This is why Emacs development took 40 years
> whereas things might've happened faster in the more
> capitalistic world (but Emacs would've been very different
> beast!).

It's enough that the people who likes it enough to do it,
do it. Gets more real that way and a better community, of
doers and users rather than managers and PR guys ...

> 5. Smartphones
>
> The iPhone is still not capable of supporting Emacs and
> I don't know how well Android could support Emacs. Even if
> they could support Emacs, Smartphones are GUI-intensive, so
> not really an environment for a text editor.

They don't have to be, there are text-based Android apps and
plugin a physical keyboard and you should have, I don't
know, something. I prefer the comfort of other solutions but
it should be possible, and absolutely so in the long run, for
people who wants that.

> So the next generation of users/programmers are going to be
> "non-GUI challenged".

It's to early to say, as the Chinese Zhou Enlai first premier
said when asked about the significance of the French
revolution ...

> [AI] is an area that I wasn't in, so I can't say much.
> I assume it will lead to more server systems and Linux (and
> Emacs) can ride the coattails. The tools for AI may be more
> in the Linux world, so the landscape could change.

In 1000 years there won't be a single job a human can do -
physical, analytical, mental, even purely emotional if there
are such jobs - that will outperform a machine doing the
same thing.

Programs that program programs should be just around
the corner.

PS. This message is sent by a human being. My name is
    Emanuel Berg and I approve this message. And I'm not just
    saying that! Heer is a typo to prove I'm not a machine.
    Really ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: History Re: Debunking Emacs merits over GUI - Re: package for Email

[Po Lu]

Emanuel Berg <incal@dataswamp.org> writes:

>> 2. Free Software
>>
>> While RMS' goal may have been laudable, many (most)
>> programmers could not see how to monetize their work in
>> a free software environment and, so, went where the money
>> was more plentiful. Without the investment of big bucks that
>> copyrighted software could command, development of Emacs in
>> the 90s slowed to a crawl and depended on the programmer
>> "with an itch". Good stuff was done, but it could've been so
>> much more. This is why Emacs development took 40 years
>> whereas things might've happened faster in the more
>> capitalistic world (but Emacs would've been very different
>> beast!).

I remind everyone that proprietary versions of Emacs developed by
computer companies have existed in the past, along with versions that
were free software, also developed by computer companies.

Instead of making such generalizations, I suggest looking at the fate of
all of those Emacsen: CCA Emacs, Unipress Emacs, Lucid Emacs and more.

>> 5. Smartphones
>>
>> The iPhone is still not capable of supporting Emacs and
>> I don't know how well Android could support Emacs. Even if
>> they could support Emacs, Smartphones are GUI-intensive, so
>> not really an environment for a text editor.
>
> They don't have to be, there are text-based Android apps and
> plugin a physical keyboard and you should have, I don't
> know, something. I prefer the comfort of other solutions but
> it should be possible, and absolutely so in the long run, for
> people who wants that.

There's also the feature/android branch, which is almost ready to be
merged into master.

Also, I don't use a physical keyboard with my Android device, yet Emacs
works fine for reading and composing mail and news.

Re: package for Email

[Filipp Gunbin]

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

Hi,

On 18/01/2023 13:56 +0000, Gottfried wrote:

> Hi everybody,
>
> I am using thunderbird for emails.
> My question:
>
> 1. Which Email package do you use?
> Can you tell your experience with your email package?

Gnus.  With just (oh!) 200 lines of elisp configuration, it's almost
perfect.

> 2. Does it make sense for me as an emacs-newbie to change from using
> thunderbird to an emacs email package?

Yes.

> 3. There are
> Rmail, GNU, Wanderlust, Mu4e etc...

GNU -> Gnus?

> 4. I prefer to habe folders because I like to have an overview.
> Mu4e doesn't have folders.

Gnus has two levels of hierarchy: servers and groups within them.

You'll be dealing with a (single) list of groups, where each group comes
from a different "server".  A server may be a remote IMAP server, or a
local one (see (info "(gnus) Choosing a Mail Back End") for local
storage options).

> 5. I want IMAP.
> Do all of them provide IMAP? (does Rmail now provide IMAP)?

Gnus provides it.

> 6. Wanderlust seems to be more difficult to set up, and I still have
> trouble because I am an Emacs-newbie.

Cannot comment on this.

> 7. Which one is easier to use?

Perhaps Rmail, but I cannot tell for sure.

> 8. Should I start with Rmail? and later switch to GNU?
>
> At the moment I don't need GNU for reading news etc...

I never read news in Gnus, only use it as mail client.

> 9. Or is it useful to start with GNU because it has more options and I
> have to learn it anyhow? and I can use it with org-mode?

I'd say that Gnus is worth investing time into it.

> 10. Do all of them have the same or similar keybindings or do I have
> to learn for each one separate keybindings?

I don't know.

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

As usual, common editing experience with other things you do in Emacs,
customization, automating stuff by writing Elisp etc...

Filipp

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

Re: package for Email

[Emanuel Berg]

Gottfried wrote:

> 1. Which Email package do you use? Can you tell your
>    experience with your email package?

Gnus ...

> 2. Does it make sense for me as an emacs-newbie to change
>    from using thunderbird to an emacs email package?

Yes, if you feel Emacs is the software for you.

> 4. I prefer to habe folders because I like to have an
>    overview. Mu4e doesn't have folders.

Gnus has folders, they are called groups.

> 5. I want IMAP.

Gnus has everything, it's the longest program ever written.

> 8. Should I start with Rmail? and later switch to GNU?

No.

> 9. Or is it useful to start with GNU because it has more
>    options and I have to learn it anyhow? [...]

Gnus has more options but you only learn the subset that you
use. Some options you don't really learn, you learn them
enough to put into a config file and then forget about
them ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: package for Email

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-19 14:46]:
> > 5. I want IMAP.
> 
> Gnus has everything, it's the longest program ever written.

It can't handle Maildir folders as it has its own stuff, duplicating
emails inside without informing me as user, terrible experience. 

When using it from scratch, fine, but not for my 50K+ conversations.

And yes, bug was reported long ago. Nothing that can be done about it.

-- 
Jean

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

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

Re: package for Email

[Martin Steffen]

>>>>> "Emanuel" == Emanuel Berg <incal@dataswamp.org> writes:

    Emanuel> Gottfried wrote:

    >> 1. Which Email package do you use? Can you tell your experience
    >> with your email package?

    Emanuel> Gnus ...

me too. 

    >> 2. Does it make sense for me as an emacs-newbie to change from
    >> using thunderbird to an emacs email package?

    Emanuel> Yes, if you feel Emacs is the software for you.

I would agree

    >> 4. I prefer to habe folders because I like to have an
    >> overview. Mu4e doesn't have folders.

    Emanuel> Gnus has folders, they are called groups.

    >> 5. I want IMAP.

    Emanuel> Gnus has everything, it's the longest program ever written.

    >> 8. Should I start with Rmail? and later switch to GNU?

    Emanuel> No.

I agree (but qualified). I used RMAIL when I started with emacs (long
time ago, and I think I used other emacs email software), gnus is way
more versatile. One thing that may speak against it is it can be
complex.


Actually, I started having troubles locally, after my organization did
no longer supported IMAP properly (which as a consequence mean, all
email clients/user programs work excellently as long as they are called
outlook). It required more and more fiddling to get the email experience
I want. And I guess it will get harder, since for some reason there will
soon be mandatory 2factor authentfication for reading emails.

but since gnus can be quite a monster, probably if one is a complete
beginner to emacs _and_ at the same time wants to use email in emacs,
gnus might be a challenge.


Martin


    >> 9. Or is it useful to start with GNU because it has more options
    >> and I have to learn it anyhow? [...]

    Emanuel> Gnus has more options but you only learn the subset that
    Emanuel> you use. Some options you don't really learn, you learn
    Emanuel> them enough to put into a config file and then forget about
    Emanuel> them ...

    Emanuel> -- underground experts united https://dataswamp.org/~incal

Re: package for Email

[Eric S Fraga]

On Thursday, 19 Jan 2023 at 15:10, Martin Steffen wrote:
> I agree (but qualified). I used RMAIL when I started with emacs (long
> time ago, and I think I used other emacs email software), gnus is way
> more versatile. One thing that may speak against it is it can be
> complex.

+1 having gone from RMAIL to VM to wl to gnus (with mutt somewhere in
the middle).

> Actually, I started having troubles locally, after my organization did
> no longer supported IMAP properly (which as a consequence mean, all
> email clients/user programs work excellently as long as they are called
> outlook). 

I've had the same problem including 2FA introduced two years ago.  I'm
using davmail as an intermediary to ensure I can keep using gnus.  Works
well.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2022-12-05) on Debian 11.5

Re: package for Email

[Jude DaShiell]

mutt has a script called fleacollar.sh in one of its directories.  The
script asks users questions and based on the answers sets up mutt when
successful so users can use mutt.  Could gnus benefit from a similar
effort?  I think whenever a software package gets a complex reputation
this is one thing the original developer or any other developers could do
for the package to increase its useage.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

Re: package for Email

[Jean Louis]

* Jude DaShiell <jdashiel@panix.com> [2023-01-19 19:41]:
> mutt has a script called fleacollar.sh in one of its directories.  The
> script asks users questions and based on the answers sets up mutt when
> successful so users can use mutt.

I have not find that script in the repository of `mutt'. Is it maybe
part of some older version of mutt? Or maybe it is OS distribution
based script?

> Could gnus benefit from a similar effort?

We could all benefit in many packages to have that type of smart
helper or installer, explaining it to us, and helping with the initial
configuration.

And more of the splash screen type full screen menus for user access
to functions, even by using the mouse.

-- 
Jean

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

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

Re: package for Email

[Leo Butler]

On Thu, Jan 19 2023, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> On Thursday, 19 Jan 2023 at 15:10, Martin Steffen wrote:
>> I agree (but qualified). I used RMAIL when I started with emacs (long
>> time ago, and I think I used other emacs email software), gnus is way
>> more versatile. One thing that may speak against it is it can be
>> complex.
>
> +1 having gone from RMAIL to VM to wl to gnus (with mutt somewhere in
> the middle).
>
>> Actually, I started having troubles locally, after my organization did
>> no longer supported IMAP properly (which as a consequence mean, all
>> email clients/user programs work excellently as long as they are called
>> outlook). 
>
> I've had the same problem including 2FA introduced two years ago.  I'm
> using davmail as an intermediary to ensure I can keep using gnus.  Works
> well.

I encountered the same problem when my employer introduced mandatory 2fa
last year. I use davmail+gnus like you, but I cannot recommend it:
davmail is fiendishly slow, does not cope well with a mobile existence
(i.e. suspend & resume) and makes a large number of mistakes involving
copying & deleting emails.

I would *love* to have a working 2fa layer for gnus that works as
painlessly as thunderbird's without needing something like davmail.

FWIW,
Leo

Re: package for Email

[Eric S Fraga]

On Thursday, 19 Jan 2023 at 17:00, Leo Butler wrote:
> I encountered the same problem when my employer introduced mandatory 2fa
> last year. I use davmail+gnus like you, but I cannot recommend it:
> davmail is fiendishly slow, does not cope well with a mobile existence
> (i.e. suspend & resume) and makes a large number of mistakes involving
> copying & deleting emails.

I guess I should have made it clear that I use POP instead of IMAP to
access my Exchange server so all manipulation after that is gnus alone
(minimising my exposure to Outlook/Exchange).  It could be that access
with IMAP is more finicky.

> I would *love* to have a working 2fa layer for gnus that works as
> painlessly as thunderbird's without needing something like davmail.

Yes, a built-in solution in gnus/Emacs would be welcome.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-01-06) on Debian 11.5

Re: package for Email

[Milan Glacier]

On 01/19/23 16:20, Eric S Fraga wrote:
>On Thursday, 19 Jan 2023 at 15:10, Martin Steffen wrote:
>> I agree (but qualified). I used RMAIL when I started with emacs (long
>> time ago, and I think I used other emacs email software), gnus is way
>> more versatile. One thing that may speak against it is it can be
>> complex.
>
>+1 having gone from RMAIL to VM to wl to gnus (with mutt somewhere in
>the middle).
>
>> Actually, I started having troubles locally, after my organization did
>> no longer supported IMAP properly (which as a consequence mean, all
>> email clients/user programs work excellently as long as they are called
>> outlook).
>
>I've had the same problem including 2FA introduced two years ago.  I'm
>using davmail as an intermediary to ensure I can keep using gnus.  Works
>well.

Have a try on Davmail? Davmail works as a mediator (an local IMAP
server) that exchanges with remote server and then forward to your MUA. And
it supports at least 2FA for office365 email accounts.

Re: package for Email

[Jean Louis]

Among all synchronization tools, I find program `movemail' which is
also supported by Emacs, more useful, as it supports all kinds of
mailboxes, it is part of GNU Mailutils.

GNU Mailutils:
https://mailutils.org/

Usage instructions:

$ movemail --help
Usage: movemail [OPTION...] inbox-url destfile [POP-password]
GNU movemail -- move messages across mailboxes.

      --[no-]emacs           output information used by Emacs rmail interface
      --[no-]ignore-errors   try to continue after errors
      --max-messages=NUMBER  process at most NUMBER messages
  -m, --[no-]progress-meter  enable progress meter
      --[no-]notify          enable biff notification
      --onerror=KW[,KW...]   what to do on errors
  -P, --owner=MODELIST       control mailbox ownership
  -p, --[no-]preserve, --keep-messages
                             preserve the source mailbox
      --program-id=FMT       set program identifier for diagnostics (default:
                             program name)
  -r, --[no-]reverse         reverse the sorting order
  -u, --[no-]uidl            use UIDLs to avoid downloading the same message
                             twice
  -v, --verbose              increase verbosity level

I use it like this, but in a program that is invoked by crontab,
Common Lisp:

(defun movemail (mailbox)
  (let ((pids (shell-1st-result "pgrep -f movemail")))
    (if pids (error "Other movemail processs exists.")
	(concatenate 'string
	       "timeout 10m /usr/local/bin/movemail -m "
	       ;; "movemail "
               (when debug "--debug-level='mailbox.prot,!trace6' ")
               "-v 'imaps://" username ":" password "@" server ":" port "/"
	       (car (gethash (intern mailbox) mailboxes)) "' \""
	       (cadr (gethash (intern mailbox) mailboxes))
	       "\""))))

So it would be like:

$ timeout 10m /usr/local/bin/movemail -m 'imaps://USERNAME:PASSWORD@example.com:993/INBOX' ~/Maildir

or other server folders are transferred to local maildirs:

$ timeout 10m /usr/local/bin/movemail -m 'imaps://USERNAME:PASSWORD@example.com:993/INBOX.OtherFolder' ~/Maildir/otherfolder


--
Jean

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

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

Re: package for Email

[John Haman]

I use Gnus, and like others have said, with some configuration, it is
very nice. I use nnimap backend with fastmail accounts, and it is indeed
fast. I like that I don't have to download all my email on every
computer. And I like reading my mails, nntp, web feeds in one place. My
gnus settings are more portable than my tbird settings.

I don't recommend Gnus unless you have a lot of time to configure Emacs
and don't do any business/HTML email.

I still prefer thunderbird for the calendar.

--
Dr. John Haman
Maryland, USA

Re: package for Email

[Emanuel Berg]

John Haman wrote:

> I don't recommend Gnus unless you have a lot of time to
> configure Emacs and don't do any business/HTML email.

?

"business" email.

-- 
underground experts united
https://dataswamp.org/~incal

Re: package for Email

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-21 16:44]:
> John Haman wrote:
> 
> > I don't recommend Gnus unless you have a lot of time to
> > configure Emacs and don't do any business/HTML email.
> 
> ?
> 
> "business" email.

With Gnus which I can't recommend to people instead of Thunderbird,
people can write efficiently business e-mails. 

If they can write HTML, I don't know, but knowing Emacs, I am sure
that can be done.

With `mutt' is matter of small settings to write in any mode, like
Markdown or Org mode, and to convert from inside of Mutt into HTML
attachment. It can be single keystroke. By that sense, I am sure in
Gnus this could workd too.

-- 
Jean

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

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

Re: package for Email

[Jude DaShiell]

aert has a user-friendly account setup feature and is ui-agnostic.  It may
have other attractive features to examine.  I just learned about this one
a few days ago and will check it out further in time.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

Re: package for Email

[Bob Newell]

>> > I don't recommend Gnus unless you have a lot of time to
>> > configure Emacs and don't do any business/HTML email.

I do ALL my business email, dozens of messages per day, in
Gnus.

I don't send HTML email but Gnus reads it with just a small
amount of setup (one line, if memory serves).

When Gnus is set up to work along with BBDB, it opens up
enormous possibilities of customizations very useful to the
business world.

I won't minimize the amount of time that has gone into setting
up Gnus to work as I wish.  I started out with Gnus about 15
years ago when a then-colleague suggested it to me when I was
using viewmail (VM) instead.  Gnus of course is not perfect;
nothing is.  But I have yet to find a single relevant task[1]
that Gnus cannot do.  Whenever I think, "I'd like to do X with
email" Gnus always comes through either natively or with some
elisp coding.

To get Gnus to where you want it, you do have to walk down
something of a long-ish road, but the payoff is huge.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

[1] Let's stick to relevant tasks.  Gnus cannot do my laundry,
although that would be a great addition.

Re: package for Email

[David Masterson]

Bob Newell <bobnewell@bobnewell.net> writes:

>>> > I don't recommend Gnus unless you have a lot of time to
>>> > configure Emacs and don't do any business/HTML email.
>
> I do ALL my business email, dozens of messages per day, in
> Gnus.

Lucky you.

> To get Gnus to where you want it, you do have to walk down
> something of a long-ish road, but the payoff is huge.

It's lonely, though, working on a programming team using various
proprietary software (MS Office, Outlook, etc.), you can't get support
for the stuff you're used to, your docs/emails don't conform to office
standards (wrong template), and projects are due.

Hopefully, this has changed since I worked.

-- 
David Masterson

Re: package for Email

[Bob Newell]

David Masterson <dsmasterson@gmail.com> writes:

> Bob Newell <bobnewell@bobnewell.net> writes:
>
>>>> > I don't recommend Gnus unless you have a lot of time to
>>>> > configure Emacs and don't do any business/HTML email.
>>
>> I do ALL my business email, dozens of messages per day, in
>> Gnus.
>
> Lucky you.

I am currently in an environment where I am effectively the
(volunteer) CEO of a small organization, so I get to do pretty
much what I want.  But see below.

> It's lonely, though, working on a programming team using various
> proprietary software (MS Office, Outlook, etc.), you can't get support
> for the stuff you're used to, your docs/emails don't conform to office
> standards (wrong template), and projects are due.
>
> Hopefully, this has changed since I worked.

I am also retired.  But still in my current volunteer
position, even though I'm at the top of the food chain, I have
to deal with the ingrained MS culture among the office staff
and the other directors.  The problem is very little with
email exchange, though--- it's primarily document exchange,
with one director insisting on using Word as a page layout
program.

However --- pre-retirement --- I was able to do quite well
running Linux in a scientific lab environment where people
sort of did what they want.  There were some issues with Word
and Powerpoint but by and large it worked out.  In fact it was
at that Lab that a colleague got me started on Gnus.  I had
always thought of Gnus as big and wild and untamed.  I wasn't
wrong, but the colleague showed me that with some effort there
were great advantages to be had.

Of course in a typical corporate setting that indeed would
have been problematic.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: package for Email

[David Masterson]

Emanuel Berg <incal@dataswamp.org> writes:

> John Haman wrote:
>
>> I don't recommend Gnus unless you have a lot of time to
>> configure Emacs and don't do any business/HTML email.
>
> ?
>
> "business" email.

MS Office?

-- 
David Masterson

Re: package for Email

[Emanuel Berg]

David Masterson wrote:

>>> I don't recommend Gnus unless you have a lot of time to
>>> configure Emacs and don't do any business/HTML email.
>>
>> ?
>>
>> "business" email.
>
> MS Office?

Ha! Indeed.

Seriously, setting up a minimal Gnus that will work for mail
isn't difficult at all, and should offer no problems for
anyone who comes from/wants to be in the Emacs or just
generally the TUI/CLI world.

I think that Gnus should streamline its interface, and
increase the level of automation, in particular in moving
between buffers, so as for my personal experience, I put a lot
of IMO "unnecessary" work into that [1].

But just speaking broadly, it's just like with Emacs
in general. To start it, move point around and edit a source
file, that can be mastered in 24h, especially, again, to
a person who has the TUI/CLI computer personality.

If you OTOH want to master Lisp, understand all of Emacs,
configure it to your liking down to the tiniest detail, even
write additional stuff and so on - then yes, I agree, that
requires "a lot of time" :)

[1] https://dataswamp.org/~incal/emacs-init/gnus/

-- 
underground experts united
https://dataswamp.org/~incal

Re: package for Email

[Milan Glacier]

On 01/19/23 01:08, John Haman wrote:
>
>I use Gnus, and like others have said, with some configuration, it is
>very nice. I use nnimap backend with fastmail accounts, and it is indeed
>fast. I like that I don't have to download all my email on every
>computer. And I like reading my mails, nntp, web feeds in one place. My
>gnus settings are more portable than my tbird settings.
>
>I don't recommend Gnus unless you have a lot of time to configure Emacs
>and don't do any business/HTML email.

I think reading business email is okay for plain text based MUA. Usually
business email has alternative plain text form which is readable. And if
you want to compose HTML email, you can write orgmode emails and then
converted it to HTML (this is done by package: org-msg).

Re: package for Email

[Emanuel Berg]

Milan Glacier wrote:

>> I use Gnus, and like others have said, with some
>> configuration, it is very nice. I use nnimap backend with
>> fastmail accounts, and it is indeed fast. I like that
>> I don't have to download all my email on every computer.
>> And I like reading my mails, nntp, web feeds in one place.
>> My gnus settings are more portable than my tbird settings.
>>
>> I don't recommend Gnus unless you have a lot of time to
>> configure Emacs and don't do any business/HTML email.
>
> I think reading business email [...]

Is that like the tickets in the airlines, business class?

-- 
underground experts united
https://dataswamp.org/~incal

Re: package for Email

[Jean Louis]

* Milan Glacier <news@milanglacier.com> [2023-01-20 07:11]:
> On 01/19/23 01:08, John Haman wrote:
> > 
> > I use Gnus, and like others have said, with some configuration, it is
> > very nice. I use nnimap backend with fastmail accounts, and it is indeed
> > fast. I like that I don't have to download all my email on every
> > computer. And I like reading my mails, nntp, web feeds in one place. My
> > gnus settings are more portable than my tbird settings.
> > 
> > I don't recommend Gnus unless you have a lot of time to configure Emacs
> > and don't do any business/HTML email.
> 
> I think reading business email is okay for plain text based MUA.

Definitely. Just that majority of businessmen on this world can't
agree with me.

First in business, we may get a lot of spam, and lot of
tracking. Coincidentallyand due to lack of HTML in text based mail
user agents, we are spared of tracking and surveillance. 

On the other hand, one percentage of businessmen do not have text
e-mails, and thy arrive as HTML, we have to somehow read that.

And speedy writing, parsing, searching, manipulating, bouncing,
forwarding, it is all there and very useful.

And yet, it is not objectively real to recommend such program to
modern business people.

The time to tell that it is useful is when it really can make some
money out of that usefulness.

> Usually business email has alternative plain text form which is
> readable. And if you want to compose HTML email, you can write
> orgmode emails and then converted it to HTML (this is done by
> package: org-msg).

Okay, I do understand. And Org mode allows easy writing, hyperlinks,
images, tables and pretty easy conversions to HTML or other formats.

And at this point I like to give you something for thinking:

TECHNOLOGY TEMPLATE PROJECT OHS Framework :
https://www.dougengelbart.org/content/view/110/460/

where it says:

| From                | To                      |
|---------------------+-------------------------|
| Tool-centric system | Document-centric system |

Let's think of the workflow:
----------------------------

1. Launch tool program (like Mutt, or any)

2. Find recipient's contact

3. Write document 

4. Send it.

5. Realize after some time you may be writing same markup documents or
   same documents, or having repetition, like attaching files numerous
   times, and so on.


How about this workflow:
------------------------

1. Write document once and all attachments.

2. Relate person to document.

3. Press key, choose person, dispatch.

In this way user does not really deal with e-mail program directly,
only decides that some information shall be sent to specific people. 

E-mail is multi part by MIME standard.

Instead of giving to user to put this picture, that audio, and
presentation, and PDF file, e-mail introduction and cover letter, and
letting user do all that work with e-mail and attachments, it is more
useful to have document centric system where user prepares documents,
and only decides to which people to send it, without bothing how to
attach it, how to prepare e-mail, etc.

-- 
Jean

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

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