unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Milan Glacier <news@milanglacier.com>
Cc: Gottfried <gottfried@posteo.de>,
	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: Debunking Emacs merits over GUI - Re: package for Email
Date: Fri, 20 Jan 2023 12:07:33 +0300	[thread overview]
Message-ID: <Y8pZ1ZIdRONMNmCk@protected.localdomain> (raw)
In-Reply-To: <20230119161030.vt4muwcdvuwdqmj7@zoho.com>

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



  parent reply	other threads:[~2023-01-20  9:07 UTC|newest]

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

Reply instructions:

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

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

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

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

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

  git send-email \
    --in-reply-to=Y8pZ1ZIdRONMNmCk@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=gottfried@posteo.de \
    --cc=help-gnu-emacs@gnu.org \
    --cc=news@milanglacier.com \
    /path/to/YOUR_REPLY

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

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