Re: how to speed up Lisp devel time

[Emanuel Berg <incal@dataswamp.org>]

Eli Zaretskii wrote:

>>> This is rather unusual, and you should expect to have some
>>> more-than-normally complicate code in that case.
>> 
>> What do you mean? It is the same for `forward-line'
>> 
>> C-u   M-x forward-line RET
>> C-u 4 M-x forward-line RET
>
> No, it isn't. forward-line accepts a numeric argument, and
> that's all. All you need to do to support that is use the
> corresponding 'interactive' code.

Okay, bad example.

What about this one, then?

C-u C-u a
aaaaaaaaaaaaaaaa 

C-u 17 a
aaaaaaaaaaaaaaaaa

>>> Also, someone pointed out that you could write this in
>>> just 83 characters.
>> 
>> Really? Well, well, let's see the code then!
>
> It was posted, I just counted the characters.

Here is the original code [last], I said it was 402 chars but
excluding the initial whitespace every line it is 376 chars.

One can make it shorter here and there, but to write that in
83 chars of Elisp - well, let's see it.

BTW that interface isn't complete/optimal I see now, there
are more stuff, also uncontroversial as you will see, that
I can add. Maybe later.

Right now - conceptually, not thinking about the details - it
supports

* Interactive use with M-x, including C-u M-x and C-u x M-x.

* Default values, for the _function_, not the interfaces.

* Verification of all args, again for the _function_ and not
  for any particular interface.

>>> That usually makes little sense in Emacs. Interactive and
>>> non-interactive uses have different semantics.
>> 
>> Same default for any kind of call makes little
>> sense. Usually!
>> 
>> I OTOH thinks that is the first policy I can think of.
>
> Then your code is unlikely to be accepted into Emacs.

The default values I speak of here isn't the default of any
particular _interface_, it is values for which _the function_
- regardless of interface - can fall back upon if the value
is unset.

I know that isn't at all any kind of radical or original
thought, it is a very basic idea and I don't care if you -
based on how it is done in Emacs - disagree.

>>> That happens, but very rarely. Well-designed clean code
>>> should avoid that.
>> 
>> It is better if everyone, well-designers or not, could use
>> a clean interface to do that. Then one could simply use it
>> and not having to rely on people writing great Elisp
>> for everything.
>
> Code doesn't write itself. Good design is always needed for
> elegant code.

The Emacs design in this case isn't good. In fact it is
a mess. The interactive and non-interactive stuff are both
tangled up sometimes and parallel sometimes.

The functions should not be branching mid-way based on that
and there shouldn't be a separate set of functions for this or
the other interface. "This is for interactive use" and all.

Interactive/non-interactive should _only_ matter in setting up
and executing _the interface_, after that the functions should
run the same based on the present data, regardless of how that
data is obtained.

Just imagine if we were to add a third interface? Would be
branch on that mid-way into functions as well, and have
a third set of functions, just for that interface?

But be that as it may, the way you do it with the
`interactive' format string still isn't good - not powerful
enough, which is way so often people have to use Lisp instead.
And, too cryptic in that tiny string which makes it
error-prone to write, and difficult to read.

[code]

(interactive (if (numberp current-prefix-arg)
                 (list current-prefix-arg)
               current-prefix-arg))
(unless end
  (setq end 73))
(unless step
  (setq step (min 10 (max 2 (/ end 10)))))
(unless i
  (setq i 0))
(unless (and (numberp i)    (<= 0 i)
             (numberp end)  (<  0 end)
             (numberp step) (<  0 step))
  (error "Bogus indata"))

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