GNU bug report logs -
#68246
30.0.50; Add non-TS mode as extra parent of TS modes
Previous Next
Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu, 4 Jan 2024 22:12:01 UTC
Severity: wishlist
Found in version 30.0.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
Message #331 received at 68246 <at> debbugs.gnu.org (full text, mbox):
>> Please don't call it "language". That'd be confusing. LSP is about
>> programming languages, so "language" is natural there. But in Emacs,
>> a major mode is more general than that. For example, it is not
>> unthinkable to consider mail-mode to be the extra-parent of
>> message-mode (or vice versa) -- but what is the "language" in that
>> case?
> Isn't the language for such modes in this paradigm just the empty set?
I'm not too worried about those cases, indeed.
I'm more worried about the taxonomy of languages.
We currently have the taxonomy of major modes, with which we're pretty
familiar, and we've had many years to learn about its downsides,
complexity, as well as how to deal with them, but for languages we're
only familiar with the easy cases, which makes us judge the idea in
a way that may prove naive.
IME, deciding what is the type of the content of a buffer is usually
trivial but with some notable caveats, such as XPM or Postscript files,
or "container formats" (like `.deb` or `.odt`, as well as things like
DocBook which can be considered either as their own format or as XML),
or "sublanguages" such as C being a subset of C++, or Javascript being
a subset of Typescript. And I suspect the info we need will not always
be quite the same.
So while there might be a good case to be made to add some API functions
to query the language/type(s) of a given buffer (I'm not sure we'd need
the language of a given major mode, OTOH), or to find the preferred
mode(s) for a given language/type, I think it's worthwhile to try and
tweak our major mode taxonomy because it is information we must have
and information we know we will always have, so we should strive to make
it as good as we can.
It shouldn't make it any harder to add language/type API functionality.
On the contrary it should make it easier.
[ As suggested elsewhere in this thread, we could even try and merge
those taxonomies, e.g. using extra parents of the form `LANG-lang`. ]
As I said at the very beginning of this long thread, I'm not completely
sure how well my proposal will play out: the upsides are in plain sight,
but it may bump into real problems. [ I'm actually surprised by Eli's
optimism about it 🙂 ]
But we won't know until we try it.
Stefan
This bug report was last modified 1 year and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.