From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Radio targets with mixed capitalisation do not work in HTML export Date: Mon, 17 Mar 2014 15:27:44 +0100 Message-ID: <87vbvcq4rj.fsf@gmail.com> References: <874n2xlgzx.fsf@bzg.ath.cx> <87eh21qgmh.fsf@gmail.com> <87d2hlhxm2.fsf@bzg.ath.cx> <87zjkpghff.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPYVe-0005re-Nw for emacs-orgmode@gnu.org; Mon, 17 Mar 2014 10:27:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPYVZ-0006qY-DC for emacs-orgmode@gnu.org; Mon, 17 Mar 2014 10:27:22 -0400 In-Reply-To: <87zjkpghff.fsf@bzg.ath.cx> (Bastien's message of "Mon, 17 Mar 2014 13:04:20 +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: Bastien Cc: Noah Slater , emacs-orgmode@gnu.org Bastien writes: > Bastien 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, > > ======================================================================== > <<>> > > Let's say hello \alpha world to test. > ======================================================================== > > gets converted into > > ======================================================================== >

> Hello α world >

> >

> Let's say hello α world to test. >

> ======================================================================== > > 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 "%s" > - (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