Re: erc-element.el

[J.P.]

Emanuel Berg via General discussion about ERC <emacs-erc@gnu.org>
writes:

> (defun erc-element-next (&optional prev)
>   (interactive "P")
>   (condition-case nil
>       (if prev
>           (erc-button-previous)
>         (erc-button-next) )
>     (error (progn
>              (goto-char (point-max))
>              (when prev
>                (erc-bol) )))))
>
> (defun erc-element-prev ()
>   (interactive)
>   (let ((beg (point)))
>     (erc-element-next t)
>     (when (= (point) beg)
>       (forward-line 0)
>       (forward-char -1)
>       (erc-element-next t) )))

I agree that the behavior demonstrated by these commands is preferable
to what's currently available from `erc-button-{previous,next}', namely,
erroring at the bounds and being unresponsive at the prompt. If the
latter constitutes a bug, then would it be responsible to change the
existing commands rather than add new ones?

For non-interactive use, I vote no, because third-party code may rely on
that behavior, specifically those aspects you find fault with. But what
about applying this exclusively to interactive invocations? That may
still be unwise because of the added complexity and possible confusion
arising from the disparity. But I suppose some discussion regarding that
would be warranted.

But if these are to be brand new commands, where would they live? I
think if we're leaving the door open to including other types of
elements, these two could go somewhere like erc-goodies.el (perhaps with
a user option specifying what elements to include as stops along the
tour). But if "elements" will only ever mean {buttons, prompt}, then
these commands could probably just coexist in erc-button.el alongside
their legacy counterparts. (In this case, the names should probably be
changed to something uglier, like `erc-button-plus-{previous,next}'.)