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 12:48:28 +1000 Message-ID: <87tuji41l5.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> <87bl5q5n8b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9054"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.4; emacs 27.2.50 Cc: Jean-Christophe Helary , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 22 05:11:11 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 1mHdt8-00028W-Ry for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Aug 2021 05:11:10 +0200 Original-Received: from localhost ([::1]:60676 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHdt5-0002LH-KP for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Aug 2021 23:11:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37760) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHdrq-0001To-GS for emacs-devel@gnu.org; Sat, 21 Aug 2021 23:09:50 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:46711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mHdro-0004K5-BA for emacs-devel@gnu.org; Sat, 21 Aug 2021 23:09:50 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id k14so13281253pga.13 for ; Sat, 21 Aug 2021 20:09:47 -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=cUSVMAw9znMvOfrSUa/bQvoNwC9TFOYzaGptj/rMPVQ=; b=aOKjrefep82Ss0fjHiW4qDs96mhZrQIZC3omkitNyiVO9QAhDLK87rx9sn8kRjH3yO mvrDcPWJ0bEWFJtq4vHwGzPZuePeZ1k7EN9KaIcZUm5Napn+yXxWn5UjcLpV5Uu/ld1i /QPMSaBGx4IQC4jubb0HxF0BE2SIlES427/NgSmjNpymNkts7XZY60wScNxa896GHN02 kCMwKTaU4xSQFm0e3kD4vMHcmE0iLzvURCU3FFyIlq4RfGuFibX+mB8fe2DEMWN4nScK xPwbwnGaRnitnEEAIgKX2qDs/eXiRCk5sz8gNKoxFpd5B3+bLsaffIv7qK33sh6EA5vR T2zA== 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=cUSVMAw9znMvOfrSUa/bQvoNwC9TFOYzaGptj/rMPVQ=; b=CVx4N2do79n7db4j7cHhTejFixKSgd8hPE5jF8omcJKxhkUrwr4AidsfrDQd1OuHcd dSegYQmYPlamEBhBjU23LtmHnjC4BvgwJ2PCjXJHU73dkn5lpz0E5hxh3yeTlMPsWsfW U6NTayvDyZb5suCekvU5Cqusokuqs1TVgzi/24CSbiYgbydiMCgvTtOJlHNgcn3B29QT TmBCHgxDKEAPuLyOnU/e+acSBGivZXV4K9FVj/9L6iHKgXazLZxMv76rEMibsr9qF6ph 5hbWyBw27GRzC4t+9P8ARNVFflfixSojK6hyEe5+s+haO3nOhVMyasRg1wLoAi7cUhzL hYSg== X-Gm-Message-State: AOAM5311G9IfXakIlOxBpN5nvS7U7KTXa0n9qvB/M9nNxupR0rjgLTbx Ki/4js93H/K/f9v1o4KUlwo3xpHD0+o= X-Google-Smtp-Source: ABdhPJwWOdytarDLRl0afwVlSmv5W7f6EF+ATqH6eJJCYMNMLzfJTew74VTnbdM1wdrDD+9M6BW4Cg== X-Received: by 2002:a63:408:: with SMTP id 8mr25117051pge.78.1629601786927; Sat, 21 Aug 2021 20:09:46 -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 f71sm12199332pfa.176.2021.08.21.20.09.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Aug 2021 20:09:46 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52b.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:272817 Archived-At: Arthur Miller writes: > Tim Cross writes: > >> 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. > > 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 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! > > 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.