Gregor Zattler writes:
>> Note that there is generally no guarantee that [[name]] link will be
>> exported as "name" by any particular backend. Your workaround with
>> num:nil is just a workaround that may or may not work in future.
> ...
> actually this workaround does /not/ work
> around if [li
Hi Ihor, Rudolf,
* Ihor Radchenko [2023-10-14; 09:01 GMT]:
> Rudolf Adamkovič writes:
>
>>> What about [[Link][link]]?
>>
>> That makes Org documents hard to read in *plain text*, that is without
>> the "descriptive links" fontification. Here is my note again, compare:
>>
>> EXAMPLE 1: Hard-to-r
Ihor Radchenko writes:
> What you want is very hard to implement in Org mode for all the backends
> - the export API, when querying a link target, returns that target as
> AST element. Individual backends then decide what to do with that target
> in order to extract the actual exported link text.
Rudolf Adamkovič writes:
> Actually, dang! I spoke too soon. While links now work consistently
> before and after exports, their description matches the destination
> heading, not the source link. But if we case-fold now, it would make a
> lot more sense to match the case of the source link, a
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> [...] loading happens before Emacs loads file-local variables. This is
>> by major mode design and we cannot do much about this. See
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
>
> I see. So, that is by design of Emacs, and Org h
Ihor Radchenko writes:
> [...] loading happens before Emacs loads file-local variables. This is
> by major mode design and we cannot do much about this. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
I see. So, that is by design of Emacs, and Org has no built-in
mechanism, akin to th
Rudolf Adamkovič writes:
>>> [...] call to 'org-toggle-link-display' does nothing.
>
>> It does nothing because it is one of the options that must be set before
>> Org mode is loaded. Resolving buffer-local variables happens after the
>> major mode is loaded.
>
> I have noticed that 'org-use-extr
Ihor Radchenko writes:
>>> Note that there is generally no guarantee that [[name]] link will be
>>> exported as "name" by any particular backend. Your workaround with
>>> num:nil is just a workaround that may or may not work in future.
>>
>> I did not know this is considered a workaround! I have
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> Note that there is generally no guarantee that [[name]] link will be
>> exported as "name" by any particular backend. Your workaround with
>> num:nil is just a workaround that may or may not work in future.
>
> I did not know this is conside
Ihor Radchenko writes:
> Note that there is generally no guarantee that [[name]] link will be
> exported as "name" by any particular backend. Your workaround with
> num:nil is just a workaround that may or may not work in future.
I did not know this is considered a workaround! I have always tho
Rudolf Adamkovič writes:
>> What about [[Link][link]]?
>
> That makes Org documents hard to read in *plain text*, that is without
> the "descriptive links" fontification. Here is my note again, compare:
>
> EXAMPLE 1: Hard-to-read, unhelpful markup:
>
> The set of [[Cellular membrane][cellular
Ihor Radchenko writes:
>> For context, I use '#+OPTIONS: num:nil', which means that '[[link]]'
>> exports as 'link' and not a section number.
>
> I am confused. num:nil just means that section titles will not be
> numbered. It has nothing to do with links, AFAIK.
My sentence says it all, but if
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> You might as well use [[Link]].
>
> For context, I use '#+OPTIONS: num:nil', which means that '[[link]]'
> exports as 'link' and not a section number.
I am confused. num:nil just means that section titles will not be
numbered. It has nothin
Ihor Radchenko writes:
> You might as well use [[Link]].
For context, I use '#+OPTIONS: num:nil', which means that '[[link]]'
exports as 'link' and not a section number. I thought about using
'[[Link]]' as you suggest, but it would make almost all sentences I
write ungrammatical. For compariso
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> [...]
>
> So, if I understand correctly, there is no way to make "[[link]]" find
> "* Link" while editing, after exporting, and on any Emacs, that is
> 'emacs -Q'. In other words, writing "* link" in lowercase, which is my
> workaround, is
Ihor Radchenko writes:
> [...]
So, if I understand correctly, there is no way to make "[[link]]" find
"* Link" while editing, after exporting, and on any Emacs, that is
'emacs -Q'. In other words, writing "* link" in lowercase, which is my
workaround, is "the solution". Do I have that right?
Rudolf Adamkovič writes:
> A while ago, I asked about case insensitivity of the syntactically
> simplest "[[links]]" in Org. I am interested in using these links
> because they are the most practical with the "literal" view.
>
> In 'emacs -Q' Org 9.6.9, "[[links]]" are case _sensitive_ when look
Howdy!
A while ago, I asked about case insensitivity of the syntactically
simplest "[[links]]" in Org. I am interested in using these links
because they are the most practical with the "literal" view.
In 'emacs -Q' Org 9.6.9, "[[links]]" are case _sensitive_ when looking
for headings. This was
18 matches
Mail list logo
