bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26658: 25.2; cc-mode doesn't use prog-mode-map as parent for c-mode-


From: Vasilij Schneidermann
Subject: bug#26658: 25.2; cc-mode doesn't use prog-mode-map as parent for c-mode-base-map
Date: Sun, 7 May 2017 15:58:34 +0200

> It doesn't seem to be quite right in the way it handles XEmacs stuff,
> but I don't think it's possible to be "right" here, at least not
> sensibly.  If this patch were to be applied to standalone CC Mode, it
> would test (derived-mode-p 'prog-mode) before calling
> (c-set-keymap-parent c-mode-base-map prog-mode-map).  prog-mode does not
> exist in XEmacs, and is unlikely ever to exist there.
> 
> But this code is purely for Emacs.  What do you think?

Hm, I don't really have a way to test this in XEmacs anyway.  Testing
for prog-mode sounds like a good idea, but will the above example do the
right thing?  The issue with `derived-mode-p` is that it works upon the
*current* major mode instead of accepting a major mode to test against
other major modes.  What is the current major mode when this line is
evaluated?  Wouldn't it make more sense to use (boundp 'prog-mode-map),
considering that we're using the variable, not the mode?

> For the commit message, the format is to aim for a complete first line
> which makes sense on its own.  (It's a sentence, but without a
> terminating full stop.)  So something like this would do:
> 
> #########################################################################
> Make prog-mode-map the keymap parent of c-mode-base-map
> 
> Fixes bug #26658.
> 
> * lisp/progmodes/cc-mode.el (c-set-keymap-parent): New function
> extracted from c-make-inherited-keymap.
> (c-mode-base-map): .......
> 
> #########################################################################
> 
> Note that the path is given before "cc-mode.el".
> 
> Do you have commit access to the Emacs repository?

No and I doubt I'll ever get it because I don't understand the commit
message rules at all.  They appear to be loosely based upon GNU
changelog guidelines, but with everyone I send patches to interpreting
them differently, probably because there isn't much substance to them in
the first place.  I've resorted to using M-x add-change-log-entry,
copying the result into the commit message and adjusting it describing
my changes, but there's apparently more to it than that.

Anyway, here's an updated patch.

Attachment: 0001-Make-prog-mode-map-the-parent-of-c-mode-base-map.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]