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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Mon, 8 Jan 2024 00:12:50 +0000

On Sun, Jan 7, 2024 at 6:55 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> But that is not necessarily true in all cases.

I specifically said I was speaking for 2 packages I created,
Eglot and Yasnippet, and possibly for lsp-mode how is facing the same
problem, which is answering the question:

  what, if any, is the language/file type for a given major mode?

I can't speak to those other cases unless someone bring them forth.

> Also, some major modes don't have a "language" attribute, in
> the usual sense of that word.

Then I guess "nil" would be a fine default for anything not inheriting from
"prog-mode"?  Or s/language/filetype if you prefer.  Dmitry said a language
database is missing.  Stefan mentioned the problem of conflation of file types
and major modes in Emacs.  I agree with both, so I thought of a simple
solution composed of a getter and a setter.

> IOW, this is IMO an even more leaky abstraction than what we get with
> derived-mode-add-parents.

We don't seem to share the same concept of what a "leaky abstraction" is.
In my world, it's an abstraction that exposes details of the thing
it's supposed to abstract away.  Unless we're trying to abstract away
lisp symbols, I don't see how set/get-language-for-mode is leaky.

But if Stefan's patch is supposed to also abstract away the
language-mode correspondence, it's definitely exposing details of
how it does it, which is via "extra parenting".

João

Previous Next

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