Emacspeak discussion list

[Tim Cross <theophilusx AT gmail.com>]

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 AT gmail.com> 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 AT google.com> 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 AT emacspeak.net> 
>>> 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 AT google.com> 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.
>>>>>> --
>> 
>> --