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: Wed, 23 Apr 2014 06:22:56 -0700 (PDT) Message-ID: <1f43a0af-3c1c-4b29-9e56-36d13f1d0900@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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1398259531 14449 80.91.229.3 (23 Apr 2014 13:25:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2014 13:25:31 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 23 15:25:24 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 1WcxAy-0007XC-0H for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Apr 2014 15:25:24 +0200 Original-Received: from localhost ([::1]:32808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcxAx-0006id-In for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Apr 2014 09:25:23 -0400 X-Received: by 10.236.197.39 with SMTP id s27mr23367489yhn.36.1398259377208; Wed, 23 Apr 2014 06:22:57 -0700 (PDT) X-Received: by 10.182.204.42 with SMTP id kv10mr27023obc.33.1398259377010; Wed, 23 Apr 2014 06:22:57 -0700 (PDT) Original-Path: usenet.stanford.edu!cm18no5611450qab.0!news-out.google.com!gi6ni598igc.0!nntp.google.com!l13no10030944iga.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:81db:f077:ec84:39f6; posting-account=IUdGewoAAACF9WtA3i8stuVyXNk2FqaH Original-NNTP-Posting-Host: 2602:306:334f:a5e0:81db:f077:ec84:39f6 User-Agent: G2/1.0 Injection-Date: Wed, 23 Apr 2014 13:22:57 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:205062 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:97328 Archived-At: 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/consumer= ist one currently marching across the globe, which, once you're aware of al= ternatives, 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 l= anguage 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 al= pha-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 fun= ction that runs against any arbitrary customized emacs to enable A-B compar= isons 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 op= tion. > > 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 give= n 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 categ= ories, apparently icicles uses a type I didn't come across in my testing, s= o far only against plain vanilla. See the "when" conditions testing for the presence (non-voidness) of a symb= ol'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 th= e 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 actuall= y 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