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: Lack of integration in Emacs - it was Re: How to rename files to numbers in Eshell? Date: Sat, 2 Oct 2021 10:53:00 +0300 Message-ID: References: <87r1d6o9eb.fsf@inka.de> <875yuii4nk.fsf@inka.de> <87h7e2krgb.fsf@zoho.eu> <8735plk3m0.fsf@zoho.eu> <875yugh1ja.fsf@zoho.eu> 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="14233"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.7+183 (3d24855) (2021-05-28) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 02 09:55:22 2021 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 1mWZrd-0003Vv-Jy for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 09:55:21 +0200 Original-Received: from localhost ([::1]:57510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWZrc-0007JX-JS for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 03:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWZql-0007Hy-Mb for help-gnu-emacs@gnu.org; Sat, 02 Oct 2021 03:54:28 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:47569) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWZqi-0007Tb-Du for help-gnu-emacs@gnu.org; Sat, 02 Oct 2021 03:54:27 -0400 Original-Received: from localhost ([::ffff:154.230.227.14]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000037FDF.000000006158102C.00006453; Sat, 02 Oct 2021 00:54:20 -0700 Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <875yugh1ja.fsf@zoho.eu> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.help:133499 Archived-At: * Emanuel Berg via Users list for the GNU Emacs text editor [2021-10-02 00:36]: > Jean Louis wrote: > > > Just that for my needs speed does not matter much. > > What really matters is the integration opportunity that > > Emacs offers. We don't have our computing so prepared to be > > fully integrated, but we have got opportunities to make > > it so. > > I agree that's super important but I thought that was possible > with SLIME. Maybe it is theoretically, maybe it is in practice > as well only I didn't crack the code ... but no, never came > close to the Elisp interactive feel. SLIME, during time 2016-2017, was working well for me. I think that SLY now works about equally well. And I also use packages to see quickly the Common Lisp specification, in general, it is well integrated for my needs. One problem is if "connection breaks" as then I lose all values and need to evaluate it again. LibreOffice has many features integrated, for example LibreOffice Writer can write HTML documents and various other types of documents. I can choose background picture for HTML page and save it. Similarly, Emacs offers to write all kinds of documents, not as visual maybe, but one can do so much. It is integrated with `make' system, with Markdown, with all kinds of programming languages, compiling, building, LaTex conversions, all kinds of modes, Dired and remote Tramp connections, in general Emacs is integrated very well. >From users' viewpoint we can lean on mobile devices that integrate features well, and I can say that in Emacs we don't have those features. For example, some file managers like Amaze on Replicant/Android/LineageOS systems may accept shared information, like if I have a file, I can choose to open it in Amaze text editor. That is rather feature of operating system. Similarly we have /usr/share/applications/ where system can decide which application could or should open specific file. The operating system I have here Parabola GNU/Linux-libre has file managers but I don't get it all integrated, each file manager is different, I don't get always a feature that tells me like "Open with Emacs". Dired is great. Though there is no automatic integration with the system. Imagine directories in Dired, and you have 5 other different file managers. There is /usr/share/applications system, but Dired is not looking there automatically. It will not give me option to open with other file managers. It will not look into how else could I open the image. I have to configure it all myself. Though from user's viewpoint I have installed the image viewers. I have already made decision that I wish to use specific image viewers, and Dired does not know about it. Other file managers will not know nothing about Dired as well. Mobile devices have it integrated long time ago and Emacs is not following the pattern. I can think of Dired like following: - press Enter on the file and that shall open it in Emacs - use prefix key or different key, and Dired should ask me how to open the file with other application that is on the file system. It makes really no sense to press on *.odt file and that I get asked by Emacs if Emacs should open it or not. That is lack of integration. Emacs should know if it cannot properly open *.odt files and offer me to open it with LibreOffice. The keys "Enter" and `&' are not well integrated in Dired for my needs. I don't like having 2 keys to launch the file, I prefer having one single key that is smarter. If I am on JPG file, I prefer opening it in Emacs with RET key. But I maybe wish to edit JPG image or view it with external viewer. Then I would prefer having quick choice, and not just changing key or typing each time different program. That could be implemented with M-RET for example and to get choice from /usr/share/applications on how to open the file. Maybe I want to open it in ImageMagick editor, maybe with Gimp, maybe with `sxiv' image viewer. Majority of file managers have the option called "Open with" and gives me choice of applications. Within Emacs I have to configure it myself or make a new function myself. And it is common users' need. - Sharing files as I mentioned is almost non-existent. If there are chat programs on the system then Dired and other file managers should offer me possibility to share to those chat systems. To share it maybe to email, or FTP, SCP, Rsync servers, and so on. And I don't mean "configure and share", rather "click and share". The less actions user have to do, the better is the integration. Emacs integrates much of features together. Though it lacks important common features used today on multiple different file systems. > > We don't have file sharing well integrated in Emacs. > > For example there is no quick Dired function to email a file > > or set of files. > > Easy enough to fix - see source last - but I don't know why it > isn't there to begin with. either political reasons or no one > did it. If user has to see the source it means that integration is not there. From programmer's viewpoint I can understand, and we can argue how easy it is. From users' viewpoint, it is simply not a tool for that. We know it could be great tool for sharing files through multiple communication lines, but it is simply not. I have it integrated with `mutt' email client, but that cannot possibly be a solution for everybody. Email software shall know how to accept files -- which is also difficulty, they don't know. And Emacs and othe file managers shall know which software is installed to offer to user to share files to such installed email software. This way there would be just nothing to configure. Exactly this works like a charm on Replicant/Android devices. Though I don't know how software registers itself to be capable of accepting shared files. For example K9 email client once installed will automatically be offered to accept the shared file. On GNU/Linux email software does not know about each other. File managers don't know about email software. It is old fashioned, not integrated. How about the central contacts management? Emacs knows nothing about it. There are attempts to provide contacts management by various software, nothing is integrated well with the operating systems. LDAP servers on GNU/Linux far from user friendly. Look at Android and other mobile operating systems. Click on file and share it, share to chat systems, email, etc. Then once sharing starts, like email, start typing the contact's name and its email address is already appearing. Look at GNU/Linux email clients, each client maybe has its contact management, maybe not. Each email client has different address book. Look at Emacs email clients that are disparate to each other each using different methods and their own aliases or address books and require hell of configurations until it starts working. Well, at leat we have unlimited fun for decades talking about configurations, and all related to setups. But it does not efficiently help the productivity. Writing letters is related to people, but where is central people management? It does not exist. If it is there, then it is exclusively locked to Emacs like BBDB or like Hyperbole contact management, which lack integration that rarely somebody uses it. To share a file from Dired, my workflow is following: 1. Review then mark files for sharing; 2. Press key; or press prefix to add comment about the files shared; 3. Write query to find possible person to share to; 4. Select correct person if there are many; 5. Files are shared; process is finished; Otherwise, without personal integration, how would I share files from Emacs? 1. Open message mode or mail mode or other email client; 2. Find files, from within email client; I find this tedious as how do I review files before selecting it? I have only titles, but titles could be similar and confusing. Maybe I like to open files and review it before marking it, see number (1) in the previous example; 3. Attach files; 4. Now find the contact information of person to send file to; how? Maybe it is integrated to specific email client, maybe not, it is difficult. Here is incomplete insight in how I use few functions to send files by using Mutt email client from Emacs. Important is that it works. It cannot be general solution for users as each user uses different email client. (defun mutt-send-files (files to email &optional subject text) "Attach files to email and send it by mutt. It is understood that mutt hooks and settings will set the from address, signature, and other settings" (let* ((files (if (string= (type-of files) "string") (list files) files)) (files (seq-drop-while (lambda (a) (not (file-exists-p a))) files)) (length (length files)) (plural (if (> length 1) "s" "")) (number (capitalize (clisp-number-to-words length t))) (text-body (or text "")) (message (format "%s attached file%s by Mr. Louis" number plural)) (subject (if subject (concat subject " - " message) message)) (subject-plain subject) (subject (string-to-double-quotes subject)) (subject (escape-$ subject)) (body (concat temporary-file-directory "mutt-attachment-body.txt")) (body-file (string-to-single-quotes body)) (files (mapcar 'string-to-single-quotes files)) (files (string-join files " ")) ;; TODO (mutt-data (mutt-prepare-command email)) (mutt-command (car mutt-data)) (command (format "%s -s %s -a %s -- %s < %s" mutt-command subject files to body-file))) (with-temp-file body (insert subject-plain) (insert "\n\n") (unless (seq-empty-p text-body) (insert "Message: \n\n") (insert text-body)) (insert "\n\n") (insert user-full-name)) (message command) (async-shell-command command))) (defun mutt-dired-send-files-subject (&optional prefix-arg) (interactive "P") (let* ((subject (read-from-minibuffer "Subject: " nil nil nil '(*email-subject*))) (text (if current-prefix-arg (read-from-minibuffer "Message: ") ""))) (when (> (length subject) 0) (let* ((files (dired-get-marked-files)) (id (cf-people-search-id (rcd-ask cf-people-prompt)))) (when id (let* ((name (cf-full-contact-name id)) (name (s-collapse-whitespace name)) (email (completing-read "Choose email: " (cf-valid-emails id)))) (when email (let* ((to (format "\"%s <%s>\"" name email)) (ask (format "Do you want to send files to %s? " to))) (when (yes-or-no-p ask) (mutt-send-files files to email subject text)))))))))) (defun mutt-dired-send-files () (interactive) (let* ((files (dired-get-marked-files)) (id (cf-people-search-id (rcd-ask cf-people-prompt)))) (when id (let* ((name (cf-full-contact-name id)) (email (completing-read "Choose email: " (cf-valid-emails id)))) (when email (let* ((to (format "\"%s <%s>\"" name email)) (ask (format "Do you want to send files for %s? " to))) (when (yes-or-no-p ask) (mutt-send-files files to email)))))))) My personal Emacs integration thus allows me to do this workflow: 1. Review files, then mark files for sharing; 2. Press key; or press prefix to add comment about the files shared; 3. Write query to find possible person to share to; 4. Select correct person as recipient if there are many; 5. Files are shared; process is finished; For each recipient there is different identity, depending of their group, that is solved in background. I don't need to choose the identity or my email address, I just decide which files are to be shared and if I need to add a comment about them. On Android/Replicant/LineageOS those features are integrated in the system and in software packages. > > Back to Common Lisp. It is even less integrated for basic > > needs. In Emacs I can mark files and share them to other > > device or use functions to share them by email or publish > > files on remote devices. In Common Lisp I have to program > > everything myself, too much of it. Marking of files I would > > need to program myself. Taking care of even lower > > level functions. > > It is like that, is it? Or did you overlook some key packages > in that field perhaps? I don't think so necessarily but it is > possible ... Number of packages does not tell about integration. Packages are disparate and often repetitive, not integrated with each other. Emacs has the GUI, Common Lisp does not have. I think Common Lisp should have it, in general every programming language TODAY, should offer GUI integrated. Not let users search for it. Example of good integration in Lisp is Lush: http://lush.sourceforge.net/screenshots.html or PicoLisp: https://picolisp.com/wiki/?home with integrated database, XHTML/CSS GUI Framework, and they are far from ideal integrated programming language. Racket seem to be better integrated. Plethora of Common Lisp is just command line based, anything else requires packages. What users of today need is something like Scratch: https://scratch.mit.edu - visual programming, integrated, easy to start. > > Everything can be done with Common Lisp and Scheme, but it > > is more work with Common Lisp as compared to Emacs once user > > understands how much of it is already close to fingertips. > > How much Elisp is there around compared to all CL and all > Scheme and all other Lisp diagrams? Pie chart! It really does not matter. Compare it to Scratch, if you need days, weeks or months to do what Scratch can do in 1 hour, then quantity really does not matter. It is not helpful. Users need well prepared systems. > >> To translate either Perl or Python to Elisp to I would > >> _never_ do ... > > > > I have done that from Perl to Common Lisp, from Perl to > > Emacs Lisp. > > Yeah, this whole translating stuff is foreign to me ... even > if I did it I would call it a re-implementation or second > attempt rather than a "translation" Good place to start with specific examples is: http://www.rosettacode.org/wiki/Rosetta_Code Doing it in different programming languages is pleasure as that increases one's own understanding of the workflow and leads to discovery of better methods. > ;;; -*- lexical-binding: t -*- > ;;; > ;;; this file: > ;;; http://user.it.uu.se/~embe8573/emacs-init/gnus/mail-to-many.el > ;;; https://dataswamp.org/~incal/emacs-init/gnus/mail-to-many.el > > (require 'gnus-msg) > (require 'message) Right. Gnus. We are all disparate. Integration nowhere. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/