> 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 "<>" or "#+target: something"[1].
> 1. A link to an invisible target will be replaced with _nothing_
>(that's the point of being
At Tue, 21 Feb 2012 10:18:00 +0100,
Nicolas Goaziou wrote:
>
> Hello,
>
> David Maus 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
> <> in master.
>
> >
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 S
Hello,
David Maus 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
<> in master.
> Without the link type we will run into trouble, won't we?.
>
> In the example f
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 d
Nice!
Nicolas Goaziou 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 test buffer.
>
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
#+L
Hello,
Carsten Dominik 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, there may exist a bet
On Feb 20, 2012, at 1:51 AM, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik 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 affiliate
Hello,
Carsten Dominik 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 it will work in more ba
On 2012-02-19, Nicolas Goaziou 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 new features /later/
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 [[ref:table
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
> >
> >
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
Hello,
Samuel Wales 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 specific proposal
Hello,
Christian Moe 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 about breaking
>
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 syntax
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
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]]
19 matches
Mail list logo
