Thanks, that's what I meant by "see how to navigate between code and docs and keys", but was too lazy to type. :)

One important thing people should keep in mind, if they're starting only with Emacs navigation features for code and docs, is that they're missing crucial information that's in the manuals. One of the manuals is like a combination of the "API docs" you'll find in the docstrings, plus all the narrative around those, which you won't find in the docstrings. If a newbie is told only to browse docstrings and code, they're doing it on hard-mode.

And if a person makes sure they have the manuals installed (sadly, the Emacs Lisp manual(s) don't come installed by default in distros I've seen, which I think is a tragic mistake for uptake), and learns how load the manual in Emacs Info browser, and learns keys the Info keys like `i`, `s`, `[`, `]`, and `u`, I think they'll be glad they didn't try working from manuals in the Web browser.

Also, I wanted to start with making the code files more accessible and concrete, and generally tell people to try thinking differently about this. The reason is that I've suspected that a systemic barrier to accessible Emacs hacking was being created in the bureaucratic and obscuring direction things were going. (And it sounded like maybe this person was a victim of that suspected problem, since, when I started, it was much easier to get into, in the ways I described.)

(FWIW, I was able to write some Emacs extensions by starting with the approach I've suggested, including: https://www.neilvandyke.org/emacs/ )