Re: erc-element.el

[J.P.]

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

>> given that the behavior of these user-facing command[s] has become so
>> ingrained after all these years, under what circumstances would
>> changing it be justified?
>
> Well, the question is "will this improve the software?" If the answer
> is yes, details are often easy to sort out ...

I'd say the answer is yes when it comes to the "unresponsive at prompt"
issue. That feels like a bug to me because the existing command doesn't
live up to the claims made by the doc string. As for cycling and
visiting prompt, I'd also be inclined if the existing behavior weren't
so entrenched. But things being as they are, I'm rather ambivalent.

>> I think we'd more than likely want to introduce completely new
>> variants.
>
> I think integrating them would be better, [...]
>
>  https://dataswamp.org/~incal/emacs-init/gnus/moggle.el

Looks like your library mainly concerns data entry, so visiting places
where input is required makes sense in context, in the same way tabbing
through an HTML form does. But this button stuff is limited to moving
the focus between clickable buttons. If that distinction is considered
expendable in the name of better UX, then perhaps someone else will
weigh in with a +1.

> It is both faster, more powerful and more intuitive IMO.

More powerful than adding new commands? Such an opportunity would grant
us the freedom to innovate, perhaps with newer, more powerful tools
(like transient). And if someday actions (likely toggles) were added for
newer features (like multi-line folding or discussion threads), a
general purpose, element-wise navigation command could (optionally)
visit those as well.

But for now, as a compromise, what about adding extra params for
wrapping and no-error (and maybe visiting prompt), similar to what
`forward-button' offers? Not as convenient, but present for those
willing to use prefix args or wrap the commands in some way. Another
idea would be to add the button.el text properties alongside
'erc-callback' and then defer to its commands for all our
button-interacting needs. This implies unbinding and deprecating
`erc-button-{next,previous}' and maybe aliasing them over in the
meantime.

Anyway, it's clear now that these erc-element snippets you've been
sharing were meant primarily for illustrative purposes. So being that
your aim is to alter instead of introduce, perhaps a move to patches
would do the most good here (if only to help make your case to our
superiors in a proper bug report).