Re: Emacs development...

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>
>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>> 
>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>> expressions in the source buffer. 
>>>
>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>
>>> What I am trying to do now is fix a bug in package.el and I don't see how I 
>>> can
>>> use ielm for that. Do you have suggestions ?
>>
>> The relevance of ielm is that it is a powerful and useful tool you have
>> at hand when doing development or bug fixing in elisp. It provides the
>> REPL where you can test/evaluate bits of code. How useful it is for a
>> specific issue will depend on that issue. 
>
> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
> interested to know if I can improve on my workflow. 
>

Evaluating sexp in the code is very valuable. However, sometimes, I just
want to execute functions or parts of functions outside the context of
the code file. I might just want to verify my understanding of how a
function works, or call it with different arguments or modify something
etc. I'm not suggesting ielm as an alternative, but rather an addition
to the set of tools/techniques used. 

>
>> The main limitation with edebug (with debuggers generally), is that it
>> doesn't really help with understanding the logic and intention of the
>> code. It can help with understanding the 'mechanics' - what gets run
>> when and what gets set to what value at what point etc. However, this
>> rarely helps explain why. You may identify when a variable gets set to
>> the wrong value, but not why it ended up with the wrong value. Knowing
>> when it gets set to the wrong value can be useful, but often, if you
>> really understand the code, you can already see this by just running the
>> steps through mentally. 
> You have a point there, but in many cases people are not really sure
> what value is passed into variable, so they will printf or message in
> elisp, something just to see the value so they can identify which piece
> of code it gets.
>
> In that particular case, I would suggest that debugger is to prefer,
> instead of adding a printf statememnt which will go away in a seconds
> after.

I personally find doing things like that much faster and less hassle
than firing up the debugger, instrumenting functions and stepping
through code.

Everyone will have their own style. I've seen lots of people who depend
heavily on debuggers. I rarely use them for any language. Debugging is
tedious enough without making it worse IMO.

A lot can also depend on the quality of the code. If you have lots of
code which depends on side effects all over the place, then sometimes a
debugger is the only way you can try and track down the problem. On the
other hand, clean functional code which avoids side effects tends to be
easier as you can clearly see where and how things get modified without
having to watch for changes or trace code execution. 

Different languages can also change the equation a bit. I am more likely
to use a debugger when working in C or assembly, but never when working
with CL, Clojure, javascript, elisp etc. I might with Java, but then
again, if I'm forced to do java, I'm already bored and no longer having
fun!

>
> Before I learned to use a debugger it could have being a lot
> of System.out.println statements, to the point I needed to search the
> output in a text editor. It was many years ago when even grep was an
> esoteric command for me :).

All depends on how you use/add those statements. If you find it
necessary to search through heaps of lines of output, I would argue you
are not using the statements judiciously. You add statements where they
are beneficial and remove them as soon as there not. Same with using the
debugger - you don't instrument everything and watch all the variables -
you apply things judiciously and clean up as you go.