There is a bit to unpack here as I think the answer to your question involves more than just basic how to instructions. The first point I'd emphasise is the critical importance of getting very familiar with the Emacs help system. Emacs help provides some extremely valuable information. For example, C-h v will provide you with a wealth of information regarding a variable. It will tell you what its curent value is, what its value was initially and in the case of buffer local variables, what the current buffer value is as well as what the default value is. It will also provide you with links to the source code where the variable is defined. In many cases, it will also provide a link to the custom interface and relevant info documentation. I suspect your enquiry re: where variables are being set is really about seeing where variables are defined. C-h v will provide that information. Likewise, C-h f will provide similar details, but for functions. There are also some additional packages you can install which will further augment the help system with additional useful information. For example, the helpful package. However, I would strongly recommend becoming familiar with the base help functionality before installing additional functionality. As to using things like debug-watch, I cannot help much. In nearly 30 years of Emacs use, I have probably used the debugger less than 10 times. I've just never found stepping through code and watching how variables change value to be very useful. In fact, I think it actually works against gaining understanding of the code. My approach is to read the code and try to understand what it does that way. I might evaluate bits of code in ielm or write very simple functions in the scratch buffer to get a better understanding etc. However, running the debugger, instrumenting functions, adding breakpoints etc is a lot of additional work and I find that additional effort is only justified for complex or difficult issues where I cannot track down the issue using more basic techniques. When it comes to languages like C or C++, I might make more use of a debugger, but for scripting languages and lisps, I tend to use the repl. For me, the debugger is the last choice, not the first. I do often use debug-on-error and debug-on-quit to pinpoint the location where something is going wrong. Once I have that, I'll usually use C-h f to look at the function and associated documentation wehre the issue occured and then read through the code to try and understand possible causes. In some cases, I might even copy the function source code, paste it into the scratch buffer, add some calls to message to dump out state information etc and then evaluate that copy so that it replaces the current version. In fact, this ability to modify a function and re-evaluate it and have the new version running in your current environment is an extremely powerful aspect of Emacs. This allows you to modify the running system on the fly and verify it works. If it doesn't debug, modify and try again. If it doesn't work and worse still, completely breaks Emacs, no big deal, just exit and restart and your back to the previous version. As mentioned in other posts, I also run multiple copies of Emacs. Currently, I still use a package called chemacs2. This package lets me define a .emacs-profiles.el file, which is a list of different Emacs profiles. I have many such profiles, but the two most important are my prod and my test profiles. My prod profile is my day-to-day Emacs workhorse. My test profile is the one I use when I want to experiment with new packages or new configurations or when I want to track down a bug in some package. The reason I do this is so that if I should inadvertently cork my configuration, I can just exit, start emacs with my stable prod profile, modify/undo whatever it was I did in my test environment and then try again. This avoids me getting into the situation where I cannot fix problems because I have broken emacspeak. Emacs 29 added a new command line option which allows you to set the user-emacs-directory i.e. where emacs will look for your init.el and other config files. So you can now achieve the same functionality as chemacs2 just using out of the box emacs. Tim Parham Doustdar <parham90@xxxxxxxxx> writes: > Hi T. V. and Tim, > Thanks a lot for the tips, I'll definitely use these. > How can I check where variables are being set during Emacspeak start-up, without losing > speech? One of the issues that made me stuck was that using debug-watch in my init file > meant I didn't have speech to read the debugger output. > Thanks! > Sent from my iPhone > >> On Jan 13, 2024, at 03:58, T.V Raman <raman@xxxxxxxxxx> wrote: >> >> >> and never forget M-. for cross-references. You can start with grep, >> but grep lie any search will land you in the middle of things; but to >> undrstand something --- anything? --- starting at the beginning is a >> better idea. >> >> >> >> Tim Cross writes: >>> >>> Just wanted to re-iterate Raman's suggestion, especially reading >>> emaspeak sources. >>> >>> I would also add that experimenting using both the scratch buffer and >>> ielm mode are extremely useful. As you read through the code, when you >>> come across code or documentation explanations you are having trouble >>> grasping, experimenting inside the ielm repl or the scratch buffer can >>> be extremely enlightening. In fact, I often find a few minutes playhing >>> with a command or function and/or setting different variable values in >>> ielm or the scratch buffer is far more productive than lots of google >>> searching. Problem with google is it cannot tell you which results are >>> bad advice or just plain wrong. In recent times, I find the rapid >>> increase in 'noise' has drastically reduced the reliability of google >>> results. >>> >>> >>> >>> >>> "\"T.V Raman\"" (via emacspeak Mailing List) <emacspeak@xxxxxxxxxxxxx> writes: >>> >>>> Ack. The best resource I can point you at are: >>>> >>>> 1. Emacspeak sources and docs, >>>> 2. Emacs docs >>>> >>>> >>>> >>>> Parham Doustdar writes: >>>>> Hi Raman, >>>>> Thanks for the explanation and the changes. >>>>> You made me realise that I have no clue what goes on in the Makefile. I’ll learn from >>>>> the syntax and look deeper into that, thanks. >>>>> I also wanted to reassure you that I know everyone is busy, and sending an email is not >>>>> my first reaction to encountering an issue. That is what I hope to illustrate by always >>>>> including the steps that I took to debug or resolve it. When I send an email asking >>>>> something, it’s because either (1) I wonder if I’m understanding the intention >>>>> correctly or (2) my skills and Google haven’t turned up a solution, likely because I’m >>>>> encountering an “unknown unknown”. >>>>> I’m always very open to learning, so if you or anyone else on the list has concrete >>>>> steps I could take, or resources I could learn from, feel free to share – I commit to >>>>> taking action on getting better at solving my own problems. >>>>> Thanks. >>>>> >>>>>> On 11 Jan 2024, at 18:26, T.V Raman <raman@xxxxxxxxxx> wrote: >>>>>> >>>>>> I've changed the default to nil, had it set to nil in my .custom file >>>>>> which was shadowing the default. >>>>>> >>>>>> 1. defcustom declares the variable with its default >>>>>> 2. make config puts the default into loaddefs.el >>>>>> 3. Before jumping off to send email, take some time to understand >>>>>> things, experiment etc. >>>>>> 4. Just sending me email will likely mean I'll stop responding since >>>>>> like you I too am busy. >>>>>> 5. >>>>>> -- >> >> --
|Full archive May 1995 - present by Year|Search the archive|
If you have questions about this archive or had problems using it, please contact us.