emac...@gmail.com (Richard Y. Kim) writes:
> Thanks for your feedback. Attached is new patch which incorporates all
> your suggestions
Applied. Thank you.
> except the following:
>
>> Not directly related to your patch, but shouldn't it be
>>
>> (user-error "Could not open: %s" name)
>
> I'm
Hi Nicolas,
Thanks for your feedback. Attached is new patch which incorporates all
your suggestions except the following:
> Not directly related to your patch, but shouldn't it be
>
> (user-error "Could not open: %s" name)
I'm not sure what you mean by this. Do you mean that the verb "open"
Richard Kim writes:
> Thanks for your feedback. I agree that using the same link type is better.
> Hence I took an alternate approach as detailed in the attached patch.
> Enhanced org-info-follow-link to attempt index lookup if node lookup fails.
> Following is my check in message found in the
Nicolas,
Thanks for your feedback. I agree that using the same link type is better.
Hence I took an alternate approach as detailed in the attached patch.
Enhanced org-info-follow-link to attempt index lookup if node lookup fails.
Following is my check in message found in the attached patch:
Hello,
Richard Kim writes:
> A patch is provided below which implements a new link type called "infoi"
> as a complement to "info" type that exist already.
Thanks for your patch.
> Why new link type? Because info index is almost always finer grain
> than info nodes. For example [[infoi:libc#
A patch is provided below which implements a new link type called "infoi"
as a complement to "info" type that exist already.
Why new link type? Because info index is almost always finer grain
than info nodes. For example [[infoi:libc#close]] brings up not only
"(libc)Opening and Closing Files" i