Re: mouse-drag-and-drop-region

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Date: Sat, 18 Nov 2017 00:48:27 -0600
> Cc: rudalics@gmx.at, tak.kunihiro@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> 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.
> 
> Oh, that's unfortunate.

If you or someone else has better ideas for implementing menus on a
TTY, let's hear them.

> >> 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?
> 
>   (setq track-mouse t)
>   (setq count 0)
> 
>   (global-set-key [mouse-movement]
>                   (lambda ()
>                     (interactive)
>                     (message "%d" (setq count (1+ count)))))
> 
> This will only message on the first mouse-movement event (after a
> non-mouse-movement event), and after moving to a new character position.

That's the intended behavior, see note_mouse_movement.

> It also messages after a down-click, which feels like a bug.

Not here, it doesn't.  I only see a message after a movement to
another glyph.