Define two new button types corresponding to article and comments links, respectively.
Reuse and extend button-map for following links via RET or mouse click.
Remove cl.el dependency by replacing lexical-let closures with ad-hoc button/text property lookup (though it would be nice to have a signum function). This has the additional benefit of allowing describe-key to report named commands, rather than anonymous closures.
Move between links via button instead of regexp search. This allows multi-jumps and is more robust to formatting changes of the hackernews buffer (e.g. by user customisation), at the expense of having to implement moving between buttons of a specified type. In fact, hackernews--forward-button probably belongs in lisp/button.el itself.
Add link's URL to the help-echo property so that the URL is echoed when point is placed over the link.
Incentives
Relying on cl (or its moral superior cl-lib) is not ideal when supporting Emacs versions both before and after 24.
Buttons encapsulate a lot of the text property and keymap logic of the hackernews UI in a more declarative fashion and reduce the need for closures.
Anonymous and undocumented closures should not be user-visible, e.g. when invoking describe-key over a corresponding link in the hackernews buffer.
Searching for links with regexps is a bit brittle, in that they are strongly coupled to the current formatting of the hackernews buffer.
Disincentives
button.el provides the functions forward-button and next-button for finding the next button in a buffer, but does not provide one for finding the next button of a particular type. This is implemented in hackernews--forward-button. I might suggest it as a patch to button.el one day.
This limitation of button.el wouldn't be a problem if hackernews only provided key bindings for "next link" and "previous link", as we could just reuse button-buffer-map, but that is not the case.
cl.el provides the function signum, and cl-lib.el provides cl-signum, but they had to be reimplemented as hackernews--signum for backwards compatibility.
Changelog
button-map
for following links viaRET
or mouse click.cl.el
dependency by replacinglexical-let
closures with ad-hoc button/text property lookup (though it would be nice to have asignum
function). This has the additional benefit of allowingdescribe-key
to report named commands, rather than anonymous closures.hackernews
buffer (e.g. by user customisation), at the expense of having to implement moving between buttons of a specified type. In fact,hackernews--forward-button
probably belongs inlisp/button.el
itself.help-echo
property so that the URL is echoed when point is placed over the link.Incentives
cl
(or its moral superiorcl-lib
) is not ideal when supporting Emacs versions both before and after 24.hackernews
UI in a more declarative fashion and reduce the need for closures.describe-key
over a corresponding link in thehackernews
buffer.hackernews
buffer.Disincentives
button.el
provides the functionsforward-button
andnext-button
for finding the next button in a buffer, but does not provide one for finding the next button of a particular type. This is implemented inhackernews--forward-button
. I might suggest it as a patch tobutton.el
one day.This limitation of
button.el
wouldn't be a problem ifhackernews
only provided key bindings for "next link" and "previous link", as we could just reusebutton-buffer-map
, but that is not the case.cl.el
provides the functionsignum
, andcl-lib.el
providescl-signum
, but they had to be reimplemented ashackernews--signum
for backwards compatibility.