[PATCH] Make eshell ‘ls’ output clickable.

[PATCH] Make eshell ‘ls’ output clickable.

[Matthew Bauer]

When the option ‘eshell-ls-make-clickable’ is set to t, the output of
list can be clicked with <mouse-1>. This provides a more dired-like
experience for Eshell. ‘eshell-ls-make-clickable’ defaults to nil.

It's debatable whether this is should be included in Eshell because it can fairlhy easily be provided with advising (see link below). My opinion, though, is that it's a fairly useful feature with fairly little cost and gives Eshell a more Dired-like feel.

This is based on the work of Edward O’Connor and Patrick Anderson from
the EmacsWiki (https://www.emacswiki.org/emacs/EshellEnhancedLS). The
original code was made for advising eshell-ls-decorated-name while
this patch just modifies it directly.

NOTE: this probably requires permission from both Edward and Patrick to get includes. I'm not sure what the process is for that but I've CC'd them in this email. This is my first patch submission to Emacs so hopefully I've done everything appropriately.

* lisp/eshell/em-ls.el: add functions ‘eshell-ls-find-file-at-point’,
  and ‘eshell-ls-find-file-at-mouse-click’; add customizable boolean
  setting ‘eshell-ls-make-clickable’; add keymap ‘eshell-ls-keymap’
  for decorated names
---
 lisp/eshell/em-ls.el | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/lisp/eshell/em-ls.el b/lisp/eshell/em-ls.el
index 79799db30b..93f14b4fb3 100644
--- a/lisp/eshell/em-ls.el
+++ b/lisp/eshell/em-ls.el
@@ -96,6 +96,10 @@ faster and conserves more memory."
   "If non-nil, use colors in file listings."
   :type 'boolean)
 
+(defcustom eshell-ls-make-clickable nil
+  "If non-nil, make ls output clickable."
+  :type 'boolean)
+
 (defface eshell-ls-directory
   '((((class color) (background light)) (:foreground "Blue" :weight bold))
     (((class color) (background dark)) (:foreground "SkyBlue" :weight bold))
@@ -787,6 +791,26 @@ to use, and each member of which is the width of that column
 
     (cons (or col-widths (vector max-width)) files)))
 
+(defun eshell-ls-find-file-at-point (point)
+  "RET on Eshell's `ls' output to open files.
+POINT is the point that the file is available at."
+  (interactive "d")
+  (find-file (buffer-substring-no-properties
+              (previous-single-property-change point 'help-echo)
+              (next-single-property-change point 'help-echo))))
+
+(defun eshell-ls-find-file-at-mouse-click (event)
+  "Middle click on Eshell's `ls' output to open files.
+EVENT refers to the mouse event that triggers the click."
+  (interactive "e")
+  (eshell-ls-find-file-at-point (posn-point (event-end event))))
+
+(defvar eshell-ls-keymap
+  (let ((map (make-sparse-keymap)))
+    (define-key map (kbd "<return>") 'eshell-ls-find-file-at-point)
+    (define-key map (kbd "<mouse-1>") 'eshell-ls-find-file-at-mouse-click)
+    map))
+
 (defun eshell-ls-find-column-lengths (files)
   "Find the best fitting column lengths for FILES.
 It will be returned as a vector, whose length is the number of columns
@@ -907,6 +931,12 @@ to use, and each member of which is the width of that column
 	    (add-text-properties 0 (length (car file))
 				 (list 'font-lock-face face)
 				 (car file)))))
+  (when eshell-ls-make-clickable
+    (add-text-properties 0 (length (car file))
+                         (list 'help-echo "RET, mouse-1: visit this file"
+                               'mouse-face 'highlight
+                               'keymap eshell-ls-keymap)
+                         (car file)))
   (car file))
 
 (provide 'em-ls)
-- 
2.13.2

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Nicolas Petton]

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

Matthew Bauer <mjbauer95@gmail.com> writes:

Hi Matthew,

Thanks for the patch!

> It's debatable whether this is should be included in Eshell because it
> can fairlhy easily be provided with advising (see link below). My
> opinion, though, is that it's a fairly useful feature with fairly
> little cost and gives Eshell a more Dired-like feel.

I like the feature, I've been using something similar for a long time.
I would even enable it by default, as I don't see any downside of doing
so.

I've commented the patch below:

> +(defun eshell-ls-find-file-at-point (point)

The function name suggests that this function finds a file based on the
current position of the point, so I would remove the POINT argument,
change `(interactive "d")' to `(interactive)', and use the `point'
function.

> +  "RET on Eshell's `ls' output to open files.
> +POINT is the point that the file is available at."

The function does not bind `RET', as the docstring suggests.

Cheers,
Nico

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

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Ted Zlatanov]

On Fri, 07 Jul 2017 17:08:47 +0200 Nicolas Petton <nicolas@petton.fr> wrote: 

NP> I like the feature, I've been using something similar for a long time.
NP> I would even enable it by default, as I don't see any downside of doing
NP> so.

Does it make it harder to use the mouse to copy file names? Are spaces
and other non-alphanumeric characters handled correctly?

What if there are URLs in the shell output? Should those be browsable?

What about dates? Can we make calendar entries automatically from
those?[1]

I feel this indicates a wider need, not specific to eshell, to dig out
"things" from text and act on them, guessing their proper handler. In
this case, because the "things" come from the `ls` output, maybe we can
tag them with a text property that can then hint that these are file
names. So to me this feels like a context-sensitive minor mode or even
an Emacs-wide text handler facility, useful beyond eshell. Maybe it
already exists?

Ted

[1] This is not an extreme suggestion; Apple and Google products do this.

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Yuri Khan]

On Fri, Jul 7, 2017 at 11:10 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> I feel this indicates a wider need, not specific to eshell, to dig out
> "things" from text and act on them, guessing their proper handler.
> Maybe it already exists?

‘find-file-at-point’ comes to mind. Maybe it could be extended, or
made one of backends, to ‘dwim-at-point’.

RE: [PATCH] Make eshell ‘ls’ output clickable.

[Drew Adams]

> > I feel this indicates a wider need, not specific to eshell, to dig out
> > "things" from text and act on them, guessing their proper handler.
> > Maybe it already exists?
> 
> ‘find-file-at-point’ comes to mind. Maybe it could be extended, or
> made one of backends, to ‘dwim-at-point’.

1. The general way to handle grabbing something at point is
to use `thingatpt.el'.  For file names and URLS, however,
`ffap.el' (specifically `ffap-guesser') works better, IMO.

The thing-at-point approach requires only that you define,
for any given type of <THING>, a `forward-<THING>' function
or both a `beginning-<THING>' and `end-<THING>' function.

Emacs comes with several such functions predefined, e.g.,
`forward-sexp'.


2. Your suggestion of `dwim-at-point' would mean doing the
right thing either (1) in general (a compromise, picked
to fit many common contexts) or (2) in a context-dependent
way.


3. FWIW, I've suggested before that Emacs do what Icicles
does: Let you use a key from the minibuffer (Icicles uses
`M-.') to grab something from some text at or near point
and append it to the minibuffer input.

(This is available whether or not completion is available
for the minibuffer input - it has nothing to do with
completion.)

Icicles `M-.' (`icicle-insert-string-at-point') is a
bit fancy (but Emacs need not do likewise):

For repetitions of `M-.', you have a choice: either
(1) successive things of the same type are inserted
from the buffer (more of the same) or (2) a different
type of thing from the buffer replaces the thing just
inserted (alternative things).

You choose via option `icicle-default-thing-insertion'.
(When you use `M-.', a plain prefix arg (`C-u') flips
the behavior of the option.)

Option `icicle-thing-at-point-functions' is where you
specify (a) the function used for #1, above, i.e.,
what type of thing to grab and (b) a list of alternative
thing-grabbing functions, for #2, above.

The behavior of a _numeric_ prefix arg N with `M-.'
depends on the default-insertion behavior you choose.
If it is #1, above, then N things of the given type are
inserted.  If it is #2, above, then the text at point is
grabbed as a Lisp sexp, evaluated, and the return value
is inserted.

[If you also use library `thingatpt+.el' then #2 with
a numeric prefix arg is handy if you are editing Lisp
code, since by default the grabbing alternatives
include 3 functions that retrieve different levels of
list near point.]

https://www.emacswiki.org/emacs/Icicles_-_Inserting_Text_from_Cursor

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Ted Zlatanov]

On Fri, 7 Jul 2017 23:30:23 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote: 

YK> On Fri, Jul 7, 2017 at 11:10 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> I feel this indicates a wider need, not specific to eshell, to dig out
>> "things" from text and act on them, guessing their proper handler.
>> Maybe it already exists?

YK> ‘find-file-at-point’ comes to mind. Maybe it could be extended, or
YK> made one of backends, to ‘dwim-at-point’.

That would be cool. I think Drew's post was along those lines too, but
crucially I'm suggesting that the *source* of the text (in this case,
eshell) should tag the text region with some property like "this came
from ls so it's probably file names, permissions, dates..."

That doesn't exist, does it? If I were to implement a first rough cut,
what should the property look like? Maybe a list of symbols?

There was a recent question on Reddit[1] about tagging lines as you
browse text and then deleting them all later. This could be another use
for this kind of ad-hoc text property, but in this case the property
would be created by the user instead of by the originator of the text.

Ted

[1] https://www.reddit.com/r/emacs/comments/6jfctn/mark_lines_in_buffer_for_mass_delete/

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Nicolas Petton]

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

Matthew Bauer <mjbauer95@gmail.com> writes:

> NOTE: this probably requires permission from both Edward and Patrick
> to get includes. I'm not sure what the process is for that but I've
> CC'd them in this email. This is my first patch submission to Emacs so
> hopefully I've done everything appropriately.

If this is your first contribution, I guess it exhausts the amount of
changes that can be accepted without signing the FSF form (~10 LOC
IIRC).  I've added Eli in the Cc, who knows more about this.

If you haven't done it already, I'd encourage you to start the paperwork
process, so that future contributions can be accepted.

Cheers,
Nico

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

Re: [PATCH] Make eshell ‘ls’ output clickable.

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: eliz@gnu.org
> Date: Fri, 07 Jul 2017 17:15:10 +0200
> 
> Matthew Bauer <mjbauer95@gmail.com> writes:
> 
> > NOTE: this probably requires permission from both Edward and Patrick
> > to get includes. I'm not sure what the process is for that but I've
> > CC'd them in this email. This is my first patch submission to Emacs so
> > hopefully I've done everything appropriately.
> 
> If this is your first contribution, I guess it exhausts the amount of
> changes that can be accepted without signing the FSF form (~10 LOC
> IIRC).  I've added Eli in the Cc, who knows more about this.

T^he code as submitted looks like more-or-less copy of what's on the
wiki, with some renaming.  So yes, I think the original authors need
to give their blessing.