Hi, Org people. I'm not sure I'm using "# <<tag>>" correctly, but my feeling is that it should stick to the following text in various Org operations. Let's say I have something like (as I think it): --8<---------------cut here---------------start------------->8--- * Some container # <<tag1>> * Title 1 # <<tag2>> * Title 2 --8<---------------cut here---------------end--------------->8--- If I put # <<tag1>> after "Title 1", say, the generated HTML is such that using URL#tag1 will position the browser window to the first line after "Title 1". Putting it before yields what I expect, that is, the browser jumps to "Title 1". However, Org interpret the above as: --8<---------------cut here---------------start------------->8--- * Some container # <<tag1>> * Title 1 # <<tag2>> * Title 2 --8<---------------cut here---------------end--------------->8--- putting the # <<tag2>> as a line within the "Title 1" header. If I later use
Hello,
François Pinard <pinard@iro.umontreal.ca> writes:
> I'm not sure I'm using "# <<tag>>" correctly, but my feeling is that it
> should stick to the following text in various Org operations. Let's say
> I have something like (as I think it):
"# <<tag>>" is a deprecated construct. I suggest to avoid bothering with
it.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes: > "# <<tag>>" is a deprecated construct. Sigh! I just spent a few hours adding many of those and making sure everything is regular. When some feature is being deprecated, the Org manual should tell us, then ! :-) And at least where that feature is documented. Currently, the manual says: The preferred match for a text link is a dedicated target: the same string in double angular brackets. This is not ultra clear to me, my English is not ultra solid either. I interpreted it as meaning that the preferred way for a text link was such "# <<tag>>" constructs, that is, all the contrary of a deprecation. > I suggest to avoid bothering with it. I'll adapt of course, but to what? If not "# <<tag>>", then what is the way to create a named anchor at an arbitrary place in an Org file? Explicit HTML code? That does not look at all like an improvement: 1. it would be limited to HTML, 2. Org will not likely not follow links to these from within Emacs, 3. if explicit HTML is introduced through specialized Org comments, they suffer exactly from the edit problem "# <<tag>>" demonstrated, being tied to the preceding text instead of the following text. So, Nicolas, I would surely avoid bothering with this problem, but I do not feel I have that choice (yet). I hope the letter I wrote at the beginning of this little thread is not going to be dismissed or ignored. François
Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> François Pinard <pinard@iro.umontreal.ca> writes:
>
> > I'm not sure I'm using "# <<tag>>" correctly, but my feeling is that it
> > should stick to the following text in various Org operations. Let's say
> > I have something like (as I think it):
>
> "# <<tag>>" is a deprecated construct. I suggest to avoid bothering with
> it.
>
>
With all due respect, that is not a satisfactory answer. I, for one (or
for two: François would surely appreciate it too), would appreciate a
pointer to the deprecation notice (I don't remember seeing one but that
doesn't mean much), and a pointer (if different) to whatever construct
is supposed to replace it.
Thanks,
Nick
François Pinard <pinard@iro.umontreal.ca> writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: >> I suggest to avoid bothering with it. > I hope the letter I wrote at the beginning of this little thread is > not going to be dismissed or ignored. Well, my original message accidentally left my machine before it was finished. I completed it and resent it, but the corrected message did not show in the mailing list. I guess the Message ID was the same, enough a reason for silent reject. I put a copy of the original message here: http://pinard.progiciels-bpi.ca/notes/Org.html#2012-05-06 François
Nick Dokos <nicholas.dokos@hp.com> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>> Hello,
>>
>> François Pinard <pinard@iro.umontreal.ca> writes:
>>
>> > I'm not sure I'm using "# <<tag>>" correctly, but my feeling is that it
>> > should stick to the following text in various Org operations. Let's say
>> > I have something like (as I think it):
>>
>> "# <<tag>>" is a deprecated construct. I suggest to avoid bothering with
>> it.
>>
>>
>
> With all due respect, that is not a satisfactory answer. I, for one (or
> for two: François would surely appreciate it too), would appreciate a
> pointer to the deprecation notice (I don't remember seeing one but that
> doesn't mean much), and a pointer (if different) to whatever construct
> is supposed to replace it.
>
> Thanks,
> Nick
>
Isn't the deprecation the need to put the <<xxx>> in a comment (i.e. #)?
The angle bracket syntax remains, I thought.
But maybe I also am confused as to the current direction this is
taking...
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org release_7.8.09-529-g035ab3.dirty
l use that construct extensively and look forward to the clarification. Yours, Christian --- Sent from mobile. Please excuse my brevity.
Hello, François Pinard <pinard@iro.umontreal.ca> writes: > When some feature is being deprecated, the Org manual should tell us, > then ! :-) And at least where that feature is documented. Currently, > the manual says: > > The preferred match for a text link is a dedicated target: the same > string in double angular brackets. This is correct. I was just pointing out (though, admittedly, not very clearly) that the final part of the next sentence in the manual, "sometimes it is convenient to put them into a comment line", isn't. As I announced a few times already, targets are going to change a bit and _commented_ targets will not be possible anymore in the new exporter. On the other hand, every regular target will be invisible. Let me explain. At the moment, "<<tag>>" and "# <<tag>>" produce, respectively, "<a name="tag" id="tag">tag</a>" and "<a name="tag" id="tag"></a>". In a not so distant future "<<tag>>" will produce "<a name="tag" id="tag"></a>" and "# <<tag>>" will be ignored. > I'll adapt of course, but to what? If not "# <<tag>>", then what is > the way to create a named anchor at an arbitrary place in an Org file? <<tag>> should suffice for that task. I hope this is clearer now. Regards, -- Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes:
[...]
> On the other hand, every regular target will be invisible. Let me
> explain.
>
> At the moment, "<<tag>>" and "# <<tag>>" produce, respectively, "<a
> name="tag" id="tag">tag</a>" and "<a name="tag" id="tag"></a>".
>
> In a not so distant future "<<tag>>" will produce "<a name="tag"
> id="tag"></a>" and "# <<tag>>" will be ignored.
And I think this is indeed the right way to go. Cleaner overall.
Thanks,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org release_7.8.09-529-g035ab3.dirty
Nicolas Goaziou <n.goaziou@gmail.com> writes: > This is correct. I was just pointing out (though, admittedly, not very > clearly) that the final part of the next sentence in the manual, > "sometimes it is convenient to put them into a comment line", isn't. It might be worth making the manual clear, so users know what's happening, and what is worth pursuing and avoiding. > At the moment, "<<tag>>" and "# <<tag>>" produce, respectively, "<a > name="tag" id="tag">tag</a>" and "<a name="tag" id="tag"></a>". > In a not so distant future "<<tag>>" will produce "<a name="tag" > id="tag"></a>" and "# <<tag>>" will be ignored. And one will be able to use <<tag>> anywhere, would it be at the beginning of a header of sentence. That would solve all my problems! So I'm eagerly awaiting for that "a not so distant future" to turn into "a recent past" :-). Thanks for the clarification. > I hope this is clearer now. In this message, yes. In the manual, not yet! François
Hi all,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> But maybe I also am confused as to the current direction this is
> taking...
let me try to summarize and clarify. Nicolas said it clearly:
At the moment, "<<tag>>" and "# <<tag>>" produce, respectively,
"<a name="tag" id="tag">tag</a>" and "<a name="tag" id="tag"></a>".
Nothing is deprecated _yet_ and there is no need for a notice or an
update of the manual to this regard. Quoting Nicolas again:
In a not so distant future "<<tag>>" will produce "<a name="tag"
id="tag"></a>" and "# <<tag>>" will be ignored.
So this *will* be deprecated when the new exporter will be part of
Org's core. We will update the manual by then.
Nicolas lives in the future because he's so much into the new exporter,
so that's why he said this *is* deprecated, but this isn't really yet.
Please keep testing the new exporters -- all contributions in this area
help a lot with the development!
Thanks,
--
Bastien
Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Hello, > > François Pinard <pinard@iro.umontreal.ca> writes: > > > When some feature is being deprecated, the Org manual should tell us, > > then ! :-) And at least where that feature is documented. Currently, > > the manual says: > > > > The preferred match for a text link is a dedicated target: the same > > string in double angular brackets. > > This is correct. I was just pointing out (though, admittedly, not very > clearly) that the final part of the next sentence in the manual, > "sometimes it is convenient to put them into a comment line", isn't. > > As I announced a few times already, targets are going to change a bit > and _commented_ targets will not be possible anymore in the new > exporter. > Sorry I missed it and thanks for the clarification. Nick > On the other hand, every regular target will be invisible. Let me > explain. > > At the moment, "<<tag>>" and "# <<tag>>" produce, respectively, "<a > name="tag" id="tag">tag</a>" and "<a name="tag" id="tag"></a>". > > In a not so distant future "<<tag>>" will produce "<a name="tag" > id="tag"></a>" and "# <<tag>>" will be ignored. > > > I'll adapt of course, but to what? If not "# <<tag>>", then what is > > the way to create a named anchor at an arbitrary place in an Org file? > > <<tag>> should suffice for that task. > > I hope this is clearer now. > > > Regards, > > -- > Nicolas Goaziou >