Dynamically deriving major mode from prog-mode or fundamental-mode

Dominik Honnef writes: The only reason I can imagine this working in GNU is that prog-mode is always available. Or maybe they've had enough people try it that they decided to put in a total hack that dereferences the function cell of the mode symbol and checks if it's a symbol naming a mode, in which case it doesn't treat it as a function but as a mode name. Why do I say this is a hack? Because this doesn't create a full mode. Why not check the value cell (as well or instead of, in either case you lose because you haven't done it)? What's the right thing to assume about the syntax table, keymap, and hooks? What if you pass it to some code that tries to access those things? Brian Palmer writes: The basic point (use `define-derived-mode') is correct, but it's a bad idea to redefine public symbols (even if they only exist in the future or in an "alternate reality" :-) this way. It's a very bad idea to do it in widely distributed library code. Your immediate problem is that this defuns prog-mode, and you need more junk to do the extra work needed when deriving go-mode from fundamental mode. You can probably get around it with an if (as in my suggestion below), but even so it's kind of ugly. The really big problem problem is that your prog-mode pollutes the name-space (there's only one...) and will confuse other modes that hack around XEmacs's lack in the same way. I recommend: (if (fboundp 'prog-mode) (define-derived-mode go--prog-mode prog-mode) (define-derived-mode go--prog-mode fundamental-mode) ;; Add prog-mode features needed by go-mode here. ) Yes, but not as a place-holder, please, for the same reason as above. Dominik Honnef writes: That's what it should do. Mode symbols are just symbols with special conventions for the use of function and value cells, and properties. Ah, but defalias makes go--prog-mode point to fundamental-mode as a *function*, not as a variable or mode. I can understand why you might think it should work as a mode symbol, but XEmacs is philosophically opposed to the kind of hack that would make it work. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta