emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] Fix uncaught error when trying to open a link at point


From: Nicolas Goaziou
Subject: Re: [O] [PATCH] Fix uncaught error when trying to open a link at point
Date: Wed, 28 Nov 2012 13:53:40 +0100

Hello,

Samuel Loury <address@hidden> writes:

> From 0e31213fa486f7fcfe1c2b7037689df077a39fce Mon Sep 17 00:00:00 2001
> From: Samuel Loury <address@hidden>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]