Bind mouse events

[mookid]

Fix #1278.

Probably a super dumb implementation: call ivy-next-line-and-call and then ivy-alt-done. I wonder if there is anything simpler; I guess that the tricky part here is to establish the bindings, then the implementation can evolve.

[basil-conto]

Missing backquote comma?

[mookid]

Indeed. It surprises me that it works without the comma...

[basil-conto]

Actually it should come as no surprise - the help-echo property can be evaluated as a function / form, in which case I suggest reverting to deferred evaluation (i.e. replace backquote with plain quote), since ivy-mouse-action-tooltip is a variable.

[basil-conto]

@mookid WDYT? (It just occurred to me that GitHub may not have notifed you of my replies on this and previous "outdated diffs". My apologies if you've already seen - I won't nag again.)

[basil-conto]

Why not propertize?

[mookid]

Indeed, looks better with it, but adds an unnecessary copy.

I guess that the mouse-face property can be added for both branches of the if, what do you think?

[basil-conto]

but adds an unnecessary copy

True, unless you pass the result of propertize to ivy--highlight-function:

(defun ivy--format-minibuffer-line (str)
  "Format line STR for use in minibuffer."
  (if (eq ivy-display-style 'fancy)
      (funcall ivy--highlight-function
               (propertize str
                           'mouse-face 'ivy-minibuffer-match-highlight
                           'help-echo  '(format "mouse-1: %s"
                                                ivy-mouse-action-tooltip)))
    (copy-sequence str)))

Though this relies on ivy--highlight-function to not overwrite any of the propertize properties, so I don't support it too strongly.

[basil-conto]

I guess that the mouse-face property can be added for both branches of the if

Indeed, I think mouse-face should be set for any clickable results, whereas ivy-display-style seems to be more specific to highlighting regexp matches.

[basil-conto]

Maybe it's just me, but I find it clearer to write

(defun ivy-mouse-done (event)
  "Exit the minibuffer with the selected candidate."
  (interactive "@e")
  (when event
    (ivy-next-line-and-call
     (- (max 0 (- (line-number-at-pos (posn-point (event-start event)))
                  2))
        ivy--window-index))
    (ivy-alt-done)))

Out of curiosity (as I am not familiar with the code or its purpose), why is up to 2 subtracted from the line number?

[mookid]

The purpose is to compute, given a click event in the minibuffer window, how many lines (offset) to adjust the selected candidate (to set it the the pointed-to candidate) before exiting.

As it is no so clear why the 2 is subtracted, I preferred to give meaningful names to the values.

line-number-at-point is the line number in the minibuffer window; line 1 is the prompt, line 2 the first candidate... as the click event designates a candidate, there is (max 2 ...) (a click on the prompt line is interpreted as selecting the first candidate).

line-number-candidate corresponds to the index of the selected candidate in the list of displayed candidates (which is indexed from 0).

We substract one because of the prompt, and one to convert to 0 based index.

[basil-conto]

Thanks, that makes sense. I'm not against naming intermediate results, I just find it clearer to subtract 2 and then ensure the result is a valid index, rather than doing (max 2 N) followed by a subtraction of 2.

[abo-abo]

Thanks, very cool. After a click I'm getting:

user-error: Minibuffer window is not active

Everything still works, but the error message is annoying. Reproducible with make plain.

[mookid]

Yes, I've seen that. I will investigate that later today or tomorrow.

A trickier event code to write is scrolling...

[mookid]

@abo-abo do you see anything more to be implemented/modified?

[mookid]

@abo-abo any hope that this lands on master?

[basil-conto]

@mookid Your thoughts on my comments above re: unconditionally adding mouse-face and leaving help-echo unevaluated?

[mookid]

I added a binding for mouse-3. But of course, one can't really end the session with the mouse, as the implementation becomes (read-char). is there any reason why this is not instead an ivy session?

Also note that the ivy--format-minibuffer-line machinery prevents correct propertization of multiline candidates.

@basil-conto :

unconditionally adding mouse-face is

This is `Apply mouse face even when non fancy.'.

leaving help-echo unevaluated

I miss the point.

[basil-conto]

offet -> offset
let* -> let
here and in ivy-mouse-dispatching-done.

[mookid]

Indeed, thanks!

[basil-conto]

Nitpick: can also be

(and event
     (let* ((...))
       ...
       offset)

if you like.

[basil-conto]

@mookid

unconditionally adding mouse-face is

This is `Apply mouse face even when non fancy.'.

leaving help-echo unevaluated

I miss the point.

Sorry, I hadn't seen your latest changes, which cover both counts. Apart from my latest nitpick review, LGTM.

[abo-abo]

@mookid Looks good to merge, except for ivy--window-index. That var is not clear to me: in some cases it tries to replace ivy--index, in others not. Can you explain why we need it? I tried replacing it with ivy--index and it doesn't quite work.

[mookid]

The key is in ivy--format. ivy--index is, as far as I understand/remember, the index of the selected candidate in the list.

ivy--window-index is the index of the highlighted candidate in the list of displayed candidates.

Previously, the two were not distinct, and the value of ivy--index was temporarily changed before calling ivy--format-minibuffer-line in ivy-format.

What do you think about replacing read-key with a recursive ivy session?

[abo-abo]

Thanks!