bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes

[Dmitry Gutov]

On 10/01/2024 18:11, Stefan Monnier wrote:
> > That's very nice and concise, but it still leaves the issue of users being
> > able to use a common hook for a family of major modes (for the same
> > language).  So I guess some inheritance-based solution is needed?
> We have `define-derived-mode` for that.
> And even those major modes which don't want to inherit via
> `define-derived-mode` can `run-mode-hooks` any additional hook they like.

Hmm, I guess I figured that having a common hook is the more pressing 
issue, since the users would want to try the different available modes, 
and they don't always know where to put their settings - on 
js-mode-hook, or js-ts-mode-hook, or that there is the base mode that 
can be used (which is the case not for every ts mode).

Whereas the packages that use derived-mode-p are most likely less 
numerous than our total set of users who employ customizations in hooks, 
and thus can more easily bear the inconvenience of having to mention 
both js-ts-mode and js-mode, for example.

> Doing it when a mode is defined is easy and "safe".

Indeed, 'run-mode-hooks' is a workable approach, but if we decided on a 
common hook name to use (e.g. if it used the format like 
xyz-language-mode-hook) that might relieve the situation somewhat.

> Changing it after the fact risks introducing breakage (just like my
> `derived-mode-add-parents` does) where the code run via the hook depends
> on specific details of the original mode which aren't available in the
> "pseudo-derived" mode.

Sure. A new hook shouldn't have such a problem, though.

> For this reason my patch only proposes the use of
> `derived-mode-add-parents` since that's the part where a clear need has
> been found.

That makes sense.