bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Dmitry Gutov
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Mon, 8 Jan 2024 21:04:30 +0200
User-agent: Mozilla Thunderbird

On 08/01/2024 06:11, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
    (set-language-for-mode 'foo-ts-mode 'foo)

Maybe we want to introduce this concept, indeed.

maybe we want to that notion of "language" from elsewhere, such as
the one used in LSP?
Or maybe we want to take it from MIME types?
I'm sure there are other options out there.

I think the precise source of the mapping is not that important. We might as well continue maintaining auto-most-alist, interpreter-mode-alist and magic-mode-alist by hand. Or indeed learn to populate them from the MIME database later.

What we have, though, it different major modes duplicating auto-mode-alist entries even inside the core Emacs. Such as c-ts-mode having modified copies of forms that originate from CC Mode.

Or ruby-mode and ruby-ts-mode using two copies of the same regexp. Etc.

Instead, we could have a mapping of files to "languages" and a separate one from languages to major modes. And one could fetch the "language" for the current buffer using 'rassoc'.

Problem is: they come with their own complexities and corner cases.
After all, this is inevitable when you create a taxonomy.
IOW, while we *may* want to add support for an explicit notion of "file
type", it's a whole problem in itself and it will not solve all
our problems either.

In the mean time, I think `derived-mode-add-parents` is worth a try.
As mentioned in some message up-thread, I'm not 100% confident that it
won't introduce serious breakage.  But I think we do need more
experience and installing my patch is a good way to do that.

This would've worked better inside the Emacs 29.1 release (which contains a few other "expedient" solutions).

I'm guessing it won't get into 29.2 either. So the users of such versions would have to deal with the existing taxonomy anyway, and half-measures might also serve to make people more confused about what works in which version and why.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]