Re: Emacs development...

[Jean-Christophe Helary <lists@traduction-libre.org>]

> On Aug 22, 2021, at 8:09, Tim Cross <theophilusx@gmail.com> wrote:
> 
> 
> 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 ?
> 
> It seems like you may be looking for a basic recipe for how you find and
> fix a bug in elisp.

Thank you Tim for your detailed reply.

I am myself guilty of replying to threads that I have not fully read so I won't complain, but I did send a clarification mail after my very first super generic mail, where I clearly stated that I was looking for a method to see how variable values evolve over the running of some code.

It seems that the common answer to that is edebug, and I think I understand what you mean by "it doesn't really help with understanding the logic and intention of the code. It can help with understanding the ’mechanics’".

> - 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.

I can do that. I'm using "inform" and "helpful" already and they are indeed very helpful in finding extra info about functions, 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.

I just read their description and they'll probably be useful at one point but since there is no "error" in the package.el code (in the meaning that an error would stop the execution of the code, or produce something similar), I'm not sure how I can use them for my purpose right now, but I'll keep them in mind.

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

The suggestions I got about M-. and M-, were invaluable. They already tremendously improved my navigation of the code.

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

I do that already.

> - edebug - for stepping and tracing through code

I guess that's the one where I can see how values evolve.

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

Unlikely.

> 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.

In the case at hand, it is 100% reproducible, I mentioned it in a mail I sent here with the title "package.el, a bug ? and a UX issue ?".

I've already fixed stuff in package.el in the past, mostly improper use of strings, not bugs per se. I wanted to further improve on that when I found that glaring bug that I'm surprised nobody noticed yet:

mark for upgrade with U
filter on marked with / m
remove the filter with / /
the marks for upgrade are gone.

generally speaking / / will remove any mark, not just upgrade ones. I guess the fact that this bug has remained in the code for so longs says something about how often the filter feature is used.

Thank you very much for the following paragraphs. They are an excellent description of what debugging involves, which I have practiced in other contexts (namely AppleScript stuff that I develop for myself) even if at a much lower level.

I'm glad I started this thread.

Jean-Christophe

> 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. 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/