[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mouse-drag-and-drop-region
From: |
Alex |
Subject: |
Re: mouse-drag-and-drop-region |
Date: |
Fri, 17 Nov 2017 00:33:48 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) |
Eli Zaretskii <address@hidden> 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.
- Re: mouse-drag-and-drop-region, (continued)
- Re: mouse-drag-and-drop-region, Alex, 2017/11/15
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/15
- Re: mouse-drag-and-drop-region, Alex, 2017/11/15
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/16
- Re: mouse-drag-and-drop-region,
Alex <=
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/17
- Re: mouse-drag-and-drop-region, Stefan Monnier, 2017/11/17
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/17
- Re: mouse-drag-and-drop-region, Stefan Monnier, 2017/11/17
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/18
- Re: mouse-drag-and-drop-region, Stefan Monnier, 2017/11/18
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/18
- Re: mouse-drag-and-drop-region, Stefan Monnier, 2017/11/18
- Re: mouse-drag-and-drop-region, Alex, 2017/11/18
- Re: mouse-drag-and-drop-region, Eli Zaretskii, 2017/11/18