From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Debunking Emacs merits over GUI - Re: package for Email Date: Thu, 19 Jan 2023 08:06:46 +0300 Message-ID: References: <20230118180348.gzwvy6iztok45ko3@zoho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27527"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: Gottfried , "help-gnu-emacs@gnu.org" To: Milan Glacier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 19 06:30:44 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pINVa-0006w7-2C for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 19 Jan 2023 06:30:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pINV5-0005G2-4F; Thu, 19 Jan 2023 00:30:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pINV0-0005FW-3h for help-gnu-emacs@gnu.org; Thu, 19 Jan 2023 00:30:08 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pINUx-0003A4-SX for help-gnu-emacs@gnu.org; Thu, 19 Jan 2023 00:30:05 -0500 Original-Received: from localhost ([::ffff:197.239.7.243]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103A08.0000000063C8D55D.0000778C; Wed, 18 Jan 2023 22:30:04 -0700 Mail-Followup-To: Milan Glacier , Gottfried , "help-gnu-emacs@gnu.org" Content-Disposition: inline In-Reply-To: <20230118180348.gzwvy6iztok45ko3@zoho.com> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142381 Archived-At: * Milan Glacier [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/