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 #424 received at 68246 <at> debbugs.gnu.org (full text, mbox):
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 19 Jan 2024 22:47:07 +0000
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
> Stefan Kangas <stefankangas <at> gmail.com>, 68246 <at> debbugs.gnu.org, casouri <at> gmail.com
>
> On Fri, Jan 19, 2024 at 6:05 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > > I.e. can you clearly paint a way forward from it that solves the "what
> > > is this language in this buffer", "what is the language for this
> > > major-mode" and the "what mode should I use for that
> > > language" problems?
> >
> > As already explained ad-nauseam, my patch has no intention to solve
> > those problems, but I can't see any way in which it gets in the way of
> > solving them, if you care to solve them.
>
> The patch is intended to solve problems in Eglot, Yasnippet,
> ffap and so on. This problem always includes with "what is this
> language in this buffer", i.e. number 1 in the preceding list.
> That's what the problem is, no less. The fact that these packages
> have always resorted to using `derived-mode-p` to solve that
> problem is an unfortunate consequence of the longstanding
> conflation between modes and languages that you yourself
> identified.
>
> But it's not the right solution, never was. Your patch contributes
> to the perpetuation of this "wrong" solution, and I think
> we should face that frontally.
Your opinions on this are well-taken and have been noted many messages
ago. You made them abundantly clear. There's no need to re-iterate
them time and again.
> After it lands, derived-mode-p will cease to mean "A derived
> from B via defined-derived-mode, so you can trust hook for B
> runs in hook for A and a lot of other things". It will mean
> something else.
Indeed, and it was not meant to mean what you suggest it should mean.
> * if it lands, we should document very well what that new meaning
> of "<lang>-mode" is. Also make some "provided-mode-walk-parents"
> so that at least problem 2 can be solved, by string-matching
> the symbol name of what will now be an even more enshrined
> convention. As to problem 3, maybe, it can be written off to
> "major-mode-remap-alist" (which I doubt will ever see much
> adoption)
Feel free to suggest improvements and clarifications to the
documentation in these matters.
> * if it doesn't land, we should look at some solution that solves
> 1 2 and 3 cleanly. I think Dmitry's patch is a decent start.
Since it will land, there's no need yet to look for alternatives. We
will consider alternatives or other ways to fix this when we have data
(as opposed to just theoretical discussions) to support the need for
such changes. (This, too, has been mentioned several times already.)
> * in the meantime, we should continue using base modes as we
> already are. In fact, the <foo>-base-mode convention is a
> much better convention to enshrine, it doesn't require any
> special caveats regarding hooks and dir-locals and changes
> to the *Help* of a major mode function description.
We already use base modes where it makes sense. It sounds like your
opinion is that we should use it much more radically, with which I
disagree and will object to introduction of base modes that server no
useful purpose by themselves. I believe I've made that clear as well.
I hope this will allow us finally to put this longish discussion to
rest, at least until we have actual data to discuss what and how needs
to be changed.
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.