Re: Radio targets with mixed capitalisation do not work in HTML export

[Nicolas Goaziou <n.goaziou@gmail.com>]

Bastien <bzg@gnu.org> writes:

> Bastien <bzg@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 &alpha; world</a>
> </p>
>
> <p>
> Let's say <a href="#Hello-alpha-world">hello &alpha; 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