Hi, recently this syntax: <<< >>> started highlighting all spaces (spaces between words) as if they were links. I see them with a blue underline. I found this because I used some Unicode-art like <<<<<<<<< >>>>>>>>> where I certainly didn't mean to define a radio link. This happens since this change: #+BEGIN_QUOTE commit 1c1936fbb1f0c42e5c7e1d3c903626aa5993a357 Author: Nicolas Goaziou <n.goaziou@gmail.com> Date: Tue Mar 25 10:15:25 2014 +0100 Allow radio links after an apostrophe and mid-word * lisp/org.el (org-make-target-link-regexp): Allow radio links after an apostrophe and mid-word. Small refactoring. * testing/lisp/test-ox.el (test-org-export/resolve-radio-link): Add test. See http://permalink.gmane.org/gmane.emacs.orgmode/84108. #+END_QUOTE Greetings, Daniel
Hello,
Daniel Clemente <n142857@gmail.com> writes:
> Hi, recently this syntax: <<< >>> started highlighting all spaces (spaces between words) as if they were links. I see them with a blue underline.
> I found this because I used some Unicode-art like <<<<<<<<< >>>>>>>>> where I certainly didn't mean to define a radio link.
This should be fixed. Thank you for reporting it.
Regards,
--
Nicolas Goaziou
El Wed, 02 Apr 2014 14:59:42 +0200 Nicolas Goaziou va escriure:
> > Hi, recently this syntax: <<< >>> started highlighting all spaces (spaces between words) as if they were links. I see them with a blue underline.
> > I found this because I used some Unicode-art like <<<<<<<<< >>>>>>>>> where I certainly didn't mean to define a radio link.
>
> This should be fixed. Thank you for reporting it.
Now it works, thanks.
I also found a strange behaviour where links appear in the middle of words. Explanatory example:
** Languages
*** <<<C>>> language
*** <<<JavaScript>>>
*** etc.
Etc. ← should the C in etc be highlighted as a link to „C“? Now it is and it's a bit annoying. This is new behaviour.
Hello,
Daniel Clemente <n142857@gmail.com> writes:
> ** Languages
> *** <<<C>>> language
> *** <<<JavaScript>>>
> *** etc.
> Etc. ← should the C in etc be highlighted as a link to „C“? Now it is and it's a bit annoying. This is new behaviour.
Indeed, this is expected. The patch you pointed out allows mid-word
radio-targets. See related thread for more information.
You could use a regular target here, although it will be more verbose:
*** <<c>>C language
...
Etc. But here I really talk about [[c][C]].
Regards,
--
Nicolas Goaziou
El Wed, 02 Apr 2014 18:57:13 +0200 Nicolas Goaziou va escriure: > > > ** Languages > > *** <<<C>>> language > > *** <<<JavaScript>>> > > *** etc. > > Etc. ← should the C in etc be highlighted as a link to „C“? Now it is and it's a bit annoying. This is new behaviour. > > Indeed, this is expected. The patch you pointed out allows mid-word > radio-targets. See related thread for more information. > „Related thread“: http://comments.gmane.org/gmane.emacs.orgmode/82923 I don't see in there any argument to have midword links, it's presented as a consequence of other patch. I'm a heavy user of <<<these links>>> to mark concepts' definitions, they are much more useful than <<these>> or [[these]]. I have notes about programs I tried, like <<<R>>>, <<<at>>> or <<<ps>>>, <<<C>>>, <<<CR>>> vs <<<LF>>> vs <<<CRLF>>>, 3-letter stock tickers, … so now I'm seeing blue links everywhere in the middle of words. I can get used to it, but it's ugly and not useful. I only need links surrounded by non-letters, like: #+BEGIN_EXAMPLE <<<org>>> organization ← certainly I'm not using the letter 'a' as a separator. I don't want link. org:mode ← ':' is a non-letter, so it's a separator. I want link orgもmode ← what's も? Let's simply say it's a letter, so no separator. No link, ok. org'mode ← is ' a letter? Ask people, I think most say no. So: with link. <<<o'clock>>> (oh, a non-letter inside. Ok) o'clocking ← no, I'm not using 'i' as a separator. No link. "o'clock" ← is " a letter? No. So: with link #+END_EXAMPLE The only use case I see is using radio links to mark the root of a word so that the inflected words are also highlighted, e.g. <<<script>>> would highlight „scripting“. But hey, when I want both „script“ and „scripting“ highlighted, I use radio links on both, not a problem. Can't we break at non-letters? Not at non-„word-constituents“, but at non-letters. If emacs doesn't provide that concept, better build it. Thanks
Hello, Daniel Clemente <n142857@gmail.com> writes: > „Related thread“: http://comments.gmane.org/gmane.emacs.orgmode/82923 > > I don't see in there any argument to have midword links, it's > presented as a consequence of other patch. I didn't say there was an argument there. I just pointed out that your report was a known fact and that it was discussed elsewhere. > I have notes about programs I tried, like <<<R>>>, <<<at>>> or > <<<ps>>>, <<<C>>>, <<<CR>>> vs <<<LF>>> vs <<<CRLF>>>, 3-letter stock > tickers, … so now I'm seeing blue links everywhere in the middle of > words. I can get used to it, but it's ugly and not useful. I can understand that. > Can't we break at non-letters? Not at non-„word-constituents“, but at > non-letters. If emacs doesn't provide that concept, better build it. I don't know. Could you define precisely that concept? Regards, -- Nicolas Goaziou
>
> > Can't we break at non-letters? Not at non-„word-constituents“, but at
> > non-letters. If emacs doesn't provide that concept, better build it.
>
> I don't know. Could you define precisely that concept?
>
I propose: radio links should be delimited by characters that don't match [:alpha:] in emacs' regular expression syntax.
Letters (like: aá書ĉ) match, and delimiters (like: -'"/) don't.
Test it with:
: (string-match-p "[[:alpha:]]" "á")
: (string-match-p "[[:alpha:]]" "書")
: (string-match-p "[[:alpha:]]" "ĉ")
: (string-match-p "[[:alpha:]]" "'")
: (string-match-p "[[:alpha:]]" "-")
And the opposite: check for non-letterness:
: (string-match-p "[^[:alpha:]]" "-")
: (string-match-p "[^[:alpha:]]" "á")
So a radio link with LINK_TEXT should not only be a match of the regexp "LINK_TEXT" but of "[^[:alpha:]]LINK_TEXT[^[:alpha:]]" (well, make it something like "(^|non-letter)LINK_TEXT($|non-text)".
I think that's better than the current solution and stills allows for radio links which contain non-letters, like <<<o'clock>>>.
What do you think?
Daniel
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --] Hello, Daniel Clemente <n142857@gmail.com> writes: > I propose: radio links should be delimited by characters that don't match [:alpha:] in emacs' regular expression syntax. > Letters (like: aá書ĉ) match, and delimiters (like: -'"/) don't. > > Test it with: > : (string-match-p "[[:alpha:]]" "á") > : (string-match-p "[[:alpha:]]" "書") > : (string-match-p "[[:alpha:]]" "ĉ") > > : (string-match-p "[[:alpha:]]" "'") > : (string-match-p "[[:alpha:]]" "-") > > And the opposite: check for non-letterness: > : (string-match-p "[^[:alpha:]]" "-") > : (string-match-p "[^[:alpha:]]" "á") > > > So a radio link with LINK_TEXT should not only be a match of the > regexp "LINK_TEXT" but of "[^[:alpha:]]LINK_TEXT[^[:alpha:]]" (well, > make it something like "(^|non-letter)LINK_TEXT($|non-text)". > > I think that's better than the current solution and stills allows > for radio links which contain non-letters, like <<<o'clock>>>. What > do you think? It could work. But I think [:alnum:] is needed instead of [:alpha:]. Here's a patch implementing it. Regards, -- Nicolas Goaziou [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-No-alphanumeric-characters-around-radio-links.patch --] [-- Type: text/x-diff, Size: 4380 bytes --] From 581e68fda98e737043fce479e6eb0cf2b3599c9b Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou <n.goaziou@gmail.com> Date: Thu, 10 Apr 2014 22:23:27 +0200 Subject: [PATCH] No alphanumeric characters around radio links * lisp/org.el (org-make-target-link-regexp): Change regexp so alphanumeric characters cannot be found next to a radio link. (org-activate-target-links): Apply changes to radio link regexp. * lisp/org-element.el (org-element--object-lex, org-element-link-parser): Apply changes to radio link regexp. * testing/lisp/test-org-element.el (test-org-element/link-parser): Update test. Patch suggested by Daniel Clemente. http://permalink.gmane.org/gmane.emacs.orgmode/84461 --- lisp/org-element.el | 15 +++++++++------ lisp/org.el | 10 +++++----- testing/lisp/test-org-element.el | 7 +++---- 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 06cce47..13837e9 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2943,12 +2943,14 @@ Assume point is at the beginning of the link." raw-link link search-option application) (cond ;; Type 1: Text targeted from a radio target. - ((and org-target-link-regexp (looking-at org-target-link-regexp)) + ((and org-target-link-regexp + (save-excursion (or (bolp) (backward-char)) + (looking-at org-target-link-regexp))) (setq type "radio" - link-end (match-end 0) - path (org-match-string-no-properties 0) - contents-begin (match-beginning 0) - contents-end (match-end 0))) + link-end (match-end 1) + path (org-match-string-no-properties 1) + contents-begin (match-beginning 1) + contents-end (match-end 1))) ;; Type 2: Standard link, i.e. [[http://orgmode.org][homepage]] ((looking-at org-bracket-link-regexp) (setq contents-begin (match-beginning 3) @@ -4184,8 +4186,9 @@ to an appropriate container (e.g., a paragraph)." (save-excursion (let ((limit (and org-target-link-regexp (save-excursion + (or (bolp) (backward-char)) (re-search-forward org-target-link-regexp nil t)) - (match-beginning 0))) + (match-beginning 1))) found) (while (and (not found) (re-search-forward org-element--object-regexp limit t)) diff --git a/lisp/org.el b/lisp/org.el index aa86a3c..321eb71 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6091,13 +6091,13 @@ by a #." (let ((case-fold-search t)) (if (re-search-forward org-target-link-regexp limit t) (progn - (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) - (add-text-properties (match-beginning 0) (match-end 0) + (org-remove-flyspell-overlays-in (match-beginning 1) (match-end 1)) + (add-text-properties (match-beginning 1) (match-end 1) (list 'mouse-face 'highlight 'keymap org-mouse-map 'help-echo "Radio target link" 'org-linked-text t)) - (org-rear-nonsticky-at (match-end 0)) + (org-rear-nonsticky-at (match-end 1)) t))))) (defun org-update-radio-target-regexp () @@ -6192,13 +6192,13 @@ targets." The regular expression finds the targets also if there is a line break between words." (and targets - (concat "\\(" + (concat "\\(?:^\\|[^[:alnum:]]\\)\\(" (mapconcat (lambda (x) (replace-regexp-in-string " +" "\\s-+" (regexp-quote x) t t)) targets "\\|") - "\\)"))) + "\\)\\(?:$\\|[^[:alnum:]]\\)"))) (defun org-activate-tags (limit) (if (re-search-forward (org-re "^\\*+.*[ \t]\\(:[[:alnum:]_@#%:]+:\\)[ \r\n]") limit t) diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el index 4eccb69..0f81a79 100644 --- a/testing/lisp/test-org-element.el +++ b/testing/lisp/test-org-element.el @@ -1336,12 +1336,11 @@ e^{i\\pi}+1=0 (should (equal "radio" - (org-test-with-temp-text "A radio link" + (org-test-with-temp-text "<<<radio>>>A radio link" + (org-update-radio-target-regexp) (org-element-property :type - (org-element-map - (let ((org-target-link-regexp "radio")) (org-element-parse-buffer)) - 'link 'identity nil t))))) + (org-element-map (org-element-parse-buffer) 'link #'identity nil t))))) ;; Standard link. ;; ;; ... with description. -- 1.9.2
Hi Nicolas,
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Here's a patch implementing it.
Looks good, please go ahead. Thank you both,
--
Bastien
Hello,
Bastien <bzg@gnu.org> writes:
> Looks good, please go ahead. Thank you both,
Applied.
Regards,
--
Nicolas Goaziou
El Thu, 10 Apr 2014 23:43:41 +0200 Nicolas Goaziou va escriure:
>
> It could work. But I think [:alnum:] is needed instead of [:alpha:].
> Here's a patch implementing it.
>
Now it's much better. Thanks.