Re: Possible bug getting bounds of URL at point?

[Karl Fogel <kfogel@red-bean.com>]

On 16 Jul 2024, Ihor Radchenko wrote:
>> Assume we have this line in an Org Mode buffer (note there are 
>> three trailing spaces after the final "m" -- hopefully the MTAs 
>> and MUAs will leave those spaces there):
>>
>>   https://example.com   
>>
>> Let's say the initial "h" is at position 22205, the position 
>> right 
>> after the final "m" is 22224, and the final position on the 
>> line 
>> (after the three spaces) is 22227.
>>
>> With point anywhere inside the URL, if I run 
>> (bounds-of-thing-at-point 'url), I currently get this result:
>>
>>   (22205 . 22227)
>>
>> But I expected this result instead:
>>
>>   (22205 . 22224)
>>
>> Is (22205 . 22227) correct, and I'm just misunderstanding how 
>> URL 
>> boundaries are supposed to work in Org Mode?
>
>This is correct. Trailing whitespace belongs to the preceding 
>node in
>Org syntax. This is not a bug.
>
>Moreover, if you have something like
>[[https//orgmode.org][description]]
>the whole thing will be considered a URL.

Thank you, Ihor.

I admit that I don't immediately understand why this is a good 
thing.  The user asked for the bounds of the URL at point, but got 
instead the bounds of some other thing (the Org "node"). 
Especially in the case of a standalone URL, with no description 
text, I don't see how including the whitespace is useful.

However, there could be issues here that I'm not familiar with. 
It sounds like you've already thought this out and concluded that 
that including the trailing whitespace is the right behavior.  If 
you have time to explain why in more detail, I'd appreciate a 
chance to learn more about it.  However, if you don't have time to 
do that, it's no problem.

I can change the code I'm writing to do things a different way, so 
this behavior need not interfere with my current task, in any 
case.

Best regards,
-Karl