[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
From: |
Eli Zaretskii |
Subject: |
bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes |
Date: |
Mon, 08 Jan 2024 05:34:10 +0200 |
> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 8 Jan 2024 00:12:50 +0000
> Cc: monnier@iro.umontreal.ca, casouri@gmail.com, 68246@debbugs.gnu.org
>
> On Sun, Jan 7, 2024 at 6:55 AM Eli Zaretskii <eliz@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.
A generalization should be based on as many use cases as possible.
> > 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"?
That's not useful, since, for example, TS and non-TS mods for those
"no-language" modes will still want to be treated the same in some
situations, like .dir-locals.el.
> > 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.
That's the sense in which I'm using it.
> Unless we're trying to abstract away lisp symbols, I don't see how
> set/get-language-for-mode is leaky.
It attempts to abstract a trait that isn't abstract, by going in the
opposite direction of that used for abstractions.
> But if Stefan's patch is supposed to also abstract away the
> language-mode correspondence
It isn't, AFAIU.
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, (continued)
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/06
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/06
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/06
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/07
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/07
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes,
Eli Zaretskii <=
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/08
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/08
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/08
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/08
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Yuan Fu, 2024/01/13
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/13
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Yuan Fu, 2024/01/13
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/14
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/14
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/15