Subject: Re: bug#76384: Incorrect mouse events / tool-bar event is undefined error.

From: mjk <[email-masked]>
Date: Thu, 20 Feb 2025 16:46:44 +0200

I think I already sent the full info about the version that failed.

The working one is the same (version number) with the -.gt-x11 
extension, and emacs-lucid works too.

I downloaded and compiled version 30.1 (rc on the web page) and compiled 
it. This one seems to work, but with the default config, configure 
produces a version that uses lucid, which seems to work as 29 too.

Not sure what to do to produce similar to the failing one, and whether 
it is worth while to use a lot of time to try to reproduce this.

t. mjk

On 20.2.2025 9.30, Eli Zaretskii wrote:
>> Date: Thu, 20 Feb 2025 03:49:28 +0200
>> Cc: [email-masked]
>> From: mjk <[email-masked]>
>>
>> Got some more info by testing. Rather interesting.
>> The reason I mentioned the window manager, is because that I haven't had
>> much trust on gnome quality since version 3 (this is 46).
>>
>> So I installed xcfe and tried there. Works fine. I do get mouse scroll
>> beeps on the tool bar, but I think that is kind of correct behavior.
>> Handlers just not defined.
>> In this configuration mouse events in text window scroll only the text
>> window as expected.
>>
>> On Xfce emacs (don't actually know where it comes from), pops up a
>> display that says that pure gtk version of emacs is not supported and
>> can cause crashes during transfers of large data, and recommends
>> installing emacs-gtk-x11 or emacs-lucid.
>> To me this sounds like fedora related tweaking.
>>
>> So I installed emacs-gtk-x11, and this seems to work fine, at least with
>> the simplest case with *scrach* buffer and no configuration of my own.
>>
>> This seems to be some kind of mismatch between the pure gtk emacs and
>> gnome window manager, or maybe in the window manager itself. dunno.
>> What is weird is that in the versions that work, I get the mouse event
>> errors from the tool-bar (as expected if they are not defined),
>> but in non working config I get them from the working window area. But -
>> the tool bar works otherwise, so other mouse events are mapped correctly.
>> So it is very surprising that different events are managed different
>> way. Seems that somebody is doing something fancy and overly complicated.
>>
>> So, maybe this is not an emacs bug after all.
> Thanks.  With which versions of Emacs did you try the above?  Po Lu
> says Emacs 30 should probably solve this, so the versions you tried
> could be relevant.
>
> Another thing to try is Emacs 30 (currently available only as a
> pretest) and see if the problem there exists even in your original
> window manager.