From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Radio targets with mixed capitalisation do not work in HTML export Date: Mon, 17 Mar 2014 12:29:25 +0100 Message-ID: <87d2hlhxm2.fsf@bzg.ath.cx> References: <874n2xlgzx.fsf@bzg.ath.cx> <87eh21qgmh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPVje-0004ar-HD for emacs-orgmode@gnu.org; Mon, 17 Mar 2014 07:29:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPVjW-00006Y-D6 for emacs-orgmode@gnu.org; Mon, 17 Mar 2014 07:29:38 -0400 Received: from rs249.mailgun.us ([209.61.151.249]:58407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPVjW-00006Q-6b for emacs-orgmode@gnu.org; Mon, 17 Mar 2014 07:29:30 -0400 In-Reply-To: <87eh21qgmh.fsf@gmail.com> (Nicolas Goaziou's message of "Mon, 17 Mar 2014 11:11:34 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Noah Slater , emacs-orgmode@gnu.org 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