Bastien <b...@gnu.org> writes: > Bastien <b...@gnu.org> 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, > > ======================================================================== > <<<Hello \alpha world>>> > > Let's say hello \alpha world to test. > ======================================================================== > > gets converted into > > ======================================================================== > <p> > <a id="Hello-alpha-world">Hello α world</a> > </p> > > <p> > Let's say <a href="#Hello-alpha-world">hello α world</a> to test. > </p> > ======================================================================== > > 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 "<a href=\"#%s\"%s>%s</a>" > - (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
