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

[Hans BKK]

On Wed, Apr 23, 2014 at 3:40 AM, Florian v. Savigny wrote:
> 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.

I beg to differ - most cultures in the world don't put a material value on 
their time with quite the same desperation as the western/material/consumerist 
one currently marching across the globe, which, once you're aware of 
alternatives, makes them IMO much more pleasant to live within.

Thanks very much for "wasting" the time with your response though Florian 8-)


> 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.

Just to save me looking them up when scanning the diffs.


> 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?

I think maybe you missed my very first statement of confession:
>> Total noob here - and non-programmer to boot, as will become immediately 
>> apparent from the code below - so please be gentle.

I've done a little batch file/macro coding but never worked with a proper 
language before, so my abilities to do any of this are very limited. Have no 
idea what scoping is, nor what "advising" a function might mean. Simple 
alpha-ordering is what was in the "list-options.el" code I based this on, so 
from my POV it certainly was "practical" to leave it that way.

Plus, it does seem to best further the goal of having a single standard 
function that runs against any arbitrary customized emacs to enable A-B 
comparisons with vanilla or a differently-customized one.

I would of course be very happy if anyone wants to refactor this to have it 
make more sense for their purposes, ideally keeping this ordering as an option.

>   > 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.

Yes if nothing else I'm sure it will help me in trying to understand a given 
package's source code.


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

This message was very common as I was working on the different symbol 
categories, apparently icicles uses a type I didn't come across in my testing, 
so far only against plain vanilla.

See the "when" conditions testing for the presence (non-voidness) of a symbol's 
attribute before trying to query/output the value.

Perhaps this one is defined as "fboundp" but doesn't actually have a value in 
the function cell? I would have thought that wasn't even possible.


> Icicle-mode, for one, is a customisation that seems impressive, but at the 
> same time changes a lot of behaviour I was used to. ;-)

Well I certainly won't have that problem since I haven't started to actually 
use emacs yet, in the sense of actually editing any text with it. 8-)

Icicles-specific question, as opposed to Helm, here:
https://groups.google.com/forum/#!topic/gnu.emacs.help/GSa1bqSKe9E