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: Fri, 18 Apr 2014 18:23:24 -0700 (PDT) [thread overview]
Message-ID: <80d0879e-b71f-49c0-8384-9108d5cdd4dc@googlegroups.com> (raw)
In-Reply-To: <38d1beb3-fffd-4718-ae10-be9646ac4a63@googlegroups.com>
On Fri, Apr 18, 2014 at 4:47 PM, Nicolas Richard wrote:
> Hans BKK writes:
>> On Fri, Apr 18, 2014 at 11:27 AM, Nicolas Richard
>>> Some symbols are just symbols. every time the lisp reader reads
>>> something, symbols are interned.
>>>
>>> Currently I have 76920 symbols in obarray.
>>
>> Aha. OK, so those "just symbols" can go to dev null.
>
> I don't know what that should mean.
I meant that after my code selects for display those symbols likely to
be of interest, I can leave the final "(t" case to simply not list
those likely to be irrelevant to my purpose.
> ;; the intersecton of the two previous sets:
> (yf/count-symbols (lambda (x) (and (fboundp x) (boundp x))))
> => 792
> (there's obviously some overlapping with bound and fbound symbols)
Yes, I'm testing for function first as I consider that primary.
Strange (to me) that such a high % of functions have no associated
value.
> FWIW, here's the yf/count-symbols that I used:
> (defun yf/count-symbols (&optional predicate)
> (let ((count 0))
> (mapatoms
> (lambda (x)
> (when (or (not predicate)
> (funcall predicate x))
> (incf count))))
> count))
cool - thanks
>> Question remains - how to separate out and ID - in the absence of a
>> predicate - any that actually may be of interest remaining in my
>> current "other" - which I presume macros should be, and having got
>> code for keymaps already above.
>
> macros are fboundp.
> (defmacro asymbollikenoother () t)
> (fboundp 'asymbollikenoother)
yes, but I'm looking for a way to ID them specifically within the
fbound cond rather than having them lumped in with the final (t
"other" grouping:
(cond
((fboundp sym) ; ALL functions
(cond
((commandp sym)
(cond
((keymapp sym)
(princ "=======\n")
(princ "\n")
(princ "command - keymap:\t\t\t\t\t")
(prin1 sym)
(princ "\n\n"))
((subrp (symbol-function sym))
(princ "=============================\n")
(princ "command - built-in primitive:\t\t")
(prin1 sym)
(princ "\n\n"))
((byte-code-function-p (symbol-function sym))
(princ "====================\n")
(princ "command - byte-code:\t\t\t")
(prin1 sym)
(princ "\n\n"))
((functionp sym)
(princ "================\n")
(princ "command - elisp:\t\t\t")
(prin1 sym)
(princ "\n\n"))
(t
(princ "===============\n")
(princ "other command:\t\t\t\t")
(prin1 sym)
(princ "\n\n"))
)
)
(t ; (non-command) functions
(cond
((keymapp sym)
(princ "==================\n")
(princ "\n")
(princ "function - keymap:\t\t\t\t")
(prin1 sym)
(princ "\n\n"))
((subrp (symbol-function sym))
(princ "==============================\n")
(princ "function - built-in primitive:\t\t")
(prin1 sym)
(princ "\n\n"))
((byte-code-function-p (symbol-function sym))
(princ "=====================\n")
(princ "function - byte-code:\t\t\t")
(prin1 sym)
(princ "\n\n"))
((functionp sym)
(princ "=================\n")
(princ "function - elisp:\t\t\t")
(prin1 sym)
(princ "\n\n"))
(t
(princ "=============================\n")
(princ "other ~function (macros +??):\t")
(prin1 sym)
(princ "\n\n"))
)
>> Thanks for that, looks useful. But looks to only pick up those
>> starting with the package string?
>
> That was the idea, yes. Most packages are namespaced that way, those
> that aren't probably should not exist in an ideal world ;)
I wish we lived in such a place 8-)
>> And I think apropos only displays a
>> limited subset, e.g. only Customized variables? and/or only those with
>> docstrings?
>
> C-h f a p r o p o s RET
> =>
> Show all meaningful Lisp symbols whose names match PATTERN.
> Symbols are shown if they are defined as functions, variables, or
> faces, or if they have nonempty property lists.
Note that in any given state,
(apropos-variable "." t)
shows much fewer results than the auto-completion listing from
M-x describe-variable
Since I'm only looking at the diff, the changes made by activating a
given feature or package, it doesn't matter if there's a lot of
less-meaningful kruft as long as it's kruft that doesn't change.
next prev parent reply other threads:[~2014-04-19 1:23 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 [this message]
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
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=80d0879e-b71f-49c0-8384-9108d5cdd4dc@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.