hi. experimenting [after significant confusion!], it appears that including a single (unpaired) double quote inside an anonymous footnote eliminates the recognition of the footnote. is this intentional? this works: ---- this is a test.[fn:: a very long footnote] ---- whereas this doesn't: ---- this is a test.[fn:: "a very long footnote] ---- i notice that for purposes of exporting, i can have the single double quote accepted by escaping it with a backslash: ---- this is a test.[fn:: \"a very long footnote] ---- but, - the backslash itself shows up in both latex and html exporting - the footnote doesn't get displayed in the org buffer as a footnote (the separate colors; this is "font locking"?) Org mode version 9.5.2 (9.5.2-gbb6830 @ /home/minshall/.emacs.d/straight/build/org/) cheers, Greg
Hi Greg,
Greg Minshall writes:
> hi. experimenting [after significant confusion!], it appears that
> including a single (unpaired) double quote inside an anonymous footnote
> eliminates the recognition of the footnote. is this intentional?
>
> this works:
> ----
> this is a test.[fn:: a very long footnote]
> ----
>
> whereas this doesn't:
> ----
> this is a test.[fn:: "a very long footnote]
> ----
>
> i notice that for purposes of exporting, i can have the single double
> quote accepted by escaping it with a backslash:
> ----
> this is a test.[fn:: \"a very long footnote]
> ----
> but,
> - the backslash itself shows up in both latex and html exporting
> - the footnote doesn't get displayed in the org buffer as a footnote
> (the separate colors; this is "font locking"?)
>
> Org mode version 9.5.2 (9.5.2-gbb6830 @ /home/minshall/.emacs.d/straight/build/org/)
I can confirm that behavior. One possible solution is to use an entity
(M-x org-entities-help):
this is a test.[fn:: \quot{}a very long footnote]
Best regards,
Juan Manuel
Juan Manuel,
> I can confirm that behavior. One possible solution is to use an entity
> (M-x org-entities-help):
thanks very much -- that does the trick for my case.
cheers, Greg
Greg Minshall writes:
> Juan Manuel,
>
>> I can confirm that behavior. One possible solution is to use an entity
>> (M-x org-entities-help):
>
> thanks very much -- that does the trick for my case.
In any case, I don't know if that behavior should be considered a bug. I
say this because other constructions with an unbalanced element,
although org does not fontify them well, they are exported correctly:
this is a test[fn::(this is an inline footnote]
this is a test[fn::{this is an inline footnote]
== LaTeX ==>
this is a test\footnote{(this is an inline footnote}
this is a test\footnote{\{this is an inline footnote}
Instead, if you do <M-: (org-element-context)> on your example,
org-element-context doesn't recognize this as a footnote reference:
this is a test[fn::"this is an inline footnote]
Looking at `org-element-footnote-reference-parser', I'd say the problem
is with:
...
(with-syntax-table org-element--pair-square-table
(ignore-errors (scan-lists (point) 1 0)))
...
If there is an unbalanced double quote inside a bracket construction,
that expression returns nil and not the position after the final
bracket. But I don't know how to go on :-(.
Best regards,
Juan Manuel
Hello, Juan Manuel Macías <maciaschain@posteo.net> writes: > Greg Minshall writes: > In any case, I don't know if that behavior should be considered a bug. I > say this because other constructions with an unbalanced element, > although org does not fontify them well, they are exported correctly: > > this is a test[fn::(this is an inline footnote] > > this is a test[fn::{this is an inline footnote] > > == LaTeX ==> > > this is a test\footnote{(this is an inline footnote} > > this is a test\footnote{\{this is an inline footnote} > > Instead, if you do <M-: (org-element-context)> on your example, > org-element-context doesn't recognize this as a footnote reference: > > this is a test[fn::"this is an inline footnote] > > Looking at `org-element-footnote-reference-parser', I'd say the problem > is with: > > ... > (with-syntax-table org-element--pair-square-table > (ignore-errors (scan-lists (point) 1 0))) > ... > > If there is an unbalanced double quote inside a bracket construction, > that expression returns nil and not the position after the final > bracket. But I don't know how to go on :-(. I think I fixed it in bugfix branch. Thanks. Regards, -- Nicolas Goaziou
Nicolas and Juan Manuel, thanks very much. the bugfix branch seems to work for my case. cheers, Greg
Hi Greg and Nicolas,
Greg Minshall writes:
> Nicolas and Juan Manuel,
>
> thanks very much. the bugfix branch seems to work for my case.
Thank you very much Nicolas. In my case it also works fine.
Best regards,
Juan Manuel