From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean-Christophe Helary Newsgroups: gmane.emacs.devel Subject: Re: Emacs development... Date: Sun, 22 Aug 2021 10:26:08 +0900 Message-ID: <1A33E99E-B463-4971-9DE6-C1D060C275D4@traduction-libre.org> 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> <87bl5q5n8b.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40487"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 22 03:26:53 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 1mHcGC-000ALd-MZ for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Aug 2021 03:26:52 +0200 Original-Received: from localhost ([::1]:40352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHcGA-0000YU-Lg for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Aug 2021 21:26:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHcFf-0008EM-AZ for emacs-devel@gnu.org; Sat, 21 Aug 2021 21:26:19 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:44561) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHcFb-0005g8-SJ for emacs-devel@gnu.org; Sat, 21 Aug 2021 21:26:18 -0400 Original-Received: (Authenticated sender: lists@traduction-libre.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 1BDA8FF803; Sun, 22 Aug 2021 01:26:10 +0000 (UTC) In-Reply-To: <87bl5q5n8b.fsf@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Received-SPF: pass client-ip=217.70.183.199; envelope-from=lists@traduction-libre.org; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:272813 Archived-At: > On Aug 22, 2021, at 8:09, Tim Cross wrote: >=20 >=20 > Jean-Christophe Helary writes: >=20 >>> On Aug 21, 2021, at 23:08, Tim Cross wrote: >>>=20 >>> 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.=20 >>=20 >> Thank you Tim for the suggestion. I like ielm a lot, when I use it. >>=20 >> 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 ? >=20 > 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 = =E2=80=99mechanics=E2=80=99". > - 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=3Dlisp-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. >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 --=20 Jean-Christophe Helary @brandelune https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/