Re: how to speed up Lisp devel time

[Emanuel Berg <incal@dataswamp.org>]

Yuri Khan wrote:

> If your command has three arguments, asking for them in
> succession with validation and re-asking is the wrong UI/UX.

? "Wrong"

How should one deal with inputted data that doesn't validate?

Saying this is wrong, and failed here, ask for another value.
Abort with C-g. I could use such an interface anyway and see
nothing wrong with it.

In a way, it already does that:

  (read-number "enter a string: ")

If I enter a string it says "Please enter a number.' It is the
same I suggest only one tiny step more involved to work for
arbitrary validation and not just for `numberp' or however
that works.

But one could also use the default value, or just do `error'.

> * A user may want to see the values entered for the first
> N arguments when typing the (N+1)th.
> * A user may want to fix a typo in the Nth argument when
> typing the (N+1)th.
> * A user may want to recall the whole set of arguments from
> the history, and optionally modify one or more of them.
> * A user may want to switch to a different window or frame
> while composing one of the arguments.

Okay? It will be even more "82 Elisp lines" but that would be
even better, sure.

> Interactive interface for more than one argument must be
> explicitly designed.

Oh, no. If you, or someone else, writes a great function,
macro or whatever to solve this it and setup a great
"interface interface" will all the fixings, will solve it for
many, many, many cases of one, two, three and so
on combinations.

There will always be one "odd man out" or bad apple, but just
because it is more than a certain number, then it can't be
automated, I don't believe that at all and I trust good
automation much more than (n) Elispers to all setup their own
stuff explicitely.

As for using it, no problem, especially with default values,
or history, one can just hit RET RET RET.

Depending on the command, there maybe should be a quicker way
to not have to do that as well, but that's another thing.

Inputting two or three values, well, to me anyway, that isn't
a problem.

Four or five - then it gets too boring so cannot be used for
functions that are used often, but of course that would be
possible as well. For example, to setup some LaTeX table with
tons of parameters. Absolutely possible and again, this can be
automated with an "interface interface", not to cover 100% but
that will cover many, many cases and can be tweaked for
many more.

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