[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs development...

From: Arthur Miller
Subject: Re: Emacs development...
Date: Sun, 22 Aug 2021 09:47:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]