Hi, I'm the author of the (rewritten) go-mode and am trying to keep it compatible with XEmacs. One particular problem I am facing right now is that GNU Emacs 24 offers prog-mode to derive from, while older GNU Emacs and Xemacs do not. So for those, I want to derive from fundamental-mode instead. The way I initially solved it for GNU Emacs was with an alias a la > (defalias 'go--prog-mode > (if (fboundp 'prog-mode) 'prog-mode 'fundamental-mode)) which I then used in the mode definition: > (define-derived-mode go-mode go--prog-mode "Go" In GNU Emacs, this works fine. XEmacs, however, apparently tries to inherit the keymap from go--prog-mode, instead of what it points to (in this case fundamental-mode), which results in the following error when trying to invoke go-mode: > Debugger entered--Lisp error: (wrong-type-argument keymapp nil) > set-keymap-parents(#<keymap size 6 0xf5> (nil)) > (if (keymap-parent go-mode-map) nil (set-keymap-parents go-mode-map (list ...))) > (unless (keymap-parent go-mode-map) (set-keymap-parents go-mode-map (list ...))) > (progn (if (get ... ...) (put ... ... ...)) (unless (keymap-parent go-mode-map) (set-keymap-parents go-mode-map ...)) (derived-mode-merge-syntax-tables (syntax-table) go-mode-syntax-table)) > (let ((delay-mode-hooks t)) (go--prog-mode) (setq major-mode (quote go-mode)) (setq mode-name "Go") (progn (if ... ...) (unless ... ...) (derived-mode-merge-syntax-tables ... go-mode-syntax-table)) (use-local-map go-mode-map) (set-syntax-table go-mode-syntax-table) (set$ > (progn (make-local-variable (quote delay-mode-hooks)) (let (...) (go--prog-mode) (setq major-mode ...) (setq mode-name "Go") (progn ... ... ...) (use-local-map go-mode-map) (set-syntax-table go-mode-syntax-table) (setq local-abbrev-table go-mode-abbrev-table) (set ... .$ > (delay-mode-hooks (go--prog-mode) (setq major-mode (quote go-mode)) (setq mode-name "Go") (progn (if ... ...) (unless ... ...) (derived-mode-merge-syntax-tables ... go-mode-syntax-table)) (use-local-map go-mode-map) (set-syntax-table go-mode-syntax-table) (setq local-ab$ > (lambda nil "Major mode for editing Go source text.\n\nThis mode provides (not just) basic editing capabilities for\nworking with Go code. It offers almost complete syntax\nhighlighting, indentation that is almost identical to gofmt and\nproper parsing of the buffer con$ > call-interactively(go-mode) > command-execute(go-mode t) > execute-extended-command(nil) > call-interactively(execute-extended-command) > (dispatch-event "[internal]") I can only suspect that the keymap won't be the only issue, but also hooks etc. What I am wondering is, if using an alias is not an option, how else could I derive the mode from prog-mode or fundamental-mode, depending on what's available? Cheers, Dominik Honnef _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Dominik Honnef writes: > The way I initially solved it for GNU Emacs was with an alias a la > > > (defalias 'go--prog-mode > > (if (fboundp 'prog-mode) 'prog-mode 'fundamental-mode)) > > which I then used in the mode definition: > > > (define-derived-mode go-mode go--prog-mode "Go" > > In GNU Emacs, this works fine. 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.

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. ) > (It probably makes sense to have prog-mode added to xemacs, too, no? Even > if just as a place-holder). Yes, but not as a place-holder, please, for the same reason as above.

Dominik Honnef writes: > XEmacs, however, apparently tries to inherit the keymap from > go--prog-mode, That's what it should do. Mode symbols are just symbols with special conventions for the use of function and value cells, and properties. > instead of what it points to (in this case fundamental-mode), 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.

Dominik Honnef writes: > For what it is worth, go-mode does not depend on any behaviour set up by > prog-mode – and there's generally not much that prog-mode does, its whole > definition fits into 20 lines of code. OK, so let's Just Do It, then. The existence of prog-mode doesn't mean we have to fix all of our other modes to use it immediately, it seems. If you want to help with that, you could try pulling GNU's prog-mode into your XEmacs load-path (in a new file if "prog-mode.el" doesn't exist), and see if anything horrible happens.

You could even take control of the situation by becoming the prog-mode maintainer for the XEmacs package system. This amounts to

>>>> Sean MacLennan <seanm(a)seanm.ca&gt; writes:

I am interested in go-mode. If Dominik can get prog-mode/go-mode working in XEmacs, I am will to do the maintenance work.

>>>>> Mats Lidell <matsl(a)xemacs.org&gt; writes: > I suggest adding prog-mode.el to the packages. A quick look in the GNU Emacs code reveals that prog-mode is defined in simple.el in core next to fundamental-mode. Maybe we should just do the same an have it in core? Views?

On Sat, 30 Mar 2013 09:04:04 +0900 "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote:

> If we put it in xemacs-base, it will have the same effect (if you're > missing xemacs-base, XEmacs turns into a better Notepad ;-), and we > only have to maintain it once, and Vin doesn't need to make any > decisions about it.

I would also prefer xemacs-base since then it would work with 21.4.

I honestly couldn't tell if "anything horrible happens". My interactions with XEmacs are limited to ensuring that go-mode works in it. Apart from that I do not use XEmacs.

> You could even take control of the situation by becoming the prog-mode > maintainer for the XEmacs package system. This amounts to I think maintaining it should be left to someone who is actually involved/familiar with XEmacs :-)