emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making TTY menus more visual


From: Jared Finder
Subject: Re: Making TTY menus more visual
Date: Wed, 07 Oct 2020 23:39:07 -0700
User-agent: Roundcube Webmail/1.3.15

On 2020-10-04 11:45 pm, Eli Zaretskii wrote:
Date: Sun, 04 Oct 2020 22:36:21 -0700
From: Jared Finder <jared@finder.org>
Cc: emacs-devel@gnu.org

> This is okay as a general idea, but it would be more clean to make
> Fmouse_position call a new C function (extracted from the first part
> of Fmouse_position's code) that just computes the mouse coordinates.
> Then Fmouse_position's would call mouse-position-function after the
> new C function returns.  Then in term.c we could call just that new C
> function.  This is because it is inappropriate for mouse_get_xy to
> call mouse-position-function when a menu is being processed.

That won't work. Making mouse_get_xy call mouse-position-function is the
purpose of this change. mouse-position-function is how xterm-mouse
injects its calculated mouse positions to the TTY menus. From searching the Emacs codebase for usage of mouse-position-function, it appears that
xterm-mouse is the only client. Of course external libraries could use
it too, but I assume they would have the same goal.

Okay, but mouse-position-function can be used for any number of
purposes.  That it's currently used only by xterm-mouse in the Emacs
sources doesn't mean it isn't used elsewhere.  The functions in that
variable are not necessarily meant to be called in the context of TTY
menus; that would be an incompatible change.  So I still think we
shouldn't call mouse-position-function in general in the TTY menu
case, only when xterm-mouse is active.  Please change the code to call
mouse-position-function only in that single case.

Perhaps a slightly more general way of doing that would be to
introduce another variable that a package must set for
mouse-position-function to be called in the context of TTY menus;
xterm-mouse will then bind that variable (or the TTY menu code in
menu-bar.el could do that for xterm-mouse).  This way, we don't
hard-code xterm-mouse in the C sources.

I'm going to push back here one more time. You have more expertise here than I, so if this isn't convincing, I can implement such a variable (it's easy enough).

I'm pushing back because I can not envision a use case for mouse-position-function that would break for TTY menus but otherwise work for every other type of normal mouse input. Adding this extra step that must be done by all clients seems like adding needless complexity.

I did a much more exhaustive search of Emacs code and remain convinced that the only use of mouse-position-function is for cases just like xt-mouse.el:

I did a search of MELPA to see if there was any use of mouse-position-function. I found nothing.

I searched GitHub for any usage and only found usages aligned with xt-mouse, specifically:

* xt-mouse.el, loadhist.el from Gnu Emacs repo forks.
* t-mouse.el from (old) Gnu Emacs repo forks.
* ext-mouse.el, a modification of an old version of xt-mouse.el that adds dragging support. * hyperbole.el from Gnu Elpa, which uses this to fix a bug in old versions of Gnu Emacs. * A handful of other files that do not actually set mouse-position-function, they instead deal with other aspects (e.g. syntax highlighting built-in symbols)

I realize this isn't an exhaustive list of all possible code, but I suspect it is a very representative list.

Let me know your thoughts. As I said, I think you have more expertise here so I will defer to your call.

  -- MJF



reply via email to

[Prev in Thread] Current Thread [Next in Thread]