Re: [O] Target and link text normalised to `orgtargetn'

[Nicolas Goaziou]

Hello,

Suvayu Ali <address@hidden> writes:

> Sorry, I don't think I quite understand.  AFAIU, targets like
> <<interesting>> have to be unique even inside the Org buffer for links
> like this to work: [[interesting][very cool]], regardless of export.  So
> then why rename them during export?

There's no guarantee that, e.g., \label{interesting} is a valid syntax.
Think about <<100%>> for LaTeX. Actually such links were broken for
non-ASCII characters before the patch.

Note that this is transparent for the user: if <<interesting>> becomes
\label{foo}, [[interesting][very cool]] automatically becomes
\hyperref[foo]{very cool}.

Your problem is different AFAIU. You are relying on the internal pattern
of generated labels, i.e., you are eating Org's dog food. I advise
against it.

If you need explicitly "\label{interesting}", ask Org to write it with,
e.g., "@@latex:\label{foo}@@" or even better

#+MACRO: lbl @@latex:\label{$1}@@

  {{{lbl(foo)}}}

> How does the above solve the issue?  I was not having problems with
> getting to export \label{foo}, my problem was what do I put as `foo'
> since in the exported TeX file foo was different.
>
> Hopefully I made myself clear, or I'm not misunderstanding something.

Again <<target>> are for [[target]], \label{...} are for
\whateverref{..}. IOW, you are mixing two different concepts. Since you
write "\secref{fig:1}" in your documents, you can also write
"\label{fig:1}" there.

Org can only ensures you that [[target]] always point to <<target>>. No
more, no less.

There is another data point to consider: internal label scheme must not
follow a simple pattern, as a user might use the same and introduce
a label collision. E.g., if <<foo>> becomes par:foo, the following
line is problematic:

  <<foo>> \label{par:foo} \ref{par:foo} [[foo]]

This is why I suggest to rever commit cf7d64f. It also introduces
a non-alphanumeric character ":", even though `org-export-get-reference'
uses only alphanumeric ones by portability concern (it is even specified
in its docstring).

Commit f1548e1 is different. I actually mostly agree with it (though
I was confused at first with the docstring change, which needs to be
fixed), but it breaks radio targets. It doesn't need to be reverted.


Regards,

-- 
Nicolas Goaziou