[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-orgmode] org-mouse.el
From: |
Carsten Dominik |
Subject: |
[Emacs-orgmode] org-mouse.el |
Date: |
Thu, 13 Apr 2006 09:40:27 +0200 |
On Apr 12, 2006, at 11:59, Piotr Zielinski wrote:
I've just fixed an incompatibility bug, which prevented org-mouse from
operating correctly with org-mode 4.21. Here's the latest version:
I really like org-mouse.el, in particular the menus with
TODO keywords, tags and priorities.
In the latest version, the context menu on links does not seem to work
- on links I still get the context menu for normal text. At first I
thought this was only for the new bracket links, but it is the same for
all link types, because `org-mouse-at-link' never returns t.
While looking at this function I realized that org.el and org-mouse.el
could check for a link at the cursor position in a much simpler way:
(defun org-mouse-at-link ()
(and (eq (get-text-property (point) 'face) 'org-link)
(save-excursion
(goto-char (previous-single-property-change (point) 'face))
(or (looking-at org-bracket-link-regexp)
(looking-at org-angle-link-re)
(looking-at org-plain-link-re)))))
This implementation depends on having font-lock active, but then a lot
of functionality in org-mode depends on that.
One more thing. I am totally used now to the fact that mouse-1 does
follow a link in Org-mode buffers, this feels completely natural. But
I am not so sure in agenda buffers. Since almost every line in that
buffer has a mouse-face property, pretty much any click in the agenda
window will send the cursor off into another buffer and window. I
would like to be able to customize this. In org.el 4.22 (on the web
now, with a few bug fixes), there is a new variable
`org-agenda-mouse-1-follows-link'. Right now, org-mouse.el does
overrule this. Could org-mouse.el honor this variable or even better no
longer put those bindings to [follow-link] at all because org.el does
this already?
Thanks.
- Carsten