From: Hans BKK <hansbkk@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Generating a listing of all symbols (16K+) and labeling subsets
Date: Wed, 23 Apr 2014 06:22:56 -0700 (PDT) [thread overview]
Message-ID: <1f43a0af-3c1c-4b29-9e56-36d13f1d0900@googlegroups.com> (raw)
In-Reply-To: <38d1beb3-fffd-4718-ae10-be9646ac4a63@googlegroups.com>
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
next prev parent reply other threads:[~2014-04-23 13:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-18 5:15 Generating a listing of all symbols (16K+) and labeling subsets Hans BKK
2014-04-18 19:01 ` Hans BKK
2014-04-18 20:47 ` Nicolas Richard
2014-04-19 1:23 ` Hans BKK
2014-04-19 2:16 ` John Mastro
2014-04-19 2:25 ` Hans BKK
2014-04-19 2:50 ` Hans BKK
2014-04-19 4:24 ` Drew Adams
2014-04-19 20:15 ` Hans BKK
2014-04-23 4:11 ` Hans BKK
2014-04-23 7:40 ` Florian v. Savigny
[not found] ` <<874n1klchv.fsf@bertrandrussell.Speedport_W_723V_1_32_000>
2014-04-23 15:07 ` Drew Adams
2014-04-23 13:22 ` Hans BKK [this message]
2014-04-24 2:30 ` Hans BKK
-- strict thread matches above, loose matches on Subject: below --
2014-04-18 2:34 hansbkk
2014-04-18 2:09 hansbkk
2014-04-18 7:19 ` Thien-Thi Nguyen
2014-04-18 10:09 ` Thorsten Jolitz
[not found] ` <mailman.19825.1397815734.10748.help-gnu-emacs@gnu.org>
2014-04-18 15:00 ` Hans BKK
[not found] ` <mailman.19813.1397805348.10748.help-gnu-emacs@gnu.org>
2014-04-18 14:55 ` Hans BKK
2014-04-18 15:27 ` Nicolas Richard
2014-04-19 16:34 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f43a0af-3c1c-4b29-9e56-36d13f1d0900@googlegroups.com \
--to=hansbkk@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.