Re: Emacs development...

[Tim Cross <theophilusx@gmail.com>]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 21, 2021, at 21:05, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
>> 
>> On Sat, 2021-08-21 at 16:50 +0900, Jean-Christophe Helary wrote:
>>> 
>>> 
>>>> On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
>>>> 
>>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>> 
>>>> Hi Jean-Christophe,
>>>> 
>>>>> Right now, I use C-h f to find the function definitions and move
>>>>> around the code.
>>>> 
>>>> That, and also M-. on a function call or variable will bring you to its
>>>> definition.
>>> 
>>> Thank you.
>>> 
>>> Sorry for this very basic question, what's the best way to navigate back to
>>> where I was ?
>> 
>> Seems to me, you don't have a workflow yet for development in general through
>> Emacs. Because questions like "how to go to definition" and "how to go back"
>> aren't really specific to ELisp, it's something you'd use while working with
>> pretty much any language, be it C, Python, Haskell, C++, Rust… The only
>> question you asked specific to ELisp is about debugging ELisp code.
>
> Thank you Konstantin
>
> I guess that's the case, but I was not even asking for *debugging*, just to see
> how values change over the run of a piece of code. If *that* is called
> "debugging", there is a discoverability issue.
>
> I saw the EDE mode but even after reading its manual I was not sure how that
> could be put to use to ease work inside Emacs list code.
>
> So I guess I'll stick to edebug, M-. and M-, eldoc, highlight-defined,
> which-key, helpful. Right now they seem to be a good minimal setting for what I
> want to do.

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. 

A common 'development' pattern with lisp like languages is sometimes
referred to as "REPL driven development". This is where you
incrementally build up your code, running and testing small bits in the
REPL as you go. You can do things like execute single s-expressions to
see what value they return. This can be a really useful way to also
learn about a bit of code - essentially, you can 'explore' what each
statement does/returns.

Initially, you will probably need to add message statements to print out
variable values and state at various points in the code. However, as
your knowledge and confidence grows, you will find this less and less
necessary.

While having tools like edebug can be extremely useful, I don't think
focusing on them is a terribly useful approach. I find the debugger to
be the tool of last resort - I turn to it when I'm completely lost and
cannot work out why something is not working correctly. When you get to
that point, it can be invaluable. However, adopting a debugging approach
based around tracing code and stepping through it, watching variables
change etc is tedious and time consuming. Focus on the logic and
understanding/interpreting the code and documentation and I suspect you
will progress faster and find it more enjoyable. A few minutes scanning
and really understanding the code will often be much faster than
starting edebug, instrumenting functions and tediously stepping through
the code watching variables change. You may be surprised at how quickly
you develop the skill of being able to just look at a bit of code and
understand exactly what it does.

However, the most critical bit of advice I can give is 'just do it'.
Don't get too caught up in tools and workflows. Just get in there and
start writing code. Initially, it will probably be rubbish. However, the
process is crucial. You will learn more from sitting and trying to write
some code than you will from hours of scanning documents, manuals and
blog posts on how to develop. It is also through writing code you will
learn what you find to be the biggest 'pain points'. This will gide you
on what workflow and combination of tools/modes etc are best suited to
your needs. Without that knowledge, it can all be a bit too abstract and
overwhelming.