RE: list of elisp primitives ?

[Drew Adams <drew.adams@oracle.com>]

> I'm trying ... to find a limited subset of
> functions that one can use to program in elisp
                                ^^^^^^^^^^^^^^^^
> and do non-trivial things but that do not
      ^^^^^^^^^^^^^^^^^^^^^
> involve searching the reference at all times.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's not what a list of subrs gives you, at all.
A subr is just a function coded in C, not in Lisp.
Likewise, for other things, such as variables,
that might be defined in C.

The choice of whether to implement something in C
has nothing to do with, and is no guide for, ease
in learning or how often something is used in
typical Elisp code.

And why do you think you need to search the
reference at all times?

> I'm thinking like in standard learners
> dictionaries, there are clear indications, like
> asterisks, that tell the learner whether the
> word is basic (generally about 2000 words) or
> intermediate (about 4000 words).
> 
> People who know the basic words can get by and
> express most of what they need to express in daily life.

Again, "basic" for a language learner has nothing
to do with how a given language construct is
implemented - in the case of Elisp, whether the
construct is implemented in C or Lisp.  Nothing
at all.

---

IMO, the biggest aid to learning Elisp is trying
to _do_ (program) something in Lisp.  Learning by
doing.

Yes, different people learn differently.  But
study combined with practice, in one form or
another, is pretty much the golden rule.

In the context of trying to do something with
Elisp, the biggest aid, in addition to doc (which
is not limited to the manual), is the source code.
Using what exists, to do more, is really what it's
about.  Free source code is a learner's friend, at
whatever level of learning.

And in that context, the apropos commands or,
better, a good completion system, can really help.

They help, in particular, because Elisp constructs
generally have names with relatively consistent
components.  If you don't have substring or
regexp completion, and you don't have progressive
completion (match multiple patterns, in any order),
then at least use apropos.

---

In my experience, the frequency of "needing" to
look something up in the Elisp reference is not
really greater when a beginner or a veteran.

As one witness, I've been using Elisp and the
reference for decades, and my use of the latter,
in terms of frequency, has been pretty much
constant over time.  I might study different
parts of it at different times, and I might
return to certain parts.  But it's not the case
that I looked stuff up in the reference more
when I was new to Emacs or Elisp.

That said, early on I did sit down sometimes and
just read through the manuals.  But I doubt that
most users proceed like that.  (I do that with
any product, especially one that has good doc.)

And in any case, that was not looking something
up; it was reading - for education and enjoyment.
If it helped learning then I imagine that was
mainly in the area of grasping concepts and
finding out what's available.

I'll also mention that I already knew Common
Lisp before coming to Emacs.  And in that case
too, I sat down and read CLTL, cover to cover.
Likewise, other Lisp dialects at the time.  But
learning to _use_ "basics" and non-basics of
the languages came mostly by doing, not reading.

---

Beyond subrs not helping to identify a list of
"basic" building blocks for learners, coming
up with any such list of constructs (ignoring
where they're implemented) is problematic, IMO.

What's basic for Lisp programming, in terms of
the _most commonly used_ constructs, could be
determined by counting (e.g. the distributed
source code).  But that information wouldn't
get you very far, I think.  

It might help more to know the frequency of
use _within each particular "area"_ of Emacs
use - buffers, windows, frames, overlays,
chars, font-lock, keymaps, syntax tables, etc.

The Elisp manual already gives you a general
idea of such frequency or relative importance,
by the fact that only a subset of existing
constructs (function, vars, etc.) are covered
in the reference.

But even then, a particular use case might
call for frequent use of constructs that
aren't prominent, or even present, in the
manual.

Letting doing lead look-up is, again, the
best approach.  The manual can't know what
you're trying to do in any particular case;
it has to be a compromise, intended to fit
most use cases and most users.