[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21465: [PATCH] CC-modes hierarchy
From: |
Alan Mackenzie |
Subject: |
bug#21465: [PATCH] CC-modes hierarchy |
Date: |
Mon, 7 Sep 2020 20:03:42 +0000 |
Hello, Lars.
On Mon, Sep 07, 2020 at 18:52:00 +0200, Lars Ingebrigtsen wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > You already have this layer, with c-mode-common-hook and
> > c-mode-base-map. My patch just makes this layering more standard and
> > then takes advantage of it to share some code.
> > Here's another version of the patch with the following changes:
> > - Got rid of c-derivative-mode (which I still use at other places in my
> > local patches, but for now, I won't push for it any more).
> > - Keep c-make-inherited-keymap for backward compatibility.
> > - Fix the "c-mode-hook is run twice" bug, using the same hack as is used
> > by define-globalized-minor-mode.
> > The third point also makes the c-mode-common "extra layer" more useful
> > since that hack is added in there.
> > Any objections to this version?
> This was four years ago, and there apparently wasn't any response here?
> Alan?
Five years on, I'm still not keen on this change. It is a large patch.
It would fragment the currently coherent functions c-mode, c++-mode and
so on. It would extend the stack of modes by inserting a new,
meaningless mode, c-mode-common; this might induce hackers to try to
derive directly from c-mode-common (which wouldn't work) rather than one
of the genuine CC Mode modes. It would magnify differences between the
Emacs version of CC Mode and the upstream version, or cause a lot of
work integrating the patch into the latter.
Of the above, I think it is the artificial introduction of c-mode-common
I'm least keen on.
I would be happiest if this bug could just be closed with "won't fix".
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Alan Mackenzie (Nuremberg, Germany).