djcb / mu

maildir indexer/searcher + emacs mail client + guile bindings
http://www.djcbsoftware.nl/code/mu
GNU General Public License v3.0
1.62k stars 391 forks source link

[gnus] RET doesn't work on gnus buttons #1580

Closed hpdeifel closed 4 years ago

hpdeifel commented 4 years ago

Gnus buttonizes URLS in article buffers, which can be opened with either RET or middle mouse button.

In mu4e-view-mode with mu4e-view-use-gnus set to t, RET is bound to mu4e-scroll-up and shadows the overlay bindings on the button.

Steps to reproduce

Set mu4e-view-use-gnus to t, open a message with URL in it, put cursor on the URL, press RET => The view scrolls up and the URL isn't opened.

Versions of mu, mu4e/emacs, operating system etc.

djcb commented 4 years ago

Good news: this works fine with 1.3.8 or newer.

averter commented 4 years ago

To be specific, messages received by others are OK, and when I look up my sent messages on thunderbird everything is also OK. Only when I open messages that I've sent on mu4e I don't get the proper display of links. I can post my mu4e configuration if necessary.

djcb commented 4 years ago

@averterer: Perhaps better, can you attach a message (sufficiently censored when need) where this happens? Thanks.

averter commented 4 years ago

Here is the edited message test-gnus_buttons.txt. Additionally to my previous message, I found that with the mouse button it works.

djcb commented 4 years ago

Strange... it works here. When point is on the URL, what does C-h k RET report?

averter commented 4 years ago

Same as @hpdeifel it seems to be bound to mu4e-scroll-up. Let me know If you want to see anything from my configuration.

RET runs the command mu4e-scroll-up (found in mu4e-view-mode-map),
which is an interactive compiled Lisp function in ‘mu4e-view.el’.

It is bound to RET.

(mu4e-scroll-up)

Scroll text of selected window up one line.

[back]
theophilusx commented 4 years ago

Seems to be working for me. When point is on a url describe-key says it is bound to shr-browse-url and when outside a url, mu4e-scroll-up.

This is with messages rendered as HTML. I don't have any plain text messages with URLs in them at the moment. Maybe that is the difference?

Alternatively, could there be something unusual about the URL such that it isn't being recognised as a URL?

I'm on Linux, Emacs 27.0.91 and mu4e 1.4.1

averter commented 4 years ago

@theophilusx I can see it fine on my other email-browser so it is probably mu4e-related. This is the active modes/hooks when reading the message

Enabled minor modes: Async-Bytecomp-Package Auto-Composition
Auto-Compression Auto-Encryption Blink-Cursor Electric-Indent Emojify
Engine Epa-Mail File-Name-Shadow Font-Lock Global-Eldoc Global-Emojify
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Multi-Web-Global
Override-Global Pyvenv Shell-Dirtrack Tool-Bar Tooltip Transient-Mark
Typopunct Yas Yas-Global

(Information about these minor modes follows the major mode info.)

mu4e:view mode:
Major mode for viewing an e-mail message in mu4e, based on
Gnus’ article-mode.

In addition to any hooks its parent mode ‘gnus-article-mode’ might have run,
this mode runs the hook ‘mu4e-view-mode-hook’, as the final or penultimate step
during initialization.

and this is the configuration of the mu4e-view-mode-hook

       (add-hook 'mu4e-view-mode-hook
         (defun my-view-mode-hook ()         ;; SIGNING AND ENCRYPTING
           (require 'typopunct)
           (typopunct-change-language 'english)
           (typopunct-mode 1)
           (visual-line-mode t)                ;; wrap text
           (epa-mail-mode)))                 ;; SIGNING AND ENCRYPTING
theophilusx commented 4 years ago

I would start by removing your view-mode hood function and see if links work. If they do, then you will know it is something being loaded in that function. At that point, I'd start adding each item back and testing to see which one is causing the issue.

averter commented 4 years ago

Tests/Observations:

theophilusx commented 4 years ago

I don't use the menu bar or tool bar, so haven't seen the new url button issue.

Interestingly, the way I tested a plain text message was to send my self a message with just some text and the url https://www.google.com - it worked fine. Does it happen when you use a different email client to send yourself a message or just when you send one using mu4e?

averter commented 4 years ago

I also don't use the menu bar (just noted that it suddenly changed because of hitting RET on the URL). Indeed, it happens regardless of the email client that I use to send the message, which suggests that it's how mu4e is viewing the message, rather than writing it. And it happens only when I'm sending it to myself, not when other people message me. I'm running out of ideas to test this

theophilusx commented 4 years ago

Probably a long shot, but what do others get when you send them a message? Are they able to follow links you put in the message?

-- Tim Cross

averter commented 4 years ago

From my email-browser I can see the links from my messages, so probably other people will also be able to see them? Could it be related to this bug? Hmm....! This is for messages that are ok

             position: 480 of 706 (68%), column: 0
            character: A (displayed as A) (codepoint 65, #o101, #x41)
              charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x41
               script: latin
               syntax: w    which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET 41" or "C-x 8 RET LATIN CAPITAL LETTER A"
          buffer code: #x41
            file code: #x41 (encoded by coding system no-conversion)
              display: by this font (glyph code)
    xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x24)

Character code properties: customize what to show
  name: LATIN CAPITAL LETTER A
  general-category: Lu (Letter, Uppercase)
  decomposition: (65) ('A')

There are text properties here:
  face                 gnus-header-name
  fontified            t

This one for messages not OK

             position: 218 of 258 (84%), column: 0
            character: C-j (displayed as C-j) (codepoint 10, #o12, #xa)
              charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x0A
               script: latin
               syntax:      which means: whitespace
             to input: type "C-x 8 RET a" or "C-x 8 RET LINE FEED (LF)"
          buffer code: #x0A
            file code: #x0A (encoded by coding system utf-8-unix)
              display: no font available

Character code properties: customize what to show
  old-name: LINE FEED (LF)
  general-category: Cc (Other, Control)

There are text properties here:
  fontified            t
theophilusx commented 4 years ago

According to that link, the bug was fixed back in 2017, so probably unlikely. You could try upgrading to 27.0.91 from git repo - it is petty stable.

averter commented 4 years ago

UPDATE: I've just received a message from someone else with links which were not clickable. The content type was also text/plain; charset=UTF-8. I'll try commenting my mu4e configurations until a bare minimum to see if I get to the bottom of this.

averter commented 4 years ago

It's related with the gnus-article view. As soon as I comment (setq mu4e-view-use-gnus t) the links became visible and I was able to follow them with g. Side note: in the meantime I've upgraded to 1.4.1. Do I need to configure something in gnus for it to work? My configuration is as simple as

;; Use gnus article view
(setq mu4e-view-use-gnus t)
(require 'mu4e-icalendar)
(mu4e-icalendar-setup)

UPDATE: probably it is related to the decoding issue #1262

averter commented 4 years ago

I don't use the menu bar or tool bar, so haven't seen the new url button issue. Interestingly, the way I tested a plain text message was to send my self a message with just some text and the url https://www.google.com - it worked fine. Does it happen when you use a different email client to send yourself a message or just when you send one using mu4e?

and how did you sent it? I'm using msmtp. Maybe this will reveal why I'm the only one experiencing this. Here's my configuration

;; sending mail (use msmtp)
(setq message-send-mail-function 'message-send-mail-with-sendmail
      sendmail-program "/usr/bin/msmtp" 
      message-sendmail-extra-arguments '("--read-envelope-from");; tell msmtp to choose the SMTP server according to the from field in the outgoing email
      message-sendmail-f-is-evil 't)
djcb commented 4 years ago

I think ultimately this comes down to a difference in behavior in 26.3. compared to some newer version; in 26.3 I could indeed reproduce it.

I've pushed a commit that should fix this...

averter commented 4 years ago

Thanks. It is working here.