heex-ts-mode does not derive from prog-mode

[KaranAhlawat]

The derivation chain goes heex-ts-mode <- html-mode <- sgml-mode <- text-mode <- nil. Which means users may trigger (and conversely not trigger) behavior they have setup in text-mode (and conversely prog-mode).

For a concrete example, the default completion-at-point keybinding is taken over by ispell in text-mode. This was unexpected since heex-ts-mode, is primarily a programming buffer, even if you're just mostly writing templates.

What are your thoughts on making it derive from prog-mode or web-mode rather than html-mode?

[wkirschbaum]

html-mode was just the simplest to start with. you are welcome to create a PR or maybe suggest some specific changes.

[KaranAhlawat]

I'll see if just swapping out html-mode for prog-mode is sufficient. Will open a PR if it is

[wkirschbaum]

@KaranAhlawat it will be a bit more than that, but check the behaviour with other packages. It might also be worth while to have a look how other templating modes work and where they derive from.

[KaranAhlawat]

vue-ts-mode derives from prog-mode, while astro-ts-mode derives from html-mode. Couldn't find other examples of templating languages modes.

[elken]

Upstream html-ts-mode derives from html-mode and mickeyp's derives from sgml-mode, as does my erb-ts-mode

Reading this now I think it's a mistake for both heex-ts-mode and erb-ts-mode to derive from text-based modes as they will inherently be more prog-mode focused. I'm surprised that astro-ts-mode doesn't follow suit as most of the components are code rather than the code & markup mix that heex, erb and vue end up with.

[wkirschbaum]

I started looking at this today. Just a reminder that this mode is part of Emacs now and further conversation regarding this will happen on the mailing list. ( I will link the thread here, unless there is not a reason to go ahead with such a change ).

The initial test on my side shows no immediate issues though.