bug#39239: 28.0.50; S-TAB in shr buffers doesn't work reliably

bug#39239: 28.0.50; S-TAB in shr buffers doesn't work reliably

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 22 bytes --]


Test case is below:


[-- Attachment #2: link.html --]
[-- Type: text/html, Size: 73 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1035 bytes --]


If you start from the start of the buffer, TAB will take you to "Gnu",
then to "FSF" and then "no more links".  If you start from the end and
S-TAB, it'll take you to "FSF" (which is correct) and then "no previous
link", which is incorrect.

Furthermore, if you put point on the "a" in "Bar", it'll take you to Gnu
instead of "FSF".

Looking at the code in text-property-search-backward, there seems to be
several off-by-one errors there, interacting with each other in horrible
ways and makes my head swim, but unless somebody gets there before me,
I'll have a look at it some other day.


In GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-01-21 built on marnie
Repository revision: c1b6cf6757fbd00cf6e8cae23e1670b9ff794811
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#39239: 28.0.50; S-TAB in shr buffers doesn't work reliably

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Looking at the code in text-property-search-backward, there seems to be
> several off-by-one errors there, interacting with each other in horrible
> ways and makes my head swim, but unless somebody gets there before me,
> I'll have a look at it some other day.

I think I got it right now -- all the test cases still work, and the
behaviour in eww now seems correct in my use case.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no