GNU bug report logs - #37193
27.0.50; TAB in article mode gets trapped in the header section

Previous Next

Full log

Message #20 received at 37193 <at> debbugs.gnu.org (full text, mbox):

From: "Jose A. Ortega Ruiz" <jao <at> gnu.org>
To: "Lars Ingebrigtsen" <larsi <at> gnus.org>
Cc: 37193 <at> debbugs.gnu.org
Subject: Re: bug#37193: 27.0.50; TAB in article mode gets trapped in the
 header section
Date: Sun, 22 Sep 2019 18:41:08 +0100

On Sun, Sep 22 2019, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao <at> 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...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.