Hello, Samuel Loury <konubi...@gmail.com> writes:
> From 0e31213fa486f7fcfe1c2b7037689df077a39fce Mon Sep 17 00:00:00 2001 > From: Samuel Loury <samuel.lo...@cosmo-platform.org> > Date: Thu, 22 Nov 2012 09:31:15 +0100 > Subject: [PATCH] Fix the uncaught exception when doing opening a link from > nowhere > > * lisp/org.el (org-open-at-point): Make sure point is on a > org-plain-link-re before trying to go to its beginning > > In cases the custor at point did not match anything, the piece of > code (goto-char (car (org-in-regexp org-plain-link-re))) threw an > error. > > The inital intention of avoiding matching a org-plain-link-re when > just after a org-bracket-link-regexp, from the commit originating > the error (ad35e2ac6c6decae55dd987be738e07e7c87bd7d) was conserved. > > TINYCHANGE Thank you for your patch. A few comments below. > (save-excursion > (when (or (org-in-regexp org-angle-link-re) > - (and (goto-char (car (org-in-regexp org-plain-link-re))) > - (save-match-data (not (looking-back "\\[\\["))))) > + (let ( > + (match (org-in-regexp org-plain-link-re)) > + ) Please do not leave dangling parens in your code. This is quite confusing. > + (and > + ;; link at point is a plain link > + match > + ;; check that it is not of the form > + ;; [[http://orgmode.org][Org]]Mode. in that > + ;; case, if the cursor is on "Mode", then the > + ;; string "http://orgmode.org][Org]]Mode" is > + ;; recognized as a plain link while it should > + ;; not be > + (progn > + ;; go to the begining of the match, If we > + ;; were in the special case, we should now > + ;; be in a org-bracket-link-regexp > + (goto-char (car match)) > + (not > + (org-in-regexp org-bracket-link-regexp) > + ) > + ) > + ) > + )) Ditto. > When trying to open a link at point when no link is present, an > error is thrown. Test for instance to call org-open-at-point (C-c C-o) > while in an empty line. > > It is in fact a regression coming from > ad35e2ac6c6decae55dd987be738e07e7c87bd7d that tries to go to the result > of a org-in-regexp call without checking whether the result is empty. > > Here is a patch that keeps the idea from > ad35e2ac6c6decae55dd987be738e07e7c87bd7d (avoiding matching an > org-plain-link-re while it is in fact a org-bracket-link-regexp) and > fixing the problem. Would you mind providing some test cases for `org-open-at-point' (or ERT tests)? This function will need to be rewritten at some point; it's better if we can then avoid introducing regressions. Regards, -- Nicolas Goaziou