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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com,
 Stefan Kangas <stefankangas <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, 15 Jan 2024 23:11:54 +0000

On Mon, Jan 15, 2024 at 8:51 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

> > I don't think there's anything magical about a base mode.  But I like your
> > solution too.
>
> As "magical", I meant the original patch for this report. I wouldn't
> mind the "base mode" approach, but I guess its still suffers from not
> being suitable for using with earlier Emacs versions.
>
> And every programming mode will have to come with -base-mode defined,

We could define them all in batch in a macro, that's not too bad.  And
then let the existing fleshed out ones overwrite those definitions by
making sure to load them later.

The main advantages of the foo-base-mode approach is that:

* it is easily grokkable by everybody, as it is very simply based on
  simple inheritance, which everybody knows already.

* there's already a fair number of such modes in the tree.

But I do like your patch better, it seems pretty useful to introduce the
language concept, as it solves this and more problems more cleanly.  So
let's see where that goes.

> This choice is coupled with the corresponding logic in 'buffer-language'
> (whether to keep the replace-regexp-in-string branch).

Yes.  I think we should err on the side on convenience.  What exactly are
the defects can we get?  I can't see anything else but the tuareg-mode, and we
can plug that on our side.  Maybe you can see more.

> Are there specific uses for get-mode-for-language when there is no
> existing buffer?

Yes, I'd say this markdown-mode use is exactly that.  Markdown inserts
some text into a buffer and all it knows is the language it's supposed
to fontify it with.  The major mode has that logic, so it must invoke
the correct (and preferred) major-mode function.

Another use is allowing the user to choose major modes for languages,
say from a tutorial or wizard or at Emacs startup.  Say, I prefer
ruby-ts-mode for Ruby, but c++-mode for C++.  It'd be helpful to summarize
those preferences.

> We could have both functions: buffer-language and get-language-for-mode
> ('get-mode-language'?). Or define one initially and add the other as needed.

Yes.  buffer-language isn't bad, it's a useful helper.  But buffer-language
should be just

   (with-current-buffer buffer (get-language-for-mode major-mode))

Right?  Modulo some caching if it turns out to be very inneficient
(which I really doubt)

João

Previous Next

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