Emacs

311 readers

2 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Windows
Mac OS X
GNU/Linux and BSD (Just get it from your distribution's package manager)

Rules

Posts should be emacs related
Be kind please
Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

Put the Caps Lock key to better use!

founded 1 year ago

MODERATORS

[email protected]

Emacs is inconsistent when clicking buttons with the mouse (alien.top)

submitted 1 year ago by [email protected] to c/[email protected]

12 comments fedilink hide all child comments

For some reason, when I click a button, be it in the customize buffer or hyperlinks in org documents, it sometimes works, and other times the whole buffer shifts to the left like a single pixel and it sets a mark (it says so in the minibuffer). The button is not clicked in those instances.

Has someone experienced something similar? Is there a way to improve this?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 year ago (4 children)

I don't know, but it might help to check C-h l to see which sequence of mouse events Emacs is reporting in each case.

[–] [email protected] 1 points 1 year ago (3 children)

I just tested, it reports that I'm dragging the mouse and setting a region, but it's weird because if the issue is my clicking being sloppy, when it should happen in emacs with no config as well, and it doesn't.

      ;; mouse-drag-region
                 ;; mouse-set-region

This is when I click and the button doesn't get pressed.

   ;; mouse-drag-region
                   ;; Info-mouse-follow-nearest-node

And this is when it does register.

I can never reproduce the issue on emacs without config.

[–] [email protected] 1 points 1 year ago (1 children)

My guess is that the "drag" detection is a side-effect of this:

the whole buffer shifts to the left like a single pixel

as it's conceivable that this means the positions of the click and release are "different" even if you didn't actually move the mouse.

So that maybe explains the end result, but not the actual trigger.

I'm just speculating though.

[–] [email protected] 1 points 1 year ago (1 children)

I have recorded a video, it's in the OP.

[–] [email protected] 1 points 1 year ago

Interesting. I'm still just guessing, but I notice that you're using relative line numbers which means that there's a potential difference between the amount of space needed to show the relative line number vs the absolute line number, and that might explain the shift in display. Can you reproduce this when using absolute line numbers? If not, that seems to narrow down the trigger scenario, which will be helpful information for an upstream bug report.

load more comments (1 replies)