On 19 Jan 2002, Jan Vroonhof yowled: :) I spotted it about half a year ago and never bothered to follow it up. No point, I've done it already :) I hope not, 'cos I've just blown the lid off their evil plans :) It looks more like a straight typo to me. Anyway, the bug is that, in command_execute(), the hook is run by passing the *variable* to run_hook(), not the symbol pointing at the variable. So the symbol is evaluated, then *the name that's in a symbol with that name* is run. If the function in `disabled-command-hook' has the same name as the hook variable, this is invisible; it just goes round twice. But if you change it it breaks. Patch (against 21.4; applying to 21.5 would doubtless be easy but I haven't produced the diff for that yet): 2002-01-18 Nix <nix(a)esperi.demon.co.uk&gt; * event-stream.c (Qdisabled_command_hook): New variable. * cmdloop.c (syms_of_cmdloop): Initialize it. * lisp.h (constant symbols): Prototype it. * eval.c (command_execute): Call hook using it, not using Vdisabled_command_hook. diff -durN 21.4.6-orig/src/cmdloop.c 21.4.6/src/cmdloop.c --- 21.4.6-orig/src/cmdloop.c Mon Jul 23 15:10:21 2001 +++ 21.4.6/src/cmdloop.c Thu Jan 17 14:19:18 2002 ＠＠ -610,6 +610,7 ＠＠ defsymbol (&Qreally_early_error_handler, "really-early-error-handler"); defsymbol (&Qtop_level, "top-level"); defsymbol (&Qerrors_deactivate_region, "errors-deactivate-region"); + defsymbol (&Qdisabled_command_hook, "disabled-command-hook"); #ifndef LISP_COMMAND_LOOP DEFSUBR (Frecursive_edit); diff -durN 21.4.6-orig/src/eval.c 21.4.6/src/eval.c --- 21.4.6-orig/src/eval.c Mon Aug 6 13:56:12 2001 +++ 21.4.6/src/eval.c Thu Jan 17 14:16:14 2002 ＠＠ -2946,7 +2946,7 ＠＠ debug_on_next_call = 0; /* #### from FSFmacs; correct? */ if (SYMBOLP (cmd) && !NILP (Fget (cmd, Qdisabled, Qnil))) - return run_hook (Vdisabled_command_hook); + return run_hook (Qdisabled_command_hook); for (;;) { diff -durN 21.4.6-orig/src/event-stream.c 21.4.6/src/event-stream.c --- 21.4.6-orig/src/event-stream.c Tue Jan 15 11:22:10 2002 +++ 21.4.6/src/event-stream.c Thu Jan 17 14:29:56 2002 ＠＠ -135,7 +135,7 ＠＠ /* Non-nil disable property on a command means do not execute it; call disabled-command-hook's value instead. */ -Lisp_Object Qdisabled, Vdisabled_command_hook; +Lisp_Object Qdisabled, Qdisabled_command_hook, Vdisabled_command_hook; EXFUN (Fnext_command_event, 2); diff -durN 21.4.6-orig/src/lisp.h 21.4.6/src/lisp.h --- 21.4.6-orig/src/lisp.h Mon Jan 7 14:17:41 2002 +++ 21.4.6/src/lisp.h Thu Jan 17 14:14:05 2002 ＠＠ -3198,7 +3198,7 ＠＠ extern Lisp_Object Qcrlf, Qcurrent_menubar, Qctext; extern Lisp_Object Qcyclic_variable_indirection, Qdecode; extern Lisp_Object Qdefun, Qdevice_live_p; -extern Lisp_Object Qdim, Qdisabled, Qdisplay_table; +extern Lisp_Object Qdim, Qdisabled, Qdisabled_command_hook, Qdisplay_table; extern Lisp_Object Qdomain_error; extern Lisp_Object Qediting_error; extern Lisp_Object Qencode, Qend_of_buffer, Qend_of_file, Qend_open; -- `I personally would not stand in a river waving a graphite rod above my head during a thunderstorm.' --- Harry Jackson

On Sat, 19 Jan 2002, Hrvoje Niksic uttered the following: What can I say but `it doesn't seem to' :) (Note that there was *no* Qdisabled_command_hook variable present; I don't know if this would break that tying because I don't know how the tying works :) ) -- `I personally would not stand in a river waving a graphite rod above my head during a thunderstorm.' --- Harry Jackson

On 19 Jan 2002, Jan Vroonhof said: Ah, battling patches! :) (not that it matters, our patches are damn-near identical...) It worked because the value of disabled-command-hook was `disabled-command-hook'; run_hook_with_args_in_buffer() looked up the value of the symbol in the disabled-command-hook (which was put in there for the value in its function cell!) and then funcalled the car of that. So it only worked if the function had the same name as the hook... (Next on my list: a bizarre attempt at OO in xemacs lisp with which I hope to replace a bunch of *-magic types, specifiers and the rest of it, for the cost of one new type and some evaluator enhancements[1]. Still designing. I'll stick the design on xemacs-beta when I can no longer punch holes in it and everyone can laugh at me and call me a madman.) [1] well, I can only do this if it's now safe to call Lisp from redisplay; IIRC after (Ben's?) error-handling-in-redisplay fixes from a few months back, it's now sort of safe. The enhancements are things like support for read in other obarrays (multiple of them at once :) ), symbols interned in multiple obarrays and other such stuff. -- `I personally would not stand in a river waving a graphite rod above my head during a thunderstorm.' --- Harry Jackson

On Sun, 20 Jan 2002, Andy Piper yowled: Great, this is a proof of concept for now so speed is less important. I can speed it up later, if it actually works. :) (I don't expect to be calling *much* from redisplay, anyway; but equally I don't really want the system to explode because I've called a few things, either.) -- `I personally would not stand in a river waving a graphite rod above my head during a thunderstorm.' --- Harry Jackson

On Mon, 21 Jan 2002, Andy Piper yowled: If we took that route to its logical conclusion, we'd end up with a completely non-extensible editor. The more that Lisp is called, the more places users can customize and extend XEmacs. This was, I thought, part of the point of XEmacs. :) (In any case, surely speeding up the Lisp evaluator is a better target than reducing the use of Lisp? If the bytecode compiler and eval layers were smarter, we'd hopefully not have to *care* about the potential speed impact of Lisp.) And the fact that specifiers of all kinds do that has rendered what could be a useful generic metavariable type useless for every single purpose I'd otherwise have had for it; specifiers are, IMHO, essentially useless except for display frobbery, mainly because of that. -- `I personally would not stand in a river waving a graphite rod above my head during a thunderstorm.' --- Harry Jackson :

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.