GNU bug report logs - #68246
30.0.50; Add non-TS mode as extra parent of TS modes

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Sat, 6 Jan 2024 14:36:17 +0000

On Sat, Jan 6, 2024 at 4:08 AM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> Other example: keys as they go through `keyboard-coding-system`,
> `input-decode-map`, `function-key-map`, `key-translation-map`.  Here we
> decided to keep the type the same.

As much as I want to believe these arguments for the conceptual
solidity of this "extra-parents" idea, I still think this is
burdensome.

As a data point, I've had  a fair number of Eglot users confused about
single simple inheritance as it stands.

> The same happens with Debian package names and Debian package features:
> package `emacs` implicitly provides the feature `emacs`.

[I don't find this model simple either, not as a casual Debian user.
But at least there they have clear separate concepts of "package" and
"feature", which seems to hint at my "mode family" or "file type" idea]

> I'm not sure which modes might be affected (beside Eglot, YASnippet,
> and CEDET).  I presume many others outside of Emacs are, since
> `derived-mode-p` is used very often out there.

Personally, I think if Eglot, YASnippet and CEDET are all we
actually know about, I think it's very simple to fix 2 out of three (even
_without_ the "base mode").  And the 3 out of 3 I _think_ I can
fix once someone points me to what exactly it should do.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.