Hi,
I think it's a great idea, as I've wanted to do it myself :-) , but
I'm glad it's in competent hands instead.
Me, I don't see any problem with a [[ref:something]] syntax. It's the
obvious org-native, cross-backend replacement for \ref. The
[[protocol:something]] syntax already widens the notion of link to
shell: and elisp: links, so I wouldn't worry about breaking
conventions. Using e.g. [[!something]] instead would introduce a brand
new bit of syntax.
Suggestion: On export, how about enabling automatic element
descriptions for references following the type:name convention, so
that e.g. just
: in [[ref:tab:numbers]] we can see...
would expand to
in Table 2 we can see...
If implemented, this should be user-customizable e.g. through an alist
like
(("fig" . "Figure") ("tab" . "Table") ("map" . "Map"))
Yours,
Christian
On 2/19/12 7:08 PM, Nicolas Goaziou wrote:
Hello,
I'd like to introduce a new type of internal links, namely "ref" links.
Since any element can now have a "#+name: something" affiliated keyword,
it would be practical to have a way to go straight to that name, from
anywhere in the buffer. The following patch implements
a [[ref:something]] syntax, or even [[ref:something][text]] to do so.
The problem that I see here is that is breaks a bit syntax for internal
links ("protocol:path" is usually for external links). Another solution
would be to make them more hermetic: [[!something]].
On the export side, a "ref" link should be replaced by its description,
if it has any, or by the sequence number of the matching element among
elements of the same type. With the new exporter and the following
buffer:
#+begin_src org
#+name: tab:letters
#+caption: Letters
| a | b |
| c | d |
#+name: tab:numbers
#+caption: Numbers
| 1 |
| 2 |
In tableau [[ref:tab:numbers]] we can see... Yet, in
[[ref:tab:numbers][the same table]], ...
#+end_src
the last sentence, in ascii, becomes:
In tableau 2 we can see... Yet, in the same table, ...
Even if it's not a perfect replacement for "\ref{something}" commands,
it should be sufficient for all major back-ends to provide an
approximate functionality. And we gain interactivity in the Org buffer.
What do you think?
Regards,
