On the Org side, when a link like [[something]] or [[something][text]]
is encountered in a buffer, the search would go on like this:
1. Search any something or #+target: something[1].
1. A link to an invisible target will be replaced with _nothing_
(that's the point of being
Hello,
Here is a new version of the patch built on top of master, along with
test cases.
If there is no objection, I'll push it to master in a couple of days.
I really think that's a great feature to have in Org.
Regards,
--
Nicolas Goaziou
From 2fdde87bb7f1241f3d24dbd8ae030a300fe8f0fc Mon
At Tue, 21 Feb 2012 10:18:00 +0100,
Nicolas Goaziou wrote:
Hello,
David Maus dm...@ictsoc.de writes:
I don't see why we should drop the link type in fuzzy links. After all
they /are/ are special type of link.
There is no link type in fuzzy links : [[something]] matches
something in
Hello,
David Maus dm...@ictsoc.de writes:
I don't see why we should drop the link type in fuzzy links. After all
they /are/ are special type of link.
There is no link type in fuzzy links : [[something]] matches
something in master.
Without the link type we will run into trouble, won't we?.
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
On Feb 20, 2012, at 1:51 AM, Nicolas Goaziou wrote:
There are still a few limitations. For example, you cannot reference
a precise list item since items do not accept affiliated keywords.
Ah, yes, this is right.
Thinking about it,
Completing myself, here is a patch implementing the previous suggestion,
along with example output obtained with it. You may need to
(fmakunbound 'org-e-ascii-target) to avoid an error, since this patch
removes the function.
First, the test buffer.
#+begin_src org
#+TITLE: Cross-references
Nice!
Nicolas Goaziou n.goaz...@gmail.com writes:
Completing myself, here is a patch implementing the previous suggestion,
along with example output obtained with it. You may need to
(fmakunbound 'org-e-ascii-target) to avoid an error, since this patch
removes the function.
First, the
At Mon, 20 Feb 2012 23:06:32 +0100,
Nicolas Goaziou wrote:
Completing myself, here is a patch implementing the previous suggestion,
along with example output obtained with it. You may need to
(fmakunbound 'org-e-ascii-target) to avoid an error, since this patch
removes the function.
I don't
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]]
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
I think it's a good idea, and would suggest this:
* If it is not going to have features added, then [[ref:asdf]] is OK
* If it /is/ going to have features added, then I recommend ES/US
ES/US is extensible syntax / universal syntax, a specific proposal for
an orthogonal and future-proof
Hello,
Christian Moe m...@christianmoe.com writes:
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
Hello,
Samuel Wales samolog...@gmail.com writes:
I think it's a good idea, and would suggest this:
* If it is not going to have features added, then [[ref:asdf]] is OK
* If it /is/ going to have features added, then I recommend ES/US
ES/US is extensible syntax / universal syntax, a
On 19.2.2012, at 19:08, 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
On Sun, Feb 19, 2012 at 08:41:45PM +0100, Nicolas Goaziou wrote:
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
On 2/19/12 8:41 PM, Nicolas Goaziou wrote:
That's another possibility, but I'd rather follow LaTeX usage. I think
it gives user more latitude in the end. Indeed, You don't have to think
about a name prefix ; you can also have constructs like Tables
[[ref:table1]], [[ref:table2]] and
On 2012-02-19, Nicolas Goaziou n.goaz...@gmail.com wrote:
Ok, I found the thread[1] about extensible syntax for links.
Again this isn't just for links and if your syntax does all you ever
anticipate, then I like it. I am talking about the future and the
difficulty of adding ad-hoc syntax fore
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
Why are you saying it is not a full replacement for \ref{something}?
There are still a few limitations. For example, you cannot reference
a precise list item since items do not accept affiliated keywords.
It is better than that because
On Feb 20, 2012, at 1:51 AM, Nicolas Goaziou wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
Why are you saying it is not a full replacement for \ref{something}?
There are still a few limitations. For example, you cannot reference
a precise list item since items do not
19 matches
Mail list logo
