Re: Emacs development...

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> 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
What do you mean in the code? Like C-x C-e?

M-: opens a repl, similar to ielm. It places cursor in minibuffer and
lets me eval a function with any arguments and so. Ielm asks me to keep
a prompt open in another buffer. So I have to switch to and from that
buffer, so I never really appreciate it. So I wonder if ielm has
something more to offer, than what I get from M-:?

> 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!
Indeed. I have to admit I am a bit lazy sometimes and use message if I
am just doing some quick thing. But generally I prefer debugger. In
c/c++ it is out of question to debug with printfs. I haven't wrote a
line of Java since 15 years back, so I can share your taste for fun,
definitely :).
>>
>> 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. 

Yep, I was young and innexperienced. Also nobody thought at university
how to use a debugger (or other tools like make & co really). It was all
about taxonomies from dinosaurus to mamal, cars with different colours
and all kind of persons and how they will keep track of their age and
such.