bug#37193: 27.0.50; TAB in article mode gets trapped in the header section

["Jose A. Ortega Ruiz" <jao@gnu.org>]

On Fri, Sep 20 2019, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> On Fri, Sep 20 2019, Lars Ingebrigtsen wrote:
>>
>>> I'm unable to reproduce this.  What's TAB bound to in your article
>>> buffers?
>>
>> Hmm, an update on this: at least in some articles now, i cannot
>> reproduce it either! Maybe it's been fixed since i last tried? (i
>> compile emacs from master frequently)... i'll try to reproduce the
>> problem and see what's different if so.
>
> Okidoke.  Please keep the debbugs address in the Cc headers, though,
> otherwise they won't get to the bug tracker.

OK, after further investigation, the cause of the problem seems to be to
use 'w3m for mm-text-html-renderer when the body of the message doesn't
have any text alternative (i.e., it's just plain html).  When the cursor
is lying right below the (visible) headers, TAB is bound to
forward-button, and that brings one to the next link in the header:
apparently, HTML links in the rendered message body are not seen as
buttons.  On the other hand, When mm-text-html-renderer is set to 'shr,
things work as expected (with TAB still bound to forward-button).

So this might be either a bug or change of behaviour of emacs-w3m
itself, rather than Gnus, unless Gnus was the one making forward-button
call w3m-next-anchor (that's what TAB does in a "normal" emacs-w3m
buffer) when the body is using 'w3m as its rendered.  All that provided
i'm understanding things correctly, of course :)

Cheers,
jao
-- 
Not far from the invention of fire must rank the invention of doubt.
-Thomas Henry Huxley, biologist (1825-1895)