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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Fri, 05 Jan 2024 23:08:40 -0500

> OK, so "kind".  So you seem to want to FOO-mode designates a family
> of modes for FOO.  That's reasonable but it  has the confusing property
> that the name of the family coincides with  the name of one of the
> members of the family.

It's actually very common.  Take "Lisp" as an example.
Similarly, `tex-mode` is both the parent of several derived modes and
the entry point that dispatches to the appropriate derived mode.

> Using inheritance for that just seems a bit off, like a hack.

`derived-mode-add-parents` is not inheritance: there's no reuse of code
involved (tho it doesn't preclude it, of course).

> Really what we wanted is a  new variable called 'mode-family'
> and test against that.

I don't think that's necessary.

This is a common programming design decision: should we have different
"types" for the various stages of a pipeline, or is it preferable to
keep the same type across various stages?  When the stages of the
pipeline often do nothing at all, it can be a good choice to keep the
type unchanged.

E.g. in Lisp, macroexpansion returns something of the same "type" as its
input: it's OK to pass the output of `macroexpand(-all)` back to
`macroexpand(-all)`.  Scheme made a different design decision on this
one (for hygiene reasons).

Other example: keys as they go through `keyboard-coding-system`,
`input-decode-map`, `function-key-map`, `key-translation-map`.  Here we
decided to keep the type the same.

> In Yasnippet, if I remember correctly (it was a long time ago), the
> snippet directory could either be renamed foo-base-mode or something
> in a .yas-parents inside that directory can be added containing
> "foo-base-mode".

AFAIK adding a `.yas-parent` containing "FOO-base-mode" just means
"oh, and also include the snippets defined for FOO-base-mode", which is
redundant with the fact that `FOO-ts-mode` already derived from
`FOO-base-mode`.

So that won't do it.  We'd need (like I recently mentioned in
https://github.com/joaotavora/yasnippet/issues/1169) something like
a new `.yas-children` (or `.yas-siblings`) which tells YASnippet
to use the current directory also for those additional modes.

>> That's why in my patch I add `python-mode` as an extra parent of
>> `python-ts-mode` even though they both share `python-base-mode` as
>> their parent.
>
> Right, that's what sounds hacky to me.  They're siblings, but now
> one also is the parent of the other. Maybe it works, but is
> definitely  odd.

`python-mode` from `python.el`, `python-mode` from `python-mode.el`, and
`python-ts-mode`, are three implementation of the `python-mode`
functionality, yes.

The fact that we use the same namespace for actual major modes and for
conceptual functionalities saves us from having to do:

    (derived-mode-add-parents 'python-mode '(python-mode))

:-)

The same happens with Debian package names and Debian package features:
package `emacs` implicitly provides the feature `emacs`.

> That said, if it works, I'm not really opposed to it.  What
> other packages do you know like Eglot and Yasnippet which use
> major-mode in this way.

I'm not sure which modes might be affected (beside Eglot, YASnippet,
and CEDET).  I presume many others outside of Emacs are, since
`derived-mode-p` is used very often out there.


        Stefan

Previous Next

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