Hi Nicolas, thanks for looking into this.
Nicolas Goaziou <n.goaz...@gmail.com> writes: > Actually, even though it works if you test it on cases like: > > <<<Foo>>> foo > > it isn't right on more complex cases: > > <<<with \alpha>>> with \alpha True. It is not right on simpler example too, with just spaces: ======================================================================== <<<Hello World>>> Let's say hello world to test. ======================================================================== It produces ======================================================================== <p> <a id="Hello-World">Hello World</a> </p> <p> Let's say <a href="#Hello World">hello-world</a> to test. </p> ======================================================================== > 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