Re: Making TTY menus more visual

[Eli Zaretskii]

> Date: Wed, 07 Oct 2020 23:39:07 -0700
> From: Jared Finder <jared@finder.org>
> Cc: emacs-devel@gnu.org
> 
> > 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.

The added complexity is minor, won't you agree?  And it only affects
xt-mouse itself and its workalikes, and then only in the context of
TTY menus, something that never worked until now.  So any client that
wants to support menus will need to make changes anyway.  Any other
uses of mouse-position-function are unaffected.  So I don't quite see
where we put any tangible burden on other clients.  Am I missing
something?

> 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 don't think we can decide on a backward-incompatible change based on
any reasonable search of ELisp code out there.  Emacs is stable, which
means users and programmers rightfully expect us not to break backward
compatibility unless it is really necessary and justified.  In this
case, the price for staying backward compatible is small, so I think
the balance is clearly in favor of not calling the hook inside TTY
menus.  The implementation of TTY menus is very delicate, so I'd very
much prefer to avoid any unnecessary Lisp calls while a menu is
displayed, because calling Lisp there is in effect a permission for
user programs to do whatever they like -- we cannot control what they
do.  For example, if the Lisp this hook calls causes redisplay, the
menu display could potentially be screwed.

> 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.

Based on the analysis above, I think the price for staying compatible
is very small, while the advantage of that is significant, as that is
what our users expect from us.

Thanks.