mouse-drag-and-drop-region

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

mouse-drag-and-drop-region

martin rudalics
Sorry for reacting late to the addition of ‘mouse-drag-and-drop-region’
but it never worked with multiple windows here so I had to find the
source of that problem first.  It turned out that having
‘mouse-autoselect-window’ non-nil interferes, because whenever the mouse
enters another window, a 'select-window' event will be generated which
the code should ignore.  I now installed the necessary change.

The code should ignore ‘switch-frame’ events too.  But this won't
accomplish much at the moment because to drag text from one frame to
another we need additional provisions.  In principle, Emacs should
always avoid switching frames during and after mouse tracking but I'm
not yet sure how to do that consistently.

Anyway, here are some comments:

(1) Why does the value selection happen within the ‘track-mouse’ form
     and why do you delete the mouse overlay?  That is, why don't we move
     this part

         (unless value-selection ; initialization
           (delete-overlay mouse-secondary-overlay)
           (setq value-selection (buffer-substring start end))
           (move-overlay mouse-secondary-overlay start end)) ; (deactivate-mark)

     right to the beginning so we have something like

   (let* ((start (region-beginning))
          (end (region-end))
          (point (point))
          (buffer (current-buffer))
          (window (selected-window))
          (value-selection (buffer-substring start end)))
     (move-overlay mouse-secondary-overlay start end)
     (track-mouse
       ...

     there?

(2) Activating the secondary overlay can be distracting and should be
     made optional (facultatively keeping the primary overlay in place
     provided (4) below is done).

(3) Showing tooltips can be distracting and should be optional.  Note
     also, that usurping tooltips this way may prevent them from showing
     interesting properties of the drop area like whether the text there
     is read only.  OTOH we might consider retaining properties of the
     text in (non-GTK) tooltips.

(4) The (deactivate-mark) and (mouse-set-point event) trick to allow
     showing point the way ‘mouse-drag-track’ does can be distracting and
     should be made optional.

(5) The mouse pointer shape should take care of indicating the exact
     position where the drop occurs.  We should probably also signal
     whenever the current drop position is invalid.  This is IIUC usual
     practice on most window systems now.

(6) Dropping should allow to copy text into the region itself.  There's
     no reason forbidding that.

(7) IMO either cutting should be the default too when the drop occurs in
     a different buffer or copying would be the default and pressing the
     modifier should produce a cut instead.  The current behavior wants
     me to always keep in mind whether the target buffer is the same as
     the source buffer.  At least, this behavior should be made optional.

(8) Read-only text should be handled.  An attempt to drop text into a
     read-only area should be signalled to the user.  An attempt to cut
     text from a read-only text/buffer should be signalled as well.

(9) The code must become resilient against any failures by wrapping it
     into a ‘condition-case’ and doing the necessary clean up operations
     (restoring region and point, deleting the secondary overlay).

I think (8) and (9) should be fixed before the release.  As for future
releases we might also consider a ‘set-transient-map’ based solution.

Sincerely, martin


Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
> Date: Tue, 14 Nov 2017 10:54:09 +0100
> From: martin rudalics <[hidden email]>
>
> (8) Read-only text should be handled.  An attempt to drop text into a
>      read-only area should be signalled to the user.  An attempt to cut
>      text from a read-only text/buffer should be signalled as well.

For the latter, we copy text instead (cf C-w in read-only text).  So I
think this feature should behave similarly, at least by default.

Thanks for the review.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
 >> (8) Read-only text should be handled.  An attempt to drop text into a
 >>       read-only area should be signalled to the user.  An attempt to cut
 >>       text from a read-only text/buffer should be signalled as well.
 >
 > For the latter, we copy text instead (cf C-w in read-only text).  So I
 > think this feature should behave similarly, at least by default.

I just noticed that the code does use ‘kill-region’ already.  This has
the side-effect of putting the text into the kill ring, something which
should be documented at least.  But I think the code should rather use
‘delete-region’ instead with the behavior you proposed.

martin


Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Alex-2
In reply to this post by martin rudalics
martin rudalics <[hidden email]> writes:


> Anyway, here are some comments:
>
> (1) Why does the value selection happen within the ‘track-mouse’ form
>     and why do you delete the mouse overlay?  That is, why don't we move
>     this part
>
>         (unless value-selection ; initialization
>           (delete-overlay mouse-secondary-overlay)
>           (setq value-selection (buffer-substring start end))
>           (move-overlay mouse-secondary-overlay start end)) ; (deactivate-mark)
>
>     right to the beginning so we have something like
>
>   (let* ((start (region-beginning))
>          (end (region-end))
>          (point (point))
>          (buffer (current-buffer))
>          (window (selected-window))
>          (value-selection (buffer-substring start end)))
>     (move-overlay mouse-secondary-overlay start end)
>     (track-mouse
>       ...
>
>     there?

I imagine that this has to do with inputting a non-mouse-movement event
before moving the mouse at all. If you use your change and press "C-g"
before moving the mouse, then the region will still be pasted.

Doing the above without your change currently results in an error due to
`insert' using a nil `value-selection', though.  So it's faulty either
way.

> (3) Showing tooltips can be distracting and should be optional.  Note
>     also, that usurping tooltips this way may prevent them from showing
>     interesting properties of the drop area like whether the text there
>     is read only.  OTOH we might consider retaining properties of the
>     text in (non-GTK) tooltips.

Also, trying to use `tooltip-show' in text-terminals using
`xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
messages.

> I think (8) and (9) should be fixed before the release.  As for future
> releases we might also consider a ‘set-transient-map’ based solution.

Perhaps (3) should be fixed before release as well (at least disabling
tooltips when they can't be shown)?

Eli, would it be okay to make the same `read-event' -> `read-key' change
(specific to xt-mouse as in Bug#29150) here as well to tide over until
the function uses `set-transient-map'?  This appears to be the last
`read-event' present in mouse.el to get rid of.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
 > I imagine that this has to do with inputting a non-mouse-movement event
 > before moving the mouse at all. If you use your change and press "C-g"
 > before moving the mouse, then the region will still be pasted.
 >
 > Doing the above without your change currently results in an error due to
 > `insert' using a nil `value-selection', though.  So it's faulty either
 > way.

I'm missing you.  Doesn't C-g deactivate the mark?

 >> (3) Showing tooltips can be distracting and should be optional.  Note
 >>      also, that usurping tooltips this way may prevent them from showing
 >>      interesting properties of the drop area like whether the text there
 >>      is read only.  OTOH we might consider retaining properties of the
 >>      text in (non-GTK) tooltips.
 >
 > Also, trying to use `tooltip-show' in text-terminals using
 > `xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
 > messages.

That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
area.

 > Perhaps (3) should be fixed before release as well (at least disabling
 > tooltips when they can't be shown)?

Sure.

martin


Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
> Date: Wed, 15 Nov 2017 10:22:45 +0100
> From: martin rudalics <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>, [hidden email],
> emacs-devel <[hidden email]>
>
>  > Also, trying to use `tooltip-show' in text-terminals using
>  > `xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
>  > messages.
>
> That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
> area.

It does, if you invoke it with 2nd argument non-nil.

It's not a bug, it's the intended behavior.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
 >> That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
 >> area.
 >
 > It does, if you invoke it with 2nd argument non-nil.
 >
 > It's not a bug, it's the intended behavior.

It's a bug in 'mouse-drag-and-drop-region' obviously.

martin


Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Alex-2
In reply to this post by martin rudalics
martin rudalics <[hidden email]> writes:

>> I imagine that this has to do with inputting a non-mouse-movement event
>> before moving the mouse at all. If you use your change and press "C-g"
>> before moving the mouse, then the region will still be pasted.
>>
>> Doing the above without your change currently results in an error due to
>> `insert' using a nil `value-selection', though.  So it's faulty either
>> way.
>
> I'm missing you.  Doesn't C-g deactivate the mark?

Usually, but I don't think it does in this case.  To be clear, it's not
just C-g that does this.  Here's a recipe:

1. Select a region.
2. Hold down-mouse-1 inside of this region.
3. Press any key before moving or releasing the mouse.

Doing this yields an error without your change, and it pastes the region
with your change.  Even when this key is C-g, `mark-active' is t after
step 3.

>>> (3) Showing tooltips can be distracting and should be optional.  Note
>>>      also, that usurping tooltips this way may prevent them from showing
>>>      interesting properties of the drop area like whether the text there
>>>      is read only.  OTOH we might consider retaining properties of the
>>>      text in (non-GTK) tooltips.
>>
>> Also, trying to use `tooltip-show' in text-terminals using
>> `xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
>> messages.
>
> That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
> area.
>
>> Perhaps (3) should be fixed before release as well (at least disabling
>> tooltips when they can't be shown)?
>
> Sure.

I suppose (display-graphic-p) should be supplied as the 2nd argument to
`tooltip-show', then?

I also noticed that when dragging in an X window, the tooltip flickers
quite a bit. Is there any easy remedy for this?  Removing the
`mouse-set-point' call in `track-mouse' helps in some cases, but not
completely.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Wed, 15 Nov 2017 19:50:26 +0100
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email], [hidden email]
>
>  >> That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
>  >> area.
>  >
>  > It does, if you invoke it with 2nd argument non-nil.
>  >
>  > It's not a bug, it's the intended behavior.
>
> It's a bug in 'mouse-drag-and-drop-region' obviously.

Right.  (I think it shouldn't show a tip on TTY frames, not in the
echo area, not anywhere.)

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
In reply to this post by Alex-2
> From: Alex <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>,  [hidden email],  emacs-devel <[hidden email]>
> Date: Wed, 15 Nov 2017 13:46:42 -0600
>
> I suppose (display-graphic-p) should be supplied as the 2nd argument to
> `tooltip-show', then?

display-multi-frame-p is more appropriate.  But I think the tooltip
should not be shown at all on TTY frames, it looks unnecessary and
even silly to show the dragged text in the echo area.

> I also noticed that when dragging in an X window, the tooltip flickers
> quite a bit. Is there any easy remedy for this?

We constantly redisplay the tooltip frame, don't we?  Or does this
happen only with GTK tooltips?

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
In reply to this post by Alex-2
> From: Alex <[hidden email]>
> Cc: emacs-devel <[hidden email]>,  [hidden email], Eli Zaretskii <[hidden email]>
> Date: Tue, 14 Nov 2017 14:17:25 -0600
>
> Eli, would it be okay to make the same `read-event' -> `read-key' change
> (specific to xt-mouse as in Bug#29150) here as well to tide over until
> the function uses `set-transient-map'?

This is a new feature, so we can do that unconditionally.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Alex-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: Alex <[hidden email]>
>> Cc: Eli Zaretskii <[hidden email]>,  [hidden email],  emacs-devel <[hidden email]>
>> Date: Wed, 15 Nov 2017 13:46:42 -0600
>>
>> I suppose (display-graphic-p) should be supplied as the 2nd argument to
>> `tooltip-show', then?
>
> display-multi-frame-p is more appropriate.

That appears to be an alias to `display-graphic-p'.

> But I think the tooltip should not be shown at all on TTY frames, it
> looks unnecessary and even silly to show the dragged text in the echo
> area.

That sounds better.  Though I wonder if tooltips could be shown in TTY
frames using a method similar to how `x-popup-menu' displays a menu in
them?

>> I also noticed that when dragging in an X window, the tooltip flickers
>> quite a bit. Is there any easy remedy for this?
>
> We constantly redisplay the tooltip frame, don't we?  Or does this
> happen only with GTK tooltips?

I don't know the details, but it appears that there are some redisplay
cycles that don't show the tooltip, leading to flickering.

I've only tested this with GTK tooltips so far.

There's also a side issue that subsequent mouse-movement events appear
to only be generated after moving a character rather than by a
configurable amount of pixels, which leads to the tooltip movement being
a bit jerky.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Tak Kunihiro-2
In reply to this post by martin rudalics
> (1) Why does the value selection happen within the ‘track-mouse’
>     form and why do you delete the mouse overlay?  That is, why
>     don't we move this part
>
>         (unless value-selection ; initialization
>           (delete-overlay mouse-secondary-overlay)
>           (setq value-selection (buffer-substring
>           start end))
>           (move-overlay mouse-secondary-overlay
>           start end)) ; (deactivate-mark)
>
>     right to the beginning so we have something like
>
>   (let* ((start (region-beginning))
>          (end (region-end))
>          (point (point))
>          (buffer (current-buffer))
>          (window (selected-window))
>          (value-selection (buffer-substring start
>          end)))
>     (move-overlay mouse-secondary-overlay start
>     end)
>     (track-mouse
>       ...
>
>     there?

There could be two operations that are `click' and `drag'.  Later on
line 40, value-selection is also used to identify whether operation is
`drag'.  Probably code should be improved.

39:  ;; "drag negligible" or "drag to read-only", restore region.
40:  (value-selection
41:   (select-window window) ; In case miss drag to other window
42:   (goto-char point)

> (2) Activating the secondary overlay can be distracting and should
>     be made optional (facultatively keeping the primary overlay in
>     place provided (4) below is done).

Region on the other window is not visible.  Thus original region
should be hi-lighted somehow.  Since mouse-drag-and-drop-region is
located on mouse.el, mouse-secondary-overlay was used.

Do you suggest to have option such like
 (defvar mouse-drag-and-drop-region-overlay 'mouse-secondary-overlay)
?

> (3) Showing tooltips can be distracting and should be optional.
>     Note also, that usurping tooltips this way may prevent them from
>     showing interesting properties of the drop area like whether the
>     text there is read only.  OTOH we might consider retaining
>     properties of the text in (non-GTK) tooltips.

Do you suggest to have option like
 (defvar mouse-drag-and-drop-region-preview t)
or implement other way to show the text besides using tooltips?

> (4) The (deactivate-mark) and (mouse-set-point event) trick to allow
>     showing point the way ‘mouse-drag-track’ does can be distracting
>     and should be made optional.

I think that this is very related to 2, 3, and 5 (as you inferred).

> (5) The mouse pointer shape should take care of indicating the exact
>     position where the drop occurs.  We should probably also signal
>     whenever the current drop position is invalid.  This is IIUC
>     usual practice on most window systems now.

I think it is a good idea.

> (6) Dropping should allow to copy text into the region itself.
>     There's no reason forbidding that.

I suppose that you mean when drop onto region itself with key pressed.
I agree.

> (7) IMO either cutting should be the default too when the drop
>     occurs in a different buffer or copying would be the default and
>     pressing the modifier should produce a cut instead.  The current
>     behavior wants me to always keep in mind whether the target
>     buffer is the same as the source buffer.  At least, this
>     behavior should be made optional.

Default behavior followed that of file browser on `drag' a file.
Between the same volume (buffer), `drag' does `cut' instead of `copy'.
I prefer current behavior as default but have
no objection to have option something like
 (defvar mouse-drag-and-drop-region-cut-hungry t)
.

> (8) Read-only text should be handled.  An attempt to drop text into
>     a read-only area should be signalled to the user.  An attempt to
>     cut text from a read-only text/buffer should be signalled as
>     well.

> For the latter, we copy text instead (cf C-w in read-only text).  So
> I think this feature should behave similarly, at least by default.

> I just noticed that the code does use ‘kill-region’ already.  This
> has the side-effect of putting the text into the kill ring,
> something which should be documented at least.  But I think the code
> should rather use ‘delete-region’ instead with the behavior you
> proposed.

I suppose that you suggest to tell user more explicitly in echo area
how he cannot change the text.  I am not against the suggestion.

On an user perspective, operation `drag-and-drop-region' is a
combination of `cut' and `paste'.  Thus text was killed instead of
deleted.  How you think delete is more preferred?  I have no objection
to document it.

> (9) The code must become resilient against any failures by wrapping
>     it into a ‘condition-case’ and doing the necessary clean up
>     operations (restoring region and point, deleting the secondary
>     overlay).
>
> I think (8) and (9) should be fixed before the release.  As for
> future releases we might also consider a ‘set-transient-map’ based
> solution.

No objection.  There is other thread about mouse-drag-and-drop-region.

https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00588.html
Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
In reply to this post by Alex-2
 > 1. Select a region.
 > 2. Hold down-mouse-1 inside of this region.
 > 3. Press any key before moving or releasing the mouse.
 >
 > Doing this yields an error without your change,

Something like

mouse-drag-region: Wrong type argument: char-or-string-p, nil

I suppose.  'value-selection' must have been nil then.

 > and it pastes the region
 > with your change.  Even when this key is C-g, `mark-active' is t after
 > step 3.

Not much better.  But doing mouse-down and pressing another key at the
same time is somewhat obscure behavior.

 > I suppose (display-graphic-p) should be supplied as the 2nd argument to
 > `tooltip-show', then?

For example, yes.

 > I also noticed that when dragging in an X window, the tooltip flickers
 > quite a bit. Is there any easy remedy for this?  Removing the
 > `mouse-set-point' call in `track-mouse' helps in some cases, but not
 > completely.

Would customizing 'tooltip-reuse-hidden-frame' change anything or are
you using GTK tooltips?

martin

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
In reply to this post by Eli Zaretskii
 > Right.  (I think it shouldn't show a tip on TTY frames, not in the
 > echo area, not anywhere.)

Agreed.

martin

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

martin rudalics
In reply to this post by Tak Kunihiro-2
 > There could be two operations that are `click' and `drag'.  Later on
 > line 40, value-selection is also used to identify whether operation is
 > `drag'.  Probably code should be improved.

Did you ever consider using the "r" interactive switch instead of the
"e" one?

 >> (2) Activating the secondary overlay can be distracting and should
 >>      be made optional (facultatively keeping the primary overlay in
 >>      place provided (4) below is done).
 >
 > Region on the other window is not visible.  Thus original region
 > should be hi-lighted somehow.  Since mouse-drag-and-drop-region is
 > located on mouse.el, mouse-secondary-overlay was used.

You mean that you highlight the original region with the secondary
overlay so that the overlay shows up on the target window as well and
the user is informed that dropping there might lead to say "dubious"
results?

 > Do you suggest to have option such like
 >   (defvar mouse-drag-and-drop-region-overlay 'mouse-secondary-overlay)
 > ?

I mean something like

(defcustom mouse-drag-and-drop-region-show-secondary-overlay t ...)

where setting this to nil means to just not show any overlay.  And your
code would have to accept that there is no secondary overlay at the time
of the drop.

 >> (3) Showing tooltips can be distracting and should be optional.
 >>      Note also, that usurping tooltips this way may prevent them from
 >>      showing interesting properties of the drop area like whether the
 >>      text there is read only.  OTOH we might consider retaining
 >>      properties of the text in (non-GTK) tooltips.
 >
 > Do you suggest to have option like
 >   (defvar mouse-drag-and-drop-region-preview t)
 > or implement other way to show the text besides using tooltips?

I would say

(defcustom mouse-drag-and-drop-region-show-tooltip t)

and never show a tooltip on text-only terminals even if this is t.

 >> (4) The (deactivate-mark) and (mouse-set-point event) trick to allow
 >>      showing point the way ‘mouse-drag-track’ does can be distracting
 >>      and should be made optional.
 >
 > I think that this is very related to 2, 3, and 5 (as you inferred).

Yes.  It's irritating to drag a block cursor with the mouse.  Do you
know of any other applications which do such a thing?

 >> (5) The mouse pointer shape should take care of indicating the exact
 >>      position where the drop occurs.  We should probably also signal
 >>      whenever the current drop position is invalid.  This is IIUC
 >>      usual practice on most window systems now.
 >
 > I think it is a good idea.

We probably need to define additional cursors for this so it's not for
Emacs 26.

 >> (7) IMO either cutting should be the default too when the drop
 >>      occurs in a different buffer or copying would be the default and
 >>      pressing the modifier should produce a cut instead.  The current
 >>      behavior wants me to always keep in mind whether the target
 >>      buffer is the same as the source buffer.  At least, this
 >>      behavior should be made optional.
 >
 > Default behavior followed that of file browser on `drag' a file.

Which file browser?

 > Between the same volume (buffer), `drag' does `cut' instead of `copy'.
 > I prefer current behavior as default but have
 > no objection to have option something like
 >   (defvar mouse-drag-and-drop-region-cut-hungry t)

I would be more radical with

(defcustom mouse-drag-and-drop-region-cut-or-copy t)

where the values 'cut and 'copy would always categorically cut or copy
(unless the value of 'mouse-drag-and-drop-region' implies to copy
instead of cut) and t means your original behavior.

 >> (8) Read-only text should be handled.  An attempt to drop text into
 >>      a read-only area should be signalled to the user.  An attempt to
 >>      cut text from a read-only text/buffer should be signalled as
 >>      well.
 >
 >> For the latter, we copy text instead (cf C-w in read-only text).  So
 >> I think this feature should behave similarly, at least by default.
 >
 >> I just noticed that the code does use ‘kill-region’ already.  This
 >> has the side-effect of putting the text into the kill ring,
 >> something which should be documented at least.  But I think the code
 >> should rather use ‘delete-region’ instead with the behavior you
 >> proposed.
 >
 > I suppose that you suggest to tell user more explicitly in echo area
 > how he cannot change the text.

The echo area should be avoided during tracking.  Think of users who
invoke 'mouse-drag-and-drop-region' on a frame without a minibuffer.

I think that first of all you should use 'delete-region' instead of
'kill-region' to avoid the above-mentioned side effect.  Then your code
should silently swallow any bugs for cutting from read-only text
provided 'kill-read-only-ok' is t.  For that purpose, simply peruse the
corresponding code from 'kill-region'.

A final drop into read-only text should always give an error.  We should
be able to redeem that by providing a feedback in form of a mouse cursor
when the mouse is either over read-only text or no buffer text at all.

 > On an user perspective, operation `drag-and-drop-region' is a
 > combination of `cut' and `paste'.  Thus text was killed instead of
 > deleted.  How you think delete is more preferred?  I have no objection
 > to document it.

IMO using 'kill-region' is an unexpected side effect.  If people
think differently, we could add yet another option like

(defucstom mouse-drag-and-drop-region-cut-does-kill-region t)

 > There is other thread about mouse-drag-and-drop-region.
 >
 > https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00588.html

I'm aware of that.  I have changed some Emacs internals to make it work
here but I have no idea of the consequences these changes might have for
other mouse-tracking functions.  So this is strictly for Emacs 27.

Thanks, martin


Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
In reply to this post by Alex-2
> From: Alex <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Wed, 15 Nov 2017 16:03:17 -0600
>
> >> I suppose (display-graphic-p) should be supplied as the 2nd argument to
> >> `tooltip-show', then?
> >
> > display-multi-frame-p is more appropriate.
>
> That appears to be an alias to `display-graphic-p'.

That's an implementation detail.  But even if it will always remain
the alias, using it still conveys the intent more clearly that
display-graphic-p, don't you agree?

> > But I think the tooltip should not be shown at all on TTY frames, it
> > looks unnecessary and even silly to show the dragged text in the echo
> > area.
>
> That sounds better.  Though I wonder if tooltips could be shown in TTY
> frames using a method similar to how `x-popup-menu' displays a menu in
> them?

No, it can't.  TTY menus pre-empt the command loop, so they cannot be
shown during mouse-tracking, AFAIR.

> >> I also noticed that when dragging in an X window, the tooltip flickers
> >> quite a bit. Is there any easy remedy for this?
> >
> > We constantly redisplay the tooltip frame, don't we?  Or does this
> > happen only with GTK tooltips?
>
> I don't know the details, but it appears that there are some redisplay
> cycles that don't show the tooltip, leading to flickering.
>
> I've only tested this with GTK tooltips so far.

Does the flickering disappear if you set x-gtk-use-system-tooltips to
nil?

> There's also a side issue that subsequent mouse-movement events appear
> to only be generated after moving a character rather than by a
> configurable amount of pixels, which leads to the tooltip movement being
> a bit jerky.

If that, too, disappears when GTK tooltips are not used, then maybe
it's due to the way we show GTK tooltips.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Alex-2
In reply to this post by martin rudalics
martin rudalics <[hidden email]> writes:

>> 1. Select a region.
>> 2. Hold down-mouse-1 inside of this region.
>> 3. Press any key before moving or releasing the mouse.
>>
>> Doing this yields an error without your change,
>
> Something like
>
> mouse-drag-region: Wrong type argument: char-or-string-p, nil
>
> I suppose.  'value-selection' must have been nil then.

Right, that's the issue. Or perhaps _an_ issue, since `kill-region' is
sent nil arguments in this case.

>> and it pastes the region
>> with your change.  Even when this key is C-g, `mark-active' is t after
>> step 3.
>
> Not much better.  But doing mouse-down and pressing another key at the
> same time is somewhat obscure behavior.

Somewhat obscure, but it should be handled better, right?

>> I also noticed that when dragging in an X window, the tooltip flickers
>> quite a bit. Is there any easy remedy for this?  Removing the
>> `mouse-set-point' call in `track-mouse' helps in some cases, but not
>> completely.
>
> Would customizing 'tooltip-reuse-hidden-frame' change anything or are
> you using GTK tooltips?

It appears that it only happens with GTK tooltips.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Alex-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> > display-multi-frame-p is more appropriate.
>>
>> That appears to be an alias to `display-graphic-p'.
>
> That's an implementation detail.  But even if it will always remain
> the alias, using it still conveys the intent more clearly that
> display-graphic-p, don't you agree?

Yeah, I agree.

>> > But I think the tooltip should not be shown at all on TTY frames, it
>> > looks unnecessary and even silly to show the dragged text in the echo
>> > area.
>>
>> That sounds better.  Though I wonder if tooltips could be shown in TTY
>> frames using a method similar to how `x-popup-menu' displays a menu in
>> them?
>
> No, it can't.  TTY menus pre-empt the command loop, so they cannot be
> shown during mouse-tracking, AFAIR.

I didn't mean to use menus directly, but to use a similar method of
displaying something "on top of" a TTY frame.  Is displaying the
rectangle that makes up a menu necessarily incompatible with a regular
command loop?  If so, do you know why?

>> > We constantly redisplay the tooltip frame, don't we?  Or does this
>> > happen only with GTK tooltips?
>>
>> I don't know the details, but it appears that there are some redisplay
>> cycles that don't show the tooltip, leading to flickering.
>>
>> I've only tested this with GTK tooltips so far.
>
> Does the flickering disappear if you set x-gtk-use-system-tooltips to
> nil?

Yes, it appears that only GTK tooltips are affected here.  Should I file
a bug report?

>> There's also a side issue that subsequent mouse-movement events appear
>> to only be generated after moving a character rather than by a
>> configurable amount of pixels, which leads to the tooltip movement being
>> a bit jerky.
>
> If that, too, disappears when GTK tooltips are not used, then maybe
> it's due to the way we show GTK tooltips.

I don't believe this one has to do with GTK.  If you set `track-mouse' to
t, then, after the first pixel movement, you will only see
mouse-movement events when you move the mouse to a whole character
position.  This might be intentional, but I think it's poor behaviour.

Reply | Threaded
Open this post in threaded view
|

Re: mouse-drag-and-drop-region

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Fri, 17 Nov 2017 00:33:48 -0600
>
> >> That sounds better.  Though I wonder if tooltips could be shown in TTY
> >> frames using a method similar to how `x-popup-menu' displays a menu in
> >> them?
> >
> > No, it can't.  TTY menus pre-empt the command loop, so they cannot be
> > shown during mouse-tracking, AFAIR.
>
> I didn't mean to use menus directly, but to use a similar method of
> displaying something "on top of" a TTY frame.  Is displaying the
> rectangle that makes up a menu necessarily incompatible with a regular
> command loop?

Yes, it is incompatible.

> If so, do you know why?

Because TTY menus are implemented by overwriting parts of the glyph
matrix with text that comes "out of nowhere", as far as the normal
redisplay is concerned.  IOW, there's no buffer or display string or
overlay string that the display engine knows about that produce this
text.  So if we let the command loop do its thing, it will eventually
enter redisplay, and the menu will be erased, partially or fully.

> > Does the flickering disappear if you set x-gtk-use-system-tooltips to
> > nil?
>
> Yes, it appears that only GTK tooltips are affected here.  Should I file
> a bug report?

Yes, of course.  Though I doubt we have the expertise to fix it (or
maybe it's even unfixable as long as we implement the GTK support the
way we do).

> >> There's also a side issue that subsequent mouse-movement events appear
> >> to only be generated after moving a character rather than by a
> >> configurable amount of pixels, which leads to the tooltip movement being
> >> a bit jerky.
> >
> > If that, too, disappears when GTK tooltips are not used, then maybe
> > it's due to the way we show GTK tooltips.
>
> I don't believe this one has to do with GTK.  If you set `track-mouse' to
> t, then, after the first pixel movement, you will only see
> mouse-movement events when you move the mouse to a whole character
> position.  This might be intentional, but I think it's poor behaviour.

Can you show a Lisp recipe to reproduce this?

12