Re: erc-element.el

[Emanuel Berg]

J.P. wrote:

>> 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.

Isn't it a good idea to include them for interactive use?

Since, with the current `erc-button-previous', if point is at
the top of the buffer and the user invokes it, nothing will
happen. But the user wanted something to happen, so cycling is
then intuitive - and the only alternative as well.

>From Lisp, it is thinkable someone has coded a program to
hammer back until nothing happens, then do something else.
Is that the case you worry about? To be honest I don't know if
such code should be encouraged ;) but OK, keep the non-cycling
for non-interactive use then?

(Yeah, same for going forward, only ... uhm, the other
way around?)

> 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.

Yeah, but what's the difference, in your mind? To me it is the
same, tab until you are where you want, then do whatever it is
that is usually done there, i.e. input for headers and prompts, press
for button, and actually whatever one can think of.

> If that distinction is considered expendable in the name of
> better UX, then perhaps someone else will weigh in with
> a +1.

To me it is the same?

>> It is both faster, more powerful and more intuitive IMO.
>
> More powerful than adding new commands?

No, I mean

1) cycling

2) include all interactive elements

It is the next level, `erc-button-{next,previous}' is just on
the button level, this is on the whole UI level, still,
complexity isn't increased in terms of UX, actually it is
reduced since one key for forward, one key for backward, and RET
to invoke (or the keyboard to type). You don't have to think
what element is what.

This is very common in the GUI world, I'm not sure if they
invented it but if they do, even tho I'm a CLI/TUI guy I don't
mind taking it from them and setting it up here. Windows XP
was the last GUI-based OS I used and I remember I was
virtually mouse-free because of this principle.

(Interesting, I didn't think of that until now. Well, I knew
the idea already when I implemented it, so it was
stored somewhere. I didn't come up with it for sure.)

> 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.

Uhm, not following 100%? I'm not familiar with transient or
toggles ...

> 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.

Well, I think it cripples the idea a little bit (a lot) if you
mean one must do C-u prior to hitting the key, it'll be too
many keystrokes. If you ask for my opinion, I like the
interactive-only idea better ...

> 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.

Not following? :)

> Anyway, it's clear now that these erc-element snippets
> you've been sharing were meant primarily for illustrative
> purposes.

Oh, no, they are operational! I use them.

> 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).

No ... let's agree first what the goal is, after that I'm
confident details can be sorted out :)

https://dataswamp.org/~incal/emacs-init/erc/erc-element.el

-- 
underground experts united
https://dataswamp.org/~incal