Stopping mouse-1 from opening [[url]]-type links in Org mode

I often have lower-level headings that consist of links only. When I just want to click anywhere on them to place point on the heading, I usually can't avoid Org opening the link on top of placing point, which isn't at all what I want. I'd much rather use mouse-2 or mouse-3 or something like C-mouse-1 to open them while disabling that functionality for mouse-1. Where / how best to set this up? Any help much appreciated! Many thanks

You don't need to configure anything! Just hold the mouse button down for a second before releasing and it will set point instead of following the link. This is controlled by the variable `org-mouse-1-follows-link` which can be set to a number, meaning the number of milliseconds you have to hold the button down to stop Org from following the link, or to `nil` which means to never open links with the mouse. (So if you can't get used to holding the click, just set the variable to nil.) EDIT: That stuff above is what the docstring says. It doesn't appear to actually work in my subsequent tests! The `defcustom` declaration actually shows `nil` is not a valid option, your options are: - a number of milliseconds, as described above; - `t`, meaning always immediately follow links; and - `double`, meaning you need to double click. EDIT2: I tried setting it to double and it doesn't actually work, single clicks still open the link! Oh, well: for me the default value of 450ms is fine, and I just long click to avoid following the link. EDIT3: the non-Org variable `mouse-1-click-follows-link` does allow setting to nil and it does work! Of course, it affects all links, not just org links. :( EDIT4: You can disable click following links with `(define-key org-mouse-map [mouse-2] #'ignore)`. Notice the `mouse-2`, that's not a typo! Somehow mouse-2 gets translated to mouse-1. Weird, huh? Anyway, you can then set some other mouse event to follow links, like `(define-key org-mouse-map [mouse-3] #'org-open-at-mouse)`.

You can look into "customising" `org-mouse-1-follows-link`, which allows disabling following the link with mouse-1, or requiring a double-click. (I think that mouse-2 and mouse-3 already sort-of follow the link, so you shouldn't have to do any further changes to allow that.)

> EDIT2: I tried setting it to double and it doesn't actually work, single clicks still open the link! I have also tested, and same here. Definitely a bug. M-x report it :-).

I will, when I get the chance, if I can reproduce the problem from `emacs -q`.

Editor playing up again. Thank you all for your amazingly useful input. Had websearched before but didn't find any mention of these variables. Setting 'mouse-1-click-follows-link' to nil is my preferred solution for now and everything now works as I want it to. Great stuff, thanks!

>EDIT4: You can disable click following links with (define-key org-mouse-map [mouse-2] #'ignore). Notice the mouse-2, that's not a typo! Somehow mouse-2 gets translated to mouse-1. Weird, huh? Anyway, you can then set some other mouse event to follow links, like (define-key org-mouse-map [mouse-3] #'org-open-at-mouse). As is usually the case, historical reasons apparently. It is kind of touched in the Info node `(elisp) Clickable Text`

I failed to reproduce it in master fwiw. emacs-repository-version is "58bb9eb4005599155a8fce8d5c5beb531a72c534"

Thanks! Although that doesn't explain *why* there is this mouse-1/mouse-2 business (other than saying it is "for compatibility with other graphical applications"), it does explain in detail *how* it works.

This may also depend on the Org version you try, not just Emacs.

Ah, I was setting mouse-1-click-follow-links. I should have read more carefully. I can reproduce it here too and org-version is "9.5.2"

You have to set it before loading org! If I do that, it works as expected. cc. u/Keybug

Well this is embarrassing! It says you have to set it before loading org right there in the docstring and I somehow missed it! Thanks for pointing that out. I think there's still a little something that might be worth reporting though. I tried `(setq org-mouse-1-follows-link nil)` and that worked as expected, but restarting Emacs and using `(setq org-mouse-1-follows-link 'double)` did not work: single clicks kept opening org mode links. Now, the docstring for `org-mouse-1-follows-link` does *not* mention `double`, so you could say `double` not working is to be expected, however the `defcustom` declaration for the variable does mention `double`: (const :tag "A double click follows the link" double) So I feel justified in expecting `double` to work.

Weird. Are you sure double doesn't work? It works just fine on my end. Tho org-mode's double click behaviour is worse than Emacs'.

I tried again just make sure and `double` really doesn't work for me. Here's exactly what I did: in `emacs -q` the first thing I did was evaluate `(setq org-mouse-1-follows-link 'double)` and then I opened an org file and single-clicked on some links. They were all followed. I'm on an oldish Emacs 28.0.50, to be precise: > GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-04-04, unofficial emacs-snapshot build: http://emacs.ganneff.de/, git commit dd5ba88afbb63f54603cc632fc55993c04531a85 It comes with Org 9.4.4, which what the above procedure winds up using. I also have Org 9.5.2 installed, so I tried another experiment: same as above, but running `M-x package-intiialize` after setting `org-mouse-1-follows-link` and before opening an org file. That way I get Org 9.5.2. The same thing happens: single clicks still open links. On the other hand the analogous experiments with `nil` instead of `'double` do work and keep single-clicks from opening links.

It turns out that setting 'mouse-1-click-follows-link' to nil has the unwanted side effect that folding / unfolding org trees by clicking on a heading's asterisks (when the cursor turns into that hand-shaped icon) no longer works. I can live with that, though, since I've designated the right mouse button to fold / unfold when clicking anywhere on a heading (via Autohotkey). Still, it would be nice to be able to use the standard functionality for it once in a while...

To me, that sounds like a (design) bug in Org. Buttons shouldn't be summarily handled like links. Clicking link *text* with `mouse-1` is what `mouse-1-click-follows-link` should be about. It shouldn't be about clicking buttons with `mouse-1`. ---- Emacs is **greatly** about working with *text* - Emacs is at least partly about *editing text*. And being able to just click `mouse-1` at some position in text to *set point* there is basic to Emacs. And by "just click" I don't mean press `mouse-1` and hold it down for some time. That's a horrible, ugly, hacky workaround. Defaulting `mouse-1-follows-click` to non-`nil` was an awful design decision. Emacs should still, as it used to, just use `mouse-2` by default for following links. ---- Ask yourself: **Which is more common: (1) to want to paste text on top of a link or (2) to want to set point somewhere within the text of a link?** If you think #1 is more common then you likely agree with the (bad) default behavior of `mouse-1-click-follows-link`. If you think #2 is more common then consider customizing that option to `nil`.

Yeah, historical. But not accidental. It was a *bad* design decision, made only based on the argument that users were becoming used to clicking `mouse-1` outside Emacs (e.g. in web browsers) to follow links. This was way back when the web became a thing and Emacs wanted to "modernize" to attract more users (sound familiar?). This bad design ignores the fact that, unlike a web browser, Emacs is a **text editor** (among other things), and that `mouse-1` is super-important for its job of setting point. *See my other reply in this thread.* Emacs should default `mouse-1-click-follows-link` to `nil` (or it never should have added that option). Use `mouse-2` to follow links. Use `mouse-1` to set point (including in link text). (You don't need to use `mouse-2` to paste into link text.)

See my reply to /u/_viz_ above, and my other reply in this thread. This `mouse-1`-to-follow-links nonsense came from Emacs trying to fit into the world of users clicking links in web browsers with `mouse-1`.

I agree with you, it is better to have mouse-1 just set point. Unfortunately on my laptop mouse-2 is a 3-finger tap which I find hard to execute reliably. (It's not a big deal since I use the mouse very little while in Emacs anyway.)

Ah, yes. I should have mentioned that. You're 100% right that using such a pseudo-mouse is a different ball game. ---- The mouse in Emacs (assuming it has at least 3 buttons) is not all that well known, and so is underappreciated IMO. In particular, double- and triple-clicking, and using `mouse-3` to relimit the region, can be handy. (Including relimiting the secondary selection, if combined with [`second-sel.el`](https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el).) ---- At least `mouse-3` *was* handy this way until they recently dismembered it, replacing it with *only* a predefined context menu. Library [`mouse3.el`](https://www.emacswiki.org/emacs/Mouse3) gives you context menus without losing the traditional `mouse-3` behavior.