Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!wilber From: wilber@alice.UUCP (Bob Wilber) Newsgroups: comp.emacs Subject: Re: speeding up describe-mode Keywords: gnus calendar Message-ID: <10323@alice.UUCP> Date: 10 Jan 90 03:26:07 GMT References: <10316@alice.UUCP> Reply-To: wilber@homxb.att.com Organization: AT&T, Bell Labs Lines: 33 I wrote: >...[About how the C code for describe mode uses a slow algorithm.] Dave Lawrence (tale@cs.rpi.wdu) responded: >Ok, now since you've described the underlying reason for it, I'll >elaborate a little more. (Heck, I didn't even understand you the first >time I read it and I supposedly know what you're talking about. :-) > >As of GNUS 3.12, one of the packages mentioned in the original keywords >as exhibiting the problem, the speed has been greatly increased at the >loss of some Ultimate Accuracy In Advertising. >... >GNUS 3.12 has sped up the process by taking out the vast majority of \\[] >substitutions intended for substitute-command-keys, leaving it only for >those not bound by default and putting in the default bindings for the >rest. If the bindings change then this loses, but for 99 44/100 % of the >time it will be true enough. Under the circumstances this was a reasonable work-around, but it also illustrates that when a useful feature is implemented too inefficiently, people won't use it. The whole point of \\[] substitutions is to ensure that what comes up in the *Help* window conforms to reality, particularly in the 56/100 % of the cases where the bindings are non-standard. Of course this is most needed in modes that do a lot of key rebindings, which tend to have the most \\[] substitutions, which are therefore the modes where the slowness of describe-mode is most serious, and are therefore the modes where the programmer is most likely to forsake the use of \\[] altogether. Sigh. If I get *real* ambitious I might try fixing up describe mode myself, but I'm no Emacs mage and there's lots of stuff in the code I don't understand so well, so it's not going to happen anytime soon. Bob Wilber wilber@homxb.att.com