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

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

On Sun, Sep 22 2019, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> 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 :)
>
> Gnus changed its buttons from being widgets to being button.el buttons
> recently, and that's probably what you're seeing.  I didn't think about
> out-of-tree HTML renderers in that context.
>
> Perhaps mm-inline-text-html-render-with-w3m should convert the widgets
> into buttons?

Hmm, actually, emacs-w3m seems to be merely "imitating" widget buttons
for the benefit of gnus:

  w3m-imitate-widget-button is a variable defined in w3m.el.

  Value
  (eq major-mode 'gnus-article-mode)

  Documentation
  If non-nil, imitate the widget buttons on link (anchor) buttons.

  It is useful for moving about in a Gnus article buffer using TAB key.
  It can also be any Lisp form that should return a boolean value.

From a quick look at w3m-next-anchor, it seems links are marked using
possibly add-hoc text properties, but i see
mm-inline-text-html-render-with-w3m is already doing some non-trivial
traversal of the buffer using those properties, so possibly your idea is
right...