From: "Jose A. Ortega Ruiz" <jao@gnu.org>
To: "Lars Ingebrigtsen" <larsi@gnus.org>
Cc: 37193@debbugs.gnu.org
Subject: bug#37193: 27.0.50; TAB in article mode gets trapped in the header section
Date: Sun, 22 Sep 2019 18:41:08 +0100 [thread overview]
Message-ID: <87blvckz4b.fsf@gnus.jao.io> (raw)
In-Reply-To: <87ftkowlmj.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 22 Sep 2019 14:39:32 +0200")
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...
next prev parent reply other threads:[~2019-09-22 17:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 17:54 bug#37193: 27.0.50; TAB in article mode gets trapped in the header section Jose A. Ortega Ruiz
[not found] ` <-kVaGOyZA0mF70kySY82z0Jk9_oQfvn1PE1Nd6_Kg-wPjLs78BUlv6YhbpUH64GBF-ySWIPjuTulwViJ4GrVgQ==@protonmail.internalid>
2019-09-20 20:28 ` Lars Ingebrigtsen
[not found] ` <874l16n1kk.fsf@gnus.jao.io>
2019-09-20 20:57 ` Lars Ingebrigtsen
2019-09-21 21:59 ` Jose A. Ortega Ruiz
2019-09-22 12:39 ` Lars Ingebrigtsen
2019-09-22 17:41 ` Jose A. Ortega Ruiz [this message]
2019-09-23 10:20 ` Lars Ingebrigtsen
2019-09-24 3:20 ` Katsumi Yamaoka
2019-09-25 7:44 ` Katsumi Yamaoka
2019-09-25 14:13 ` Jose A. Ortega Ruiz
2019-09-25 23:46 ` Katsumi Yamaoka
2019-09-26 0:08 ` Jose A. Ortega Ruiz
2019-09-26 1:14 ` Katsumi Yamaoka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87blvckz4b.fsf@gnus.jao.io \
--to=jao@gnu.org \
--cc=37193@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.