links in messages

[Yuri D'Elia]

It would be nice to have some uniformity in link behavior in either the
text or shr rendering of the links, as you cannot tell at a first glance
how the message was rendered.

The handling is currently a bit different, and it feels annoying to use.

M-RET should always open the links. Moving over the link should always
the display the url, as "w" does. TAB/<backtab> should move across
links. Clicking on a link should do the same as M-RET. Currently, I
receive and error that the buffer is read-only for text-only parts,
which is odd.

[Eduardo Mercovich]

Hi Yuri.

> It would be nice to have some uniformity in link behavior in either

> the text or shr rendering of the links [...] M-RET should always open

> the links. Moving over the link should always the display the url, as
> "w" does. TAB/<backtab> should move across links. Clicking on a link

> should do the same as M-RET. [...]

As a 22 years UX professional, I *strongly* support your idea. :)


--
eduardo mercovich

Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.

[Dirk-Jan C. Binnema]

I'm all for uniformity of course -- but it's not so easy in this case.

If we only look at the shr renderer (which is the default with a new
enough emacs), we're just displaying a pre-rendered buffer with links
set-up to react to certain keys/click - it's hard to influence exactly
how it does that. I suspect you could influence shr's chosen keybinding
though.

TAB between links would be a nice feature for the non-shr display,
indeed.

At least in my case, it seems shr defaults to using a proportional font
(on graphical displays), which makes the difference quite visible.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Yuri D'Elia]

On Sun, May 22 2016, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
>> M-RET should always open the links. Moving over the link should always
>> the display the url, as "w" does. TAB/<backtab> should move across
>> links. Clicking on a link should do the same as M-RET. Currently, I
>> receive and error that the buffer is read-only for text-only parts,
>> which is odd.
>
> I'm all for uniformity of course -- but it's not so easy in this case.
>
> If we only look at the shr renderer (which is the default with a new
> enough emacs), we're just displaying a pre-rendered buffer with links
> set-up to react to certain keys/click - it's hard to influence exactly
> how it does that. I suspect you could influence shr's chosen keybinding
> though.

I have some tentative changes that I'm using, and indeed I modify
shr-map directly. It's fine for me, as I use a dedicated instance of
emacs for mu4e, but that's not a good general solution. For instance:

(define-key shr-map (kbd "M-RET") 'shr-browse-url)

The only thing I can contribute is the binding for 'w' (which does the
analogous of shr's "copy to clipboard":

(defun mu4e~view-copy-url-from-binding (&optional url)
(interactive)
(let ((url (or url (mu4e~view-get-property-from-event 'mu4e-url))))
(when url
(kill-new url)
(message "Copied %s" url))))

(define-key mu4e-view-clickable-urls-keymap "w" 'mu4e~view-copy-url-from-binding)

> At least in my case, it seems shr defaults to using a proportional font
> (on graphical displays), which makes the difference quite visible.

That's tunable with shr-use-fonts. I'm actually running the latest shr
code in emacs24 to use shr-use-colors and shr-use-fonts (both set to
nil), which make them indistinguishable.

Arguably, shr's rendering of links is not the best in this scenario, as
you need to actually hover on a link, or move into it, or press 'w' to
see the actual URL.

On email messages, this is obviously not good. Especially for symmetry
with text messages.

I was also planning to plug into shr to always expand the link (in
brackets, or something always visible), but didn't get to it yet.