From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans BKK Newsgroups: gmane.emacs.help Subject: Re: Generating a listing of all symbols (16K+) and labeling subsets Date: Fri, 18 Apr 2014 18:23:24 -0700 (PDT) Message-ID: <80d0879e-b71f-49c0-8384-9108d5cdd4dc@googlegroups.com> References: <38d1beb3-fffd-4718-ae10-be9646ac4a63@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1397870726 29797 80.91.229.3 (19 Apr 2014 01:25:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Apr 2014 01:25:26 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Apr 19 03:25:19 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WbK1u-0007zg-FR for geh-help-gnu-emacs@m.gmane.org; Sat, 19 Apr 2014 03:25:18 +0200 Original-Received: from localhost ([::1]:40558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbK1u-0005OG-3I for geh-help-gnu-emacs@m.gmane.org; Fri, 18 Apr 2014 21:25:18 -0400 X-Received: by 10.236.188.134 with SMTP id a6mr10655928yhn.11.1397870605228; Fri, 18 Apr 2014 18:23:25 -0700 (PDT) X-Received: by 10.182.97.195 with SMTP id ec3mr94obb.30.1397870604845; Fri, 18 Apr 2014 18:23:24 -0700 (PDT) Original-Path: usenet.stanford.edu!cm18no4178690qab.0!news-out.google.com!gi6ni537igc.0!nntp.google.com!c1no361984igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: <38d1beb3-fffd-4718-ae10-be9646ac4a63@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2602:306:334f:a5e0:34d6:6f1d:10e2:9ffb; posting-account=IUdGewoAAACF9WtA3i8stuVyXNk2FqaH Original-NNTP-Posting-Host: 2602:306:334f:a5e0:34d6:6f1d:10e2:9ffb User-Agent: G2/1.0 Injection-Date: Sat, 19 Apr 2014 01:23:24 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:204945 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:97210 Archived-At: 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.