Re: Generating a listing of all symbols (16K+) and labeling subsets

[florian@fsavigny.de (Florian v. Savigny)]

  > Exploring the code and resulting output has been a decent learning exercise in its own right.

I thought so. Even if -- worst case -- you end up saying that your
work has not been useful /at all/, you should have learned a good deal
about what symbols are, which is useful knowledge when you program in
elisp. (Efficiency, of course, is another matter.) I think a lot of
unorthodox approaches do not succeed, but if you do have the time,
there is nothing to suggest that there is no value in trying them out.

I could imagine that much of the veteran response is due to the
entirely natural and inevitable fact that the more experienced you
get, the older you necessarily get, and the older you get, the less
time you want to waste. (And, of course, the better you know how not
to waste it.) IOW, usefulness and efficiency are naturally developing
criteria. But they are not, as you have suggested, part of a dogma.

  > Any and all feedback welcome.

OK, I'll take that literally, because I am not sure I have completely
understood the purpose of your package:

If you have icicle-mode, apparently, list-hh-symbols fails:
"Symbol's function definition is void: cycle-icicle-image-file-thumbnail".

Thus, I have tried your function with emacs -q --no-site-file, and got
a buffer of some 100K lines. I understand your intention is to diff
it, rather than browse it with your eyes, but then it would seem to me
the docstrings are not of much value, as I should think customisation
would not normally change them.

Also, is it practical to order them alphabetically, rather than, say,
by file from which they were loaded? As has been mentioned elsewhere,
most packages are "namespaced" by prefixing all their symbols with a
unique ID -- which should keep the symbols from one package together
in an alphabetical listing -- but that is not true for all of them (I
seem to recall some very fundamental ones.)

Are you intending to enable different kinds of listings? Scoping and
different kinds of ordering would seem important to me to make such
"reports" manageable.

What about customisations that advise existing functions, or even
redefine them?

  > Will likely kill the final "(t / leftovers / other (misc) symbol"
  > bucket if it's true changes in that category are unlikely to be of
  > interest.

Whatever, there are a lot of "other (misc) symbol" entries all through
the listing, which do not at all look informative to me. (And a lot of
which, frankly, amaze me. But this is probably due to my limited
understanding of Elisp.) But who knows. Maybe it is sometimes
informative to simply know whether a symbol exists or not.

The challenge for you is to test your function in real life, and
demonstrate inhowfar it helps you to understand some given
customisation. Icicle-mode, for one, is a customisation that seems
impressive, but at the same time changes a lot of behaviour I was used
to. ;-)

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld