Do you see the same problem if you start Emacs using emacs -Q (no init file)? If not, bisect your init file to find the culprit.
this post was submitted on 18 Oct 2023
1 points (100.0% liked)
Emacs
314 readers
2 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
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
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
Nope! And when I tried with my config the very first click had that issue. It's very weird tho, I have no idea what could be causing it...
Bisect your init file. You can use command comment-region comment out 1/2 of it, then 3/4, then 7/8,... till you can see easily what's causing the problem. This is a binary search, so it narrows things down quickly.
Ok, I just did. It's (global-display-line-numbers-mode). Now.... why???? It's odd as hell.
Do you have Evil or god-mode or meow or anything remotely similar?
Nope, vanilla emacs in that respect.
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.
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.
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.
I have recorded a video, it's in the OP.
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.
as you said, display-line-numbers do the shift when the cursor change the quantity of numbers in the line, from 9 to 10, for example, maybe if you use `absolute` can help, or you use can try change a fixed width from the line number, so it cannot change the window size.
Also, you can see this example from modus-theme to help you.