From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Emacs development... Date: Sun, 22 Aug 2021 09:09:49 +1000 Message-ID: <87bl5q5n8b.fsf@gmail.com> References: <56B1C272-CB13-4793-930C-9F6B96F9856B@traduction-libre.org> <83r1enz453.fsf@gnu.org> <87h7fjuuva.fsf@gnu.org> <351DF59E-BFE0-4CC2-8A40-B4E7CB73D81E@traduction-libre.org> <2281ccca2d439b935535197d931c1ccf41b0f86f.camel@yandex.ru> <3AA2DD3C-EDEC-4180-9180-AE84D6705BE8@traduction-libre.org> <87fsv26eu1.fsf@gmail.com> <5587433C-396F-4230-A81D-21CC33FAF901@traduction-libre.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26907"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.4; emacs 27.2.50 Cc: emacs-devel@gnu.org To: Jean-Christophe Helary Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 22 02:38:00 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mHbUu-0006lE-CH for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Aug 2021 02:38:00 +0200 Original-Received: from localhost ([::1]:53934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHbUs-00054E-Ds for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Aug 2021 20:37:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHbTw-0004N1-Gj for emacs-devel@gnu.org; Sat, 21 Aug 2021 20:37:00 -0400 Original-Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]:38761) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mHbTu-000698-LE for emacs-devel@gnu.org; Sat, 21 Aug 2021 20:37:00 -0400 Original-Received: by mail-pg1-x52e.google.com with SMTP id w8so13068673pgf.5 for ; Sat, 21 Aug 2021 17:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=eEX3gkvqTkptj9wSxXZDO7007W7RP8MDQcPObnIinRA=; b=lY+KPTfAdH4ivtE+NuuS4c216c3wjggofmYrC2ltFVoj9OIULFR3XzUtiI3UO1X4FU pScv4Xb+2KqM3msmFU9UMhJ9e6b5Hs8RjPyE7cbYszpVfzEv8S1W0kou4wjpMbstIPxn v1QbtEwNwbjCN5zlwXmVa3lfImF7Y4yr+yDFoSgzpBg0TI+y9HH02e6saoLi88HSkUMI WdY/Zzbxvj5VWzkdK+wG3XGEF36yXCAxWLqqL3tG6Kpmbgm8JizcyzYuSzijQeZtu3aW DtN3+IjgI1IQeDXNAlZMdZS/ASUC7ShQDj/nMrqdh/e2S2f0Wc0nj/PTik/3iR5SJONq Xfjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=eEX3gkvqTkptj9wSxXZDO7007W7RP8MDQcPObnIinRA=; b=b6UihA6EPjG7DnZuaJy05ghtOLwm34j4fOIcNH8K4AtZQBEHeMvSiBw8kvHB/TWi0O LiUXJa13KwYf2+CBjHDMldLGx7bONmAM/YV89q1sWX6eznphaoDyfZrF8UvxqItBaFrY L2yEpNb/V13aYUgB58Opt1lFFFV1CdPnvZH7DabQOlLmdxJ4CSURReI8HvnhsRr7SARu fkW+Gi8Byz0NqLCM3KycoM/Ds4bP6smMACmHt5ICiTfZuqUXZRzAnVwVmlGbBMq3X672 e4TJuRF4TRibIHfR/rtL2iJE9/fjystyYU1ajmKhyHRzqvuOyUlOrTd1p+1W2RibP8pl yYgQ== X-Gm-Message-State: AOAM533g4JFItGy8JNQ7XrzniGA+G2ZOnIod5tU0uKe8m/xVBwDcBBdi 18WIK0waj1irSGSqjIX6fSuHTgQYhbM= X-Google-Smtp-Source: ABdhPJzh9esAFVj5XPqb4kRTCo9j77bMscsl5hmAeQN758vSMD6IE4L/5DNJkzM7J+34TCIp5+KoIg== X-Received: by 2002:aa7:8c14:0:b029:3e0:235a:5d58 with SMTP id c20-20020aa78c140000b02903e0235a5d58mr26701825pfd.57.1629592616851; Sat, 21 Aug 2021 17:36:56 -0700 (PDT) Original-Received: from tim-desktop (106-69-104-133.dyn.iinet.net.au. [106.69.104.133]) by smtp.gmail.com with ESMTPSA id j185sm11347417pfb.86.2021.08.21.17.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Aug 2021 17:36:56 -0700 (PDT) In-reply-to: <5587433C-396F-4230-A81D-21CC33FAF901@traduction-libre.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::52e; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:272810 Archived-At: Jean-Christophe Helary writes: >> On Aug 21, 2021, at 23:08, Tim Cross 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.