Re: [PATCH] Fix disabled-command-hook must be disabled-command-hook

nix> In any case, surely speeding up the Lisp evaluator is a nix> better target than reducing the use of Lisp? Speeding up Lisp is extremely hard. Funcalls are necessarily expensive. It's possible to use a different evaluation model (eg, that of Scheme; Michael Sperber has a colleague with a large subset of Emacs Lisp implemented in Scheme, and preliminary results are that it is no slower than native XEmacs Lisp). But even then, native Scheme funcalls are much slower than those in C. I think the only hope for writing redisplay in Lisp is a decade of Moore's law (or the return of the Lisp machine ;-). nix> If the bytecode compiler and eval layers were smarter, we'd nix> hopefully not have to *care* about the potential speed impact nix> of Lisp. Not likely. The byte-compiler already takes incorrect shortcuts in several places. Basically Martin ran out of correct optimizations, and continued to "optimize" anyway. It would be possible to use declarations to do somewhat better (eg, if you could be sure variables were integers and not floats, characters, or markers, you could byte-compile to compiled CCL with a dramatic speedup -- except that the CCL engine is noticably more buggy than most of the rest of XEmacs, as befits one of the few parts of Mule that Ben and Martin haven't touched). Smarter isn't good enough, I think you need to rip it out by the roots. nix> And the fact that specifiers of all kinds do that has nix> rendered what could be a useful generic metavariable type nix> useless for every single purpose I'd otherwise have had for nix> it; specifiers are, IMHO, essentially useless except for nix> display frobbery, mainly because of that. And a useful generic metavariable would be useless for display frobbery, mainly due to lack of that. I'm not opposing introduction of generic metas, but I doubt they could replace specifiers where specifiers are useful. But as far as I can tell, the only non-display aspect of specifiers that would be useful is already covered by the (long-implemented) buffer-local variables. To be really useful, a generic variable would implement (for example) the kind of functionality that we currently use "auto-.*-alists" for, no? Or am I completely missing what you have in mind? I guess we'll see when you post the patch, huh? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.