[Emacs-orgmode] org-mouse.el

[Carsten Dominik]

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