Re: [O] Radio targets
Hi, OK, thank you. I am using emacs with spacemacs and it is still using the melpa version of orgmode as I am unable to get it to load the git branch of orgmode. I will try it out once I make the switch. On Sun, Apr 16, 2017 at 2:54 AM, Nicolas Goaziou wrote: > Hello, > > R C writes: > > > Please see attached. The org file is just: > > > > * <<>> heading > > The discussion in *abc* highlights the issue. > > Fixed. Thank you. > > Regards, > > -- > Nicolas Goaziou0x80A93738 >
Re: [O] Radio targets
Hello, R C writes: > Please see attached. The org file is just: > > * <<>> heading > The discussion in *abc* highlights the issue. Fixed. Thank you. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Radio targets
Hello, R C writes: > Hi, > Please see attached. The org file is just: > > * <<>> heading > The discussion in *abc* highlights the issue. Thank you. Fixed. Regards, -- Nicolas Goaziou
Re: [O] Radio targets
Hi, Please see attached. The org file is just: * <<>> heading The discussion in *abc* highlights the issue. On Tue, Apr 11, 2017 at 5:28 AM, Nicolas Goaziou wrote: > Hello, > > R C writes: > > > I set up radio targets such as <<>> in a heading, which makes > all > > occurrences of the word analysis to be links to the heading. However this > > seems to override the boldface settings such *Analysis*, so that the > > asterisks show up in the exported text. Is there a way to get around > > this? > > Could you show an ECM demonstrating the issue? > > Regards, > > -- > Nicolas Goaziou > tst.pdf Description: Adobe PDF document tst.org Description: Binary data
Re: [O] Radio targets
Hello, R C writes: > I set up radio targets such as <<>> in a heading, which makes all > occurrences of the word analysis to be links to the heading. However this > seems to override the boldface settings such *Analysis*, so that the > asterisks show up in the exported text. Is there a way to get around > this? Could you show an ECM demonstrating the issue? Regards, -- Nicolas Goaziou
[O] Radio targets
I set up radio targets such as <<>> in a heading, which makes all occurrences of the word analysis to be links to the heading. However this seems to override the boldface settings such *Analysis*, so that the asterisks show up in the exported text. Is there a way to get around this? Thanks.
Re: [O] radio targets, a bug?
Hi Thomas, thomas kalbe writes: > (after that comes a number of weird symbols that I cannot even copy > into the email...) What version of Org are you using? M-x org-version RET Thanks, -- Bastien
[O] radio targets, a bug?
Hi All, html-export for the following minimal example breaks: === Keyword1 "keyword2" <<>> <<>> === Error Message: org-export-activate-smart-quotes: Wrong number of arguments: #[(q type) "ÆÇ\" (after that comes a number of weird symbols that I cannot even copy into the email...) Removing the quotes around "keyword2" fixes the problem: === Keyword1 keyword2 <<>> <<>> === What also works is to add another word between Keyword1 and "keyword2": === Keyword1 and "keyword2" <<>> <<>> === Thanks, thomas
Re: [O] Radio Targets in Tables
Hello, R.T. writes: > I have the following two tables in a .org file: > > TABLE A > | PM | Notebook | > |-+| > | TAD | [[./13939-SEC.org][13939-SEC]] | > | KB | [[./13488-PAG.org][13488-PAG]] | > > TABLE B > | Employee| Initials | > |-+---| > | Kenneth Bones | <<>> | > | Timothy Duggett | <<>> | > > > The intent is that when I click on an entry in the PM field in TABLE A, that > focus jumps to the associated record in TABLE B. > > The entries in the PM field do seem to link after a C-c C-c or upon initial > loading. Org mode changes them to be underlined. > > However when I click on a "PM" link, it instead takes me to the link to the > right in the associated "Notebook" column in TABLE A. > > For example, clicking on "TAD" in TABLE A does not jump me to "Timothy > Duggett" in TABLE B, but instead opens the "13939-SEC.org" file. AFAICT, this is fixed in soon-to-be-released Org 8.3 (and perhaps on current 8.2, though I didn't check). You may want to update Org. Regards, -- Nicolas Goaziou
[O] Radio Targets in Tables
Hi, I have the following two tables in a .org file: TABLE A | PM | Notebook | |-+| | TAD | [[./13939-SEC.org][13939-SEC]] | | KB | [[./13488-PAG.org][13488-PAG]] | TABLE B | Employee| Initials | |-+---| | Kenneth Bones | <<>> | | Timothy Duggett | <<>> | The intent is that when I click on an entry in the PM field in TABLE A, that focus jumps to the associated record in TABLE B. The entries in the PM field do seem to link after a C-c C-c or upon initial loading. Org mode changes them to be underlined. However when I click on a "PM" link, it instead takes me to the link to the right in the associated "Notebook" column in TABLE A. For example, clicking on "TAD" in TABLE A does not jump me to "Timothy Duggett" in TABLE B, but instead opens the "13939-SEC.org" file. I cannot explain this behavior, but am assuming it has something to do with radio links not working properly within tables. Thanks GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ c:/Program Files (x86)/emacs-24.3/lisp/org/)
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Nicolas Goaziou writes: > OK, let's try it. Time will tell. > > Installed in 1c1936fbb1f0c42e5c7e1d3c903626aa5993a357. Thanks, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello, Bastien writes: > That's quite a premature and unstable intuition, but I think it's > worth trying if your intuition goes in the same direction. Otherwise > let's just prevent apostrophes. OK, let's try it. Time will tell. Installed in 1c1936fbb1f0c42e5c7e1d3c903626aa5993a357. Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > However, I'm not sure this is something desirable, but the apostrophe > problem is mildly annoying. My intuition is that midword matching will soon be used as a neat trick, while preventing "target's" to match "<<>>" will prove annoying. Also, one can easily circumvent midword false positives by using a slightly different word. That's quite a premature and unstable intuition, but I think it's worth trying if your intuition goes in the same direction. Otherwise let's just prevent apostrophes. Thanks again, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > It looks perfect. I tested* the HTML and LaTeX backend and they do > exactly what's expected. Thanks a lot for putting this together! Applied. -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello,
Bastien writes:
> It looks perfect. I tested* the HTML and LaTeX backend and they do
> exactly what's expected. Thanks a lot for putting this together!
There is still a limitation (which was already present before the
patch), though. The regexp cannot match a radio link next to an
apostrophe, since those are considered word-constituent.
An obvious solution would be to drop the separator ("\\_<", previously
"\\<") altogether. This would allow the following construct:
<<>> some target's
This would also allow midword matching when the radio target is small
enough to be contained within a word.
<> organization
However, I'm not sure this is something desirable, but the apostrophe
problem is mildly annoying.
WDYT?
Regards,
--
Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > Here are 3 patches (for maint) fixing radio-target behaviour. It looks perfect. I tested* the HTML and LaTeX backend and they do exactly what's expected. Thanks a lot for putting this together! * With quite a complex radio link like the one in the attached file. a.org Description: Lotus Organizer -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello, Bastien writes: > Nicolas Goaziou writes: > >> For example, `org-make-target-link-regexp' generates a regexp enclosed >> within "\\<...\\>". Unfortunately, that will not match a radio link >> starting with an entity, e.g., <<<\alpha-test>>> \alpha-test. It is >> probably due to the fact that radio targets were initially meant to >> contain only plain text, not Org syntax. > > FWIW, I'd be fine to only allow plain text in radio targets, instead > of the full syntax. Your take. > >>> It's one of the last thing I want to get fixed before we release Org >>> 8.2.3. >> >> If you don't mind, I need a bit more time (around a week) for 8.2.3. In >> particular, there are speed issues in `org-element-context' that I would >> like to fix first. > > Sure -- there is absolutely no rush, and I have my own share of things > I need to fix too, so let's no hurry at all. I was mentioning 8.2.3 > because Stefan created the emacs-24 branch, which means that the move > toward Emacs 24.4 is accelerating now, but there is no deadline that > I'm aware of. Here are 3 patches (for maint) fixing radio-target behaviour. Feedback welcome. Regards, -- Nicolas Goaziou >From a55057e99d72241d039a1f8d57ced3cbb5dcb68d Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Sun, 23 Mar 2014 11:23:08 +0100 Subject: [PATCH 1/3] Change "\" and "~" syntax to symbol * lisp/org.el (org-mode): Change "\" and "~" characters syntax from `punctuation' to `symbol' so they are on par with other characters used in Org syntax (e.g., "/", "*"...). This change is needed to correctly find radio links starting with an entity: <<<\alpha-test>>> \alpha-test --- lisp/org.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 70bf19e..56ae096 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5341,6 +5341,8 @@ The following commands are available: ;; Modify a few syntax entries (modify-syntax-entry ?@ "w") (modify-syntax-entry ?\" "\"") + (modify-syntax-entry ?\\ "_") + (modify-syntax-entry ?~ "_") (if org-startup-truncated (setq truncate-lines t)) (when org-startup-indented (require 'org-indent) (org-indent-mode 1)) (org-set-local 'font-lock-unfontify-region-function -- 1.9.1 >From 2f46aae4d602402f201c8d3291a985de374d7593 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Sun, 23 Mar 2014 11:28:26 +0100 Subject: [PATCH 2/3] Fix radio target parsing * lisp/org-element.el (org-element-all-successors, org-element-object-restrictions): Prioritize `link' over other successors in order to find radio links starting with another syntax object (e.g., an entity). Also allow text markup within radio targets. (org-element-link-parser): Add contents to radio targets. * lisp/org.el (org-make-target-link-regexp): Fix regexp so it can match targets starting with an Org object (i.e., an entity). (org-ctrl-c-ctrl-c): Fix function when applied on an object contained within a radio target. * testing/lisp/test-org-element.el (test-org-element/radio-target-parser): Add test. * testing/lisp/test-ox.el (test-org-export/resolve-radio-link): Add test. --- lisp/org-element.el | 19 +++ lisp/org.el | 10 ++ testing/lisp/test-org-element.el | 15 +++ testing/lisp/test-ox.el | 9 + 4 files changed, 37 insertions(+), 16 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 9bb7944..9589714 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -187,10 +187,10 @@ is not sufficient to know if point is at a paragraph ending. See "List of recursive element types aka Greater Elements.") (defconst org-element-all-successors - '(export-snippet footnote-reference inline-babel-call inline-src-block - latex-or-entity line-break link macro plain-link radio-target - statistics-cookie sub/superscript table-cell target - text-markup timestamp) + '(link export-snippet footnote-reference inline-babel-call + inline-src-block latex-or-entity line-break macro plain-link + radio-target statistics-cookie sub/superscript table-cell target + text-markup timestamp) "Complete list of successors.") (defconst org-element-object-successor-alist @@ -328,13 +328,13 @@ Don't modify it, set `org-element-affiliated-keywords' instead.") (paragraph ,@standard-set) ;; Remove any variable object from radio target as it would ;; prevent it from being properly recognized. - (radio-target latex-or-entity sub/superscript) + (radio-target latex-or-entity sub/superscript text-markup) (strike-through ,@standard-set) (subscript ,@standard-set) (superscript ,@standard-set) ;; Ignore inline babel call and inline src block as formulas are ;; possible. Also ignore line breaks and statistics cookies. - (table-cell export-snippet footnote-reference latex-or-entity link macro + (table-cell link export-snippet footnote-reference la
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Noah Slater writes: > Or perhaps to survey what is already out there. What are people > already doing/trying to do? I opened a different thread to make the poll more prominent. -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Or perhaps to survey what is already out there. What are people already doing/trying to do? On 21 March 2014 18:28, Bastien wrote: > Hi Nicolas, > > Nicolas Goaziou writes: > > > It would probably make my life less miserable. But do radio target users > > need entities within? > > IMHO the best way to know is to open a new thread with [POLL] > and a very clear subject like > > "[POLL] Do you need special entities in radio target?" > > 2 cents, > > -- > Bastien >
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > It would probably make my life less miserable. But do radio target users > need entities within? IMHO the best way to know is to open a new thread with [POLL] and a very clear subject like "[POLL] Do you need special entities in radio target?" 2 cents, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > FWIW, I'd be fine to only allow plain text in radio targets, instead > of the full syntax. Your take. It would probably make my life less miserable. But do radio target users need entities within? Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > For example, `org-make-target-link-regexp' generates a regexp enclosed > within "\\<...\\>". Unfortunately, that will not match a radio link > starting with an entity, e.g., <<<\alpha-test>>> \alpha-test. It is > probably due to the fact that radio targets were initially meant to > contain only plain text, not Org syntax. FWIW, I'd be fine to only allow plain text in radio targets, instead of the full syntax. Your take. >> It's one of the last thing I want to get fixed before we release Org >> 8.2.3. > > If you don't mind, I need a bit more time (around a week) for 8.2.3. In > particular, there are speed issues in `org-element-context' that I would > like to fix first. Sure -- there is absolutely no rush, and I have my own share of things I need to fix too, so let's no hurry at all. I was mentioning 8.2.3 because Stefan created the emacs-24 branch, which means that the move toward Emacs 24.4 is accelerating now, but there is no deadline that I'm aware of. Thanks again, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello, Bastien writes: > Bastien writes: > >> Can you make the change (ie. radio-link is a link with a description, >> the description being its parsed path)? If so, do you want me to make >> the change in the backends or do you want to take care of this too? > > I see you reverted related commits -- are you on this? I reverted them because they introduced an infloop that I didn't have time to fix. I'm working on it, slowly. There are also a couple of problems related to radio targets that need to be fixed at the same time. For example, `org-make-target-link-regexp' generates a regexp enclosed within "\\<...\\>". Unfortunately, that will not match a radio link starting with an entity, e.g., <<<\alpha-test>>> \alpha-test. It is probably due to the fact that radio targets were initially meant to contain only plain text, not Org syntax. Anyway, I think it should be enclosed to something like "\\(?:\\W\\|^\\)..."\\(?:\\W\\|$\\)" instead. > It's one of the last thing I want to get fixed before we release Org > 8.2.3. If you don't mind, I need a bit more time (around a week) for 8.2.3. In particular, there are speed issues in `org-element-context' that I would like to fix first. Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Bastien writes: > Can you make the change (ie. radio-link is a link with a description, > the description being its parsed path)? If so, do you want me to make > the change in the backends or do you want to take care of this too? I see you reverted related commits -- are you on this? It's one of the last thing I want to get fixed before we release Org 8.2.3. Thanks in advance, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > path is always a string. Description is always parsed (and transcoded > already). In the most simple cases, they are equals. I found out I have to parse the path because "hello \alpha" would not be exported correctly otherwise. (But I agree this is a corner case.) > 5174495 adds contents to radio links (and, because of this, introduces > an infloop in `org-element-context' on master, but that's another > story). Your change parses link's contents on the fly. So this is mostly > equivalent, albeit more verbose in all exporters. Yes, I parsed the link's contents on the fly just for the purpose of this small patch, but a general solution is better. > So the question is : should we consider a radio-link as a link with > a description, which would basically be its parsed path? I think so. > I think it is > useful because its contents can differ from its relative radio-target, > due to case-insensitivity. Indeed. Can you make the change (ie. radio-link is a link with a description, the description being its parsed path)? If so, do you want me to make the change in the backends or do you want to take care of this too? Thanks, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > Bastien writes: > >> If we do this, I don't see the need to enforce case sensitivity. > > I attach a patch that illustrates the fix I propose on top on my > previous commit. I somehow missed this message. > With this, > > > <<>> > > Let's say hello \alpha world to test. > > > gets converted into > > > > Hello α world > > > > Let's say hello α world to test. > > > > which I think is what the OP expected. We preserve case sensitivity > of the target, and we preserve the link description. Indeed, downcasing value is not necessary in this case. > (I think the confusion comes from calling "path" what is really the > description when path and description are the same, like in a link > to a radio target.) path is always a string. Description is always parsed (and transcoded already). In the most simple cases, they are equals. > Let me know what you think, It could work if we revert 5174495 and b4ffae0 and propagate the changes to "ox-latex.el", "ox-beamer.el" and "ox-ascii.el". Though, there is still a problem to consider. See below. > diff --git a/lisp/ox-html.el b/lisp/ox-html.el > index 4d6180d..0cacd57 100644 > --- a/lisp/ox-html.el > +++ b/lisp/ox-html.el > @@ -2775,9 +2775,13 @@ INFO is a plist holding contextual information. See >(let ((destination (org-export-resolve-radio-link link info))) > (when destination > (format "%s" > - (org-export-data (org-element-contents destination) info) > + (org-export-solidify-link-text > +(org-export-data (org-element-contents destination) info)) It should be (org-export-solidify-link-text (org-element-property :value destination)) See `org-html-radio-target'. > - (org-export-solidify-link-text path) > + (org-export-data > +(org-element-parse-secondary-string > + path > + (org-element-restriction 'paragraph)) info) It should be: (org-element-restriction 'radio-target) Anyway, this raises a question. 5174495 adds contents to radio links (and, because of this, introduces an infloop in `org-element-context' on master, but that's another story). Your change parses link's contents on the fly. So this is mostly equivalent, albeit more verbose in all exporters. So the question is : should we consider a radio-link as a link with a description, which would basically be its parsed path? I think it is useful because its contents can differ from its relative radio-target, due to case-insensitivity. Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Nicolas Goaziou writes: > I see the capitalization problem, but I still don't understand why you > think target and description are inverted. Well, they are. Okay, again: <<>> hello world The target of the second "hello world" is "Hello World" (capitalized). The description of the second hello world is "hello world" (lower case.) With the latest maint, the second "hello world" is translated as Hello World whereas it should be hello world ^ ^ ^ ^ [target] [description] >yyy > > targets > >zzz > > In the current state (ignoring the description part), you have: > > ... > > and > > ... > > What do you think is wrong here? If the radio link is "Hello World", the target should be #Hello-World. We can decide to lower case all targets, but it is not necessary with the fix I propose. -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > Nicolas Goaziou writes: > >> >> Hello World >> >> >> >> Let’s say Hello World to test. >> >> It looks good to me. > > The target is the radio link: "Hello World". > > The link description in the second paragraph is "hello world". > > So the output is not good: > > 1) Hello World should be >Hello World > ^ ^ > > 2) Hello World should be >hello world > ^ ^ ^ ^ > > See the difference with the result you get after applying > the patch I just sent on top of d2e7b1b5. I see the capitalization problem, but I still don't understand why you think target and description are inverted. yyy targets zzz In the current state (ignoring the description part), you have: ... and ... What do you think is wrong here? Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Nicolas Goaziou writes: > > Hello World > > > > Let’s say Hello World to test. > > It looks good to me. The target is the radio link: "Hello World". The link description in the second paragraph is "hello world". So the output is not good: 1) Hello World should be Hello World ^ ^ 2) Hello World should be hello world ^ ^ ^ ^ See the difference with the result you get after applying the patch I just sent on top of d2e7b1b5. -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > I don't get the logic: the output text has two parts: the target of > the link, the description of the link. It the example above, the > Target is "Hello World", and should be rewritten "Hello-World" to > escape spaces. The description is "hello world" and should not be > rewritten, it must appears the same way to the user. Actually, the target is "hello-world". On latest "maint", with your example, I get: --8<---cut here---start->8--- Hello World Let’s say Hello World to test. --8<---cut here---end--->8--- It looks good to me. >> Anyway, I think the solution is to slightly change the parser to enforce >> case-insensitivity. > > I thought about this, but it does not solve the problem of displaying > the target instead of the link description. I cannot reproduce this problem. Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes:
> If we do this, I don't see the need to enforce case sensitivity.
I attach a patch that illustrates the fix I propose on top on my
previous commit.
With this,
<<>>
Let's say hello \alpha world to test.
gets converted into
Hello α world
Let's say hello α world to test.
which I think is what the OP expected. We preserve case sensitivity
of the target, and we preserve the link description.
(I think the confusion comes from calling "path" what is really the
description when path and description are the same, like in a link
to a radio target.)
Let me know what you think,
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 4d6180d..0cacd57 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2775,9 +2775,13 @@ INFO is a plist holding contextual information. See
(let ((destination (org-export-resolve-radio-link link info)))
(when destination
(format "%s"
- (org-export-data (org-element-contents destination) info)
+ (org-export-solidify-link-text
+ (org-export-data (org-element-contents destination) info))
attributes
- (org-export-solidify-link-text path)
+ (org-export-data
+ (org-element-parse-secondary-string
+ path
+ (org-element-restriction 'paragraph)) info)
;; Links pointing to a headline: Find destination and build
;; appropriate referencing command.
((member type '("custom-id" "fuzzy" "id"))
--
Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, thanks for looking into this. Nicolas Goaziou writes: > Actually, even though it works if you test it on cases like: > > <<>> foo > > it isn't right on more complex cases: > > <<>> with \alpha True. It is not right on simpler example too, with just spaces: <<>> Let's say hello world to test. It produces Hello World Let's say hello-world to test. > As you can see, the logic is right in ox-latex.el, ox-html.el and > ox-beamer.el. I don't get the logic: the output text has two parts: the target of the link, the description of the link. It the example above, the Target is "Hello World", and should be rewritten "Hello-World" to escape spaces. The description is "hello world" and should not be rewritten, it must appears the same way to the user. > Anyway, I think the solution is to slightly change the parser to enforce > case-insensitivity. I thought about this, but it does not solve the problem of displaying the target instead of the link description. > Some additional properties need to be added in order > to preserve original contents of both radio links and radio targets. > > I pushed such a change. Is it working as expected? Not for me: when "a word" is linked to a radio target, I expect to see "a word" in the output, linked to a #a-word id. When "another word" is linked to "Another Word", I expect to see "another word" in the output, linking to an anchor #Another-Word. If we do this, I don't see the need to enforce case sensitivity. -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello, Bastien writes: > Nicolas, I modified the logic for radio link export in ox-html.el, > ox-latex.el and ox-beamer.el. I also modified the use of the target > instead of the path in ox-ascii.el. Can you review this change > (http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=d2e7b1b) and > confirm it does the right thing? Actually, even though it works if you test it on cases like: <<>> foo it isn't right on more complex cases: <<>> with \alpha As you can see, the logic is right in ox-latex.el, ox-html.el and ox-beamer.el. Anyway, I think the solution is to slightly change the parser to enforce case-insensitivity. Some additional properties need to be added in order to preserve original contents of both radio links and radio targets. I pushed such a change. Is it working as expected? Regards, -- Nicolas Goaziou
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Noah, Noah Slater writes: > Experiencing a bug with radio targets and html export. > > IF set a radio target like <<> then the text foo in the body > will be linked to #foo, but the radio target has an anchor id of Foo, > so the link doesn't work. > > I expected the foo text to be linked to #Foo instead. Indeed. This is now fixed in maint, please confirm when you have a moment. Nicolas, I modified the logic for radio link export in ox-html.el, ox-latex.el and ox-beamer.el. I also modified the use of the target instead of the path in ox-ascii.el. Can you review this change (http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=d2e7b1b) and confirm it does the right thing? Thanks, -- Bastien
[O] Radio targets with mixed capitalisation do not work in HTML export
Experiencing a bug with radio targets and html export. IF set a radio target like <<> then the text foo in the body will be linked to #foo, but the radio target has an anchor id of Foo, so the link doesn't work. I expected the foo text to be linked to #Foo instead.
Re: [O] Radio targets in comment lines
Steen Hoyer writes: > Thank you Nicolas! I will think about a patch for the FAQ. I don't quite > understand one of your comments: > >> There is no point in making radio targets invisible. > > I think that invisible radio targets are precisely what I want - > that's why I made so many of them in comments under the old system. Am > I missing something? I've tried putting the radio targets in > a :LOGBOOK:, which works fine in Emacs, but not after export. Perhaps > I should use some other type of non-exported drawer? > > For what it is worth, I am trying to able to paste text from academic papers > (with multiple possible citation styles) and have links to notes elsewhere in > the file appear automatically. > > * Author Year > <<>> > <<>> > > I am not using the radio targets in a sentence and therefore I don't > want them to be visible. I could use <> to make > an invisible target (or use a custom ID), but then to link I would > need [[Author et al., Year]], instead of simply Author et al., Year. > Does this make sense, is there some workaround I'm missing, or should > I give up on this clumsy system? I'm not sure to understand. With this method, you're just creating broken links since the source (the radio target) will be removed upon exporting. All these links will have no destination. If you just want the links when writing the document and have them turned into plain text when exporting the document, you can simply delete the radio targets using a function within `org-export-before-processing-hook'. Regards, -- Nicolas Goaziou
Re: [O] Radio targets in comment lines
Thank you Nicolas! I will think about a patch for the FAQ. I don't quite understand one of your comments: > There is no point in making radio targets invisible. I think that invisible radio targets are precisely what I want - that's why I made so many of them in comments under the old system. Am I missing something? I've tried putting the radio targets in a :LOGBOOK:, which works fine in Emacs, but not after export. Perhaps I should use some other type of non-exported drawer? For what it is worth, I am trying to able to paste text from academic papers (with multiple possible citation styles) and have links to notes elsewhere in the file appear automatically. * Author Year <<>> <<>> I am not using the radio targets in a sentence and therefore I don't want them to be visible. I could use <> to make an invisible target (or use a custom ID), but then to link I would need [[Author et al., Year]], instead of simply Author et al., Year. Does this make sense, is there some workaround I'm missing, or should I give up on this clumsy system? Best, Steen
Re: [O] Radio targets in comment lines
Hello, Steen Hoyer writes: > Org 8 seems to have changed the way radio links in comment lines work. > > # <<>> No longer creates a link - 'C-c C-c can do nothing useful at > this location' > > #+test <<>> Works within org for some reason, but then the line will > be exported... > > I was curious if this was intentional, This is intentional. No Org syntax is recognized in a comment anymore. On the other hand, all targets (not radio targets) are invisible now. Therefore, you can write: Some text<> in a paragraph. And "invisible" (note the double brackets) will not appear during export. "#+test <<>>" has wrong syntax since the colons are mandatory: "#+test: <<>>". It will not be exported (as a keyword), but it cannot hold radio targets (or targets) either. > because I have many (now broken) links of the first kind in my org > files, and because of this line in the org FAQ: "The usual way of > turning radio links invisible is to comment them," FAQ is not up-to-date. Also, note that there is a confusion between targets (double brackets) and radio targets (triple brackets). There is no point in making radio targets invisible. There is also no need for the (INVISIBLE) hack anymore. Patches welcome wrt the FAQ. Regards, -- Nicolas Goaziou
[O] Radio targets in comment lines
Org 8 seems to have changed the way radio links in comment lines work. # <<>> No longer creates a link - 'C-c C-c can do nothing useful at this location' #+test <<>> Works within org for some reason, but then the line will be exported... I was curious if this was intentional, because I have many (now broken) links of the first kind in my org files, and because of this line in the org FAQ: "The usual way of turning radio links invisible is to comment them," Best wishes, Steen
