Re: Emacs development...

[Tim Cross]

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. 

It seems like you may be looking for a basic recipe for how you find and
fix a bug in elisp. There is no such thing. Every bug is different. The
one thing which is consistent is the need to understand the environment
and available tools. The main point I wanted to make is that the Emacs
debugger, while a very useful tool, is not where I would focus
initially. I feel it is often a mistake for people to immediately think
that when trying to track down a bug, the first thing you do is fire up
edebug. Most of the time, it is the last thing I use - in fact, for most
bug fixing or elisp development, I never use it. It I had to rank the
tools from most important/useful to least, it would probably be
something like

- Emacs built-in help system (including using info effectively). Looking
  up information about functions and variables, current configuration
  settings, key bindings, finding relevant functions/variables etc.

- Using debug-on-error and debug-on-quit to generate backtraces -
  essential tools to identify the point in the code where things go
  wrong, allowing you to work backwards to find out why. 

- emacs=lisp-mode - navigating around the code, finding definitions,
  evaluating expressions etc

- ielm and *scratch* buffer in elisp mode - entering expressions, using
  history, pasting and yanking code etc. 

- edebug - for stepping and tracing through code

- gdb - for those rarer cases where you need to dive into low level C stuff

When trying to track down a bug, I find the most important first step is
to try and identify the minimal recipe to reliably reproduce the issue.
If you cannot reproduce it, you are unlikely to be able to fix it. Even
if you think you have fixed it, you won't know for sure unless you know
how to reproduce it. Once you know the minimal environment configuration
needed to trigger the bug, you will have a better idea where in the code
the bug is likely located and can study that bit of code to understand
how it works. To understand it, you will likely need to lookup the docs
for functions and variables involved and possibly try executing
functions/commands in ielm to see what they return based on different
input values etc. At this point, your objective is to narrow the search
space as far as possible. Ideally, you will narrow things down to a
single function or a couple of functions.

Once you get to this point, how you will progress will depend a lot on
the type of bug. For example, sometimes you might be able to create a
minimal test environment using the scratch buffer and ielm. You might
copy the function to the scratch buffer, give it a new name, evaluate it
and try running it with different input values. Sometimes, the type of
bug will not lend itself to doing this - for example, a UI bug in a
major mode might be difficult to 'extract' because of too many
dependencies in the modes local environment. You might need
to spend time configuring a test environment by defining variables in a
scratch buffer which you can set to different values and then execute
the command multiple times within your 'artificial' test environment.
Sometimes, it will be almost trivial - you will scan the code and a
single expression will jump out as a likely candidate and a few test
evaluations with different inputs will identify the cause.

The key is to narrow down the issue to the smallest amount of code
possible and then focus on understanding how that code works - not just
what variables change and when, but understand the logic behind he code.
Understand what the intention of the code is and identify where that
intention and actual behaviour differ. At this point, the most important
resource at your disposal is you - it is your understanding of the code
which will determine how quickly you understand the bug and can identify
how to resolve it.

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.