emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Loury <konubinix@gmail.com>
To: Bastien <bzg@altern.org>
Cc: OrgMode ML <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Fix uncaught error when trying to open a link at point
Date: Fri, 04 Jan 2013 12:39:18 +0100	[thread overview]
Message-ID: <87wqvtrxcp.fsf@konixwork.incubateur.ens-lyon.fr> (raw)
In-Reply-To: <87bodpdskd.fsf@bzg.ath.cx>


[-- Attachment #1.1: Type: text/plain, Size: 2186 bytes --]

Hi and thanks for paying attention to my patch.

Bastien <bzg@altern.org> writes:

> I allowed myself to fix this, with a somewhat smaller patch:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?h=maint&id=14ffe2

This is indeed a good way to fix the uncaught error problem.

Nonetheless, the patch I provided was intended to also correct a
functional problem (to my mind) about the consistency of the behavior of
org-open-at-point relatively to plain links. Let me explain what I mean:

* First test: with bracket links

  Imagine you have the following line (I placed a _ to indicate
  the position of the cursor)

╭────
│  some non r_elevant text [[id:some-id]]
╰────

  Within that situation, launching org-open-at-point would follow the
  id:some-id link.

  In the following situation (with the cursor inside the link)

╭────
│  some non relevant text [[id:so_me-id]]
╰────

  org-open-at-point will also open the link. That one seems obvious but I
  think it is worth keeping in mind though.

* Second test: with plain links
  Now, imagine the same scenarios with plain links

╭────
│  some non relevant text id:so_me-id
╰────

  With the cursor inside the link, org-open-at-point follows the
  link. Then with the cursor before the link:

╭────
│  some non r_elevant text id:some-id
╰────

  org-open-at-point results in an error (now caught thanks to Bastien)
  while I (and I stress it is my personal opinion) think that it should
  also follow the link, like in the case of a bracket link.

As suggested by Nicolas, I provided tests in attachment to show the 4
use cases I just explained.

The initial patch I provided was meant to enhance the implementation of
org-open-at-point to make those use cases work.

What do you think? Should we enhance the function that way. I use the
patched version for some time now and I often launch org-open-at-point
(C-c C-o) before plain links.

Thanks again for your answers.

-- 
Konubinix
GPG Key    : 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: test --]
[-- Type: text/x-diff, Size: 3160 bytes --]

From d9df74a72962020c3e695be0ad9a8646a42ee9de Mon Sep 17 00:00:00 2001
From: Samuel Loury <konubinixweb@gmail.com>
Date: Fri, 4 Jan 2013 12:31:01 +0100
Subject: [PATCH] Addition of tests highlighting the expected behavior of
 org-open-at-point in several circumstances

---
 testing/examples/open-at-point.org     |    8 ++++
 testing/lisp/test-org-open-at-point.el |   63 ++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 testing/examples/open-at-point.org
 create mode 100644 testing/lisp/test-org-open-at-point.el

diff --git a/testing/examples/open-at-point.org b/testing/examples/open-at-point.org
new file mode 100644
index 0000000..b3bb92d
--- /dev/null
+++ b/testing/examples/open-at-point.org
@@ -0,0 +1,8 @@
+
+* Header 1
+  :PROPERTIES:
+  :ID:       header1_with_great_id
+  :END:
+* Header 2
+  [[id:header1_with_great_id][Header 1]]
+  id:header1_with_great_id
diff --git a/testing/lisp/test-org-open-at-point.el b/testing/lisp/test-org-open-at-point.el
new file mode 100644
index 0000000..efb70c8
--- /dev/null
+++ b/testing/lisp/test-org-open-at-point.el
@@ -0,0 +1,63 @@
+;;; test-org-open-at-point.el
+
+;; Copyright (c) Samuel Loury
+;; Authors: Samuel Loury
+
+;; Released under the GNU General Public License version 3
+;; see: http://www.gnu.org/licenses/gpl-3.0.html
+
+;;;; Comments:
+
+;; Test for the org-open-at-point function
+
+;;; Code:
+
+\f
+;;; Bracket links
+
+(save-excursion
+  (set-buffer (get-buffer-create "test-org-open-at-point.el"))
+  (setq ly-here
+        (file-name-directory
+         (or load-file-name (buffer-file-name)))))
+
+(defun test-org-open-at-point/goto-fixture ()
+  (find-file-other-window
+   (concat ly-here "../examples/open-at-point.org"))
+  (set-buffer "open-at-point.org"))
+
+(ert-deftest test-org-open-at-point/bracket-link-inside ()
+  "Test `org-open-at-point' from inside a bracket link."
+  (test-org-open-at-point/goto-fixture)
+  ;; go inside the bracket link
+  (goto-char 113)
+  (org-open-at-point)
+  ;; should now be in front of the header
+  (should (equal (point) 2)))
+
+(ert-deftest test-org-open-at-point/plain-link-inside ()
+  "Test `org-open-at-point' from inside a plain link."
+  (test-org-open-at-point/goto-fixture)
+  ;; go inside the plain link
+  (goto-char 126)
+  (org-open-at-point)
+  ;; should now be in front of the header
+  (should (equal (point) 2)))
+
+(ert-deftest test-org-open-at-point/bracket-link-before ()
+  "Test `org-open-at-point' from before a bracket link but in the same line."
+  (test-org-open-at-point/goto-fixture)
+  ;; go before the bracket link
+  (goto-char 83)
+  (org-open-at-point)
+  ;; should now be in front of the header
+  (should (equal (point) 2)))
+
+(ert-deftest test-org-open-at-point/plain-link-before ()
+  "Test `org-open-at-point' from before a plain link but in the same line."
+  (test-org-open-at-point/goto-fixture)
+  ;; go before the plain link
+  (goto-char 124)
+  (org-open-at-point)
+  ;; should now be in front of the header
+  (should (equal (point) 2)))
-- 
1.7.10.4


[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

  reply	other threads:[~2013-01-04 11:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22  8:42 [PATCH] Fix uncaught error when trying to open a link at point Samuel Loury
2012-11-28 12:53 ` Nicolas Goaziou
2012-12-20  8:41 ` Bastien
2013-01-04 11:39   ` Samuel Loury [this message]
2013-01-04 13:17     ` Samuel Loury
2013-01-04 16:18       ` Bastien
2013-01-14 10:35         ` Samuel Loury
2013-02-13 15:25       ` Bastien
2013-02-13 16:39         ` Samuel Loury
2013-02-13 16:49           ` Bastien
2013-03-16 19:22             ` Samuel Loury
2013-03-16 19:32               ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqvtrxcp.fsf@konixwork.incubateur.ens-lyon.fr \
    --to=konubinix@gmail.com \
    --cc=bzg@altern.org \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).