help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Lack of integration in Emacs - it was Re: How to rename files to numbers


From: Jean Louis
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
User-agent: Mutt/2.0.7+183 (3d24855) (2021-05-28)

* Emanuel Berg via Users list for the GNU Emacs text editor 
<help-gnu-emacs@gnu.org> [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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]