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

Previous Next

Full log

Message #415 received at 68246 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 casouri <at> gmail.com, Stefan Kangas <stefankangas <at> gmail.com>,
 68246 <at> debbugs.gnu.org
Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Fri, 19 Jan 2024 22:47:07 +0000

On Fri, Jan 19, 2024 at 6:05 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> > I.e. can you clearly paint a way forward from it that solves the "what
> > is this language in this buffer", "what is the language for this
> > major-mode" and the "what mode should I use for that
> > language" problems?
>
> As already explained ad-nauseam, my patch has no intention to solve
> those problems, but I can't see any way in which it gets in the way of
> solving them, if you care to solve them.

The patch is intended to solve problems in Eglot, Yasnippet,
ffap and so on. This problem always includes with "what is this
language in this buffer", i.e. number 1 in the preceding list.
That's what the problem is, no less. The fact that these packages
have always resorted to using `derived-mode-p` to solve that
problem is an unfortunate consequence of the longstanding
conflation between modes and languages that you yourself
identified.

But it's not the right solution, never was. Your patch contributes
to the perpetuation of this "wrong" solution, and I think
we should face that frontally.

After it lands, derived-mode-p will cease to mean "A derived
from B via defined-derived-mode, so you can trust hook for B
runs in hook for A and a lot of other things".  It will mean
something else.  Once that lands, it can never really safely
be rolled back.  So my position is:

* if it lands, we should document very well what that new meaning
  of "<lang>-mode" is.  Also make some "provided-mode-walk-parents"
  so that at least problem 2 can be solved, by string-matching
  the symbol name of what will now be an even more enshrined
  convention.  As to problem 3,   maybe, it can be written off to
  "major-mode-remap-alist" (which I doubt will ever see much
  adoption)

* if it doesn't land, we should look at some solution that solves
  1 2 and 3 cleanly.   I think Dmitry's patch is a decent start.

* in the meantime, we should continue using base modes as we
  already are.  In fact, the <foo>-base-mode convention is a
  much better convention to enshrine, it doesn't require any
  special caveats regarding hooks and dir-locals and changes
  to the *Help* of a major mode function description.

Previous Next

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