bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes

[João Távora]

On Wed, Jan 10, 2024 at 6:24 AM Stefan Kangas <stefankangas@gmail.com> wrote:

> I.e. the difference is:
>
>     (derived-mode-p 'foo-mode)   vs    (language-for-mode-p 'foo)
>     Monnier                            Távora
>
> Either of those would answer the question "does the current buffer
> contain language FOO".  The former reuses the old taxonomy, the right
> introduces a new one.

Yes, but the on on the right looks more like

   (cl-defun get-language-for-mode &optional (mode major-mode) ...)

i.e. it's not a boolean predicate.  You can make one with it, of course.

> Basically, the biggest weakness of Stefan M's solution is the biggest
> strength of João's and vice versa: "backwards-compatibility" (if we can
> call it that) vs "clean taxonomy".

Indeed I think it's important to clearly state what "backwards
compatibility" we're trying to solve here.  What exactly was "broken"
after the introduction of TS modes?  We could answer

   "nothing, the TS modes were new things!"

Or we could answer

   "some things, because in some situations the user is led mode or
    less easily to use the new mode and her configs for the old mode
    don't apply"

I believe Stefan and Eli and using the second interpretation.
Fine, that's perfectly fine.  They are actively trying to fix this
breakage.  Also fine.

Importantly, I think it's important to quantify how many "things" were
broken.  In the beginning of this discussion, I saw references to
Eglot and Yasnippet.  Then CEDET, then lsp-mode, then ffap.
I know very well what's going on with the first two, but not the
others.  Does anyone?  It's important to have an overview of what
is broken where, and if it's in the Emacs tree, in the ELPAs, or
elsewhere entirely.

We also know the problem is already mostly fixed in places like Eglot
and lsp-mode.  Elegantly?  Manifestly not, but it's "no worse" than
what was in place pre-TS-modes.

Can we do better for Emacs 30 (or Emacs 29 + compat.el)?  Probably
yes.

1. We could have more "base" modes like we already have and keep
   the relative simplicity of simple inheritance.

2. We could have a new concept of "language" that is a non-nil
   property of _some_ major modes.  With this new concept a number
   of new useful features are being speculated (for example
   language-specific hooks, a friendly dialog for beginners looking
   to use a specific language, etc).  But these new features are
   not essential to  "fixing the breakage".

   The concept of "content type" works just as well here, IMO.

   Also, it has been pointed out that the existing major-mode-remap-alist
   could be used for this.  I agree, but it should come with
   accessors and be localized to to define-derived-mode anyway.

3. We could have this special concept of extra parents so
   that any existing derived-mode-p call does what we thing is
   the right from here on.

All valid alternatives, but I'm surprised option 3 is such a strong
candidate, since it requires exposing the user to a non-trivial
concept.  The symbol "<foo>-mode" would be promoted to designate
something like a "meta-mode" (I also called "family" earlier) where
the current major mode might be 'derived-mode-p' from it but the
concrete-mode's hooks and body is not run.  Interesting as
this is (Stefan M made a defense of it based on practices in other
packages), I think it's just too strong of a hammer to use here,
and at least a minor headache in terms of docstrings.

João