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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>, Yuan Fu <casouri <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Sat, 20 Jan 2024 10:16:45 +0000

On Sat, Jan 20, 2024, 07:04 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > 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.

Then pray tell.  What will it mean exactly?  This patch has no doc
yet (last I saw).

> > * 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.

I don't understand the vision behind this patch.  It has do doc
yet.  Despite your attempts to wrap this up and shut me up
I'm trying to at least converse with the author to expound it.
Often it's when trying to explain something in plain English
that to see how suitable it is.

> > * 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.

If you've already decided that, just install it and save
us all some time.

> We will consider alternatives or other ways to fix this when
> we have data

I've given you data: at least Eglot and markdown mode have brittle
hacks this patch does nothing for.  You have chosen to ignore it.
Also I've explained how potentially dangerous this patch is to
Eglot customizations.

> 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.

So solving the common language-detection problem, deduplicating
hooks and dir-locals is not serving a purpose "by oneself"?
Indeed you make up an undefined high bar of "by oneselfness"
you get to choose what clears it and doesn't.  But it doesn't
make your argument an argument.

João

Previous Next

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