Emacspeak discussion list

[Robert Melton <lists AT robertmelton.com>]

Raman--

Thanks for the tips!  Some more comments inline below. 

> 1. +1 on learning the org bits;
> 2. See the emacspeak blog article on taking smart notes.

https://emacspeak.blogspot.com/2022/10/learn-smarter-by-taking-rich-hypertext.html

The above post was a great read, and between you and Tim I really think I am 
incredibly underusing bookmarks. 


> 3. What exactly do you mean by "folding" -- there are multiple ways of
>   doing that.
> 4. Good to know you hate the experience, but pointless you saying say
>   so without saying why you "hate" it.
> 5. In general, it's not worth hating things --- at least in your tools,
>   use what works for you, ignore the rest.

I laughed out loud, fair enough.  I was posting here after getting frustrated 
with yafolding, outline-mode, origami and a few others.  I had search issues 
and sometimes with origami even issues reopening folds, which seemed 
incredibly odd.  I guess the way I cam away on this was "the juice isn't 
worth  the squeeze". 


> 6. See the blog articles I posted over the  holidays.

They were great!  I actually discovered comint from them and I built my 
own little interface to an "Apple Reminders" CLI app. 


> 7. Read "How to ask questions the smart way" by ESR --it'll make a
>   difference to the responses you generate.

Read it last time you linked it, wasn't lack of knowledge, was a missive 
sent off in a state of generalized frustration with the incredibly obtuse 
and undocumented codebase I am working on. Not an excuse, also, 
the amount of things I randomly tried was far too long a list to call out.
In the end, I think I fell into the trap of "if you don't want to deal with 
the problem make a new more tractable problem!"  ---  Hence dug in 
on tools which no matter how good can't save you from poorly written
codebase.  


> 8. Use emacs' xref and eglot integration to advantage

This with the Python LSP that mostly can grok the project is all that has 
kept me sane thus far. 


> 9. Chase down the author of the code and see if they have a design-doc.
> 10. If they dont, then write one as you understand their code, it'll
>    help the project as well as you.

This is a great point, and I have actually touched base with the client and 
gotten this work pulled into the scope. Will take a bit to understand the 
original authors intent, but not sure I could leave something more valuable
behind for the next person. 


> 11. Depending on the language, exercise your understanding by writing tests.
> 12. All of the above are good software engineering practice; emacs is a
>    tool that helps you do those well --- or poorly depending on how
>    well you know to use your tools.
> 

Absolutely, every time I dig around the Emacspeak codebase and build system 
I learn a little more.  But still learning all the dials and levers, I have 
just scratched
the surface of all the features built into Emacs, and only started recently 
doing any
non-trivial customizations. 


--
Robert "robertmeta" Melton
lists AT robertmelton.com