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
View this message in rfc822 format
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 5 Jan 2024 18:02:29 +0000
> Cc: monnier <at> iro.umontreal.ca, 68246 <at> debbugs.gnu.org
>
> > > Or consulting documentation.
> >
> > Again, only the mode's symbol is important.
>
> No. Say some consult-documentation minor-mode relies on
> some setting of 'documentation-function'?
I had info-look in mind.
> > > Or anything we've built (including muscle memory) that lives on top
> > > of syntactic abstractions like forward-sexp.
> >
> > Here you already bump into a problem, because most languages have no
> > notion of "sexp", so making a TS mode do the same as a traditional
> > mode is not easy at all.
>
> Of course they do!! How else would electric-pair-mode have worked
> for virtually every language for more than 10 years
forward-sexp moves forward even when there are no parentheses or
braces anywhere in sight.
> Well the reason why e-p-m and these things work today for most ts
> modes is because they are also _using_ the Lisp/C parser based on
> syntax tables and syntax-propertize-function.
That's because a language parser will not have any notion of a sexp,
so it cannot help.
> > I invite you to compare CC mode with c-ts-mode, and see for yourself
> > how the common grounds are very small. It seems surprising at first
> > sight, but once you look at the code, it is very clear.
>
> And this is mainly because CC mode is, well, rather corpulent software,
> let's put it like that. This is why I wrote it makes sense to start
> from scratch for this one.
A discussion where you brush aside any argument that doesn't fit your
theory is not a useful one. In Emacs we have to solve problems that
happen in the messy real world, not problems in an ideal world where
everything is according to some elegant theory.
> But would some kind of c++-base-mode hurt in some way? Presuming Alan
> allows it, of course.
Feel free to suggest such a base mode. If it works and is helpful, we
will install it. Frankly, I doubt you could come up with a useful
base mode like that: the differences are too large.
> > > At the very least, it seems a common hook would be useful, and that's
> > > what an empty foo-base-mode() would give.
> >
> > Where a base mode makes sense, sure. But even that causes problems,
> > since the base mode leaves some stuff not set up.
>
> I don't follow. Can you give an example of a problem?
Yes, look at python.el and sh-script.el. The base mode can only go so
far, it must stop before it gets into the stuff that is really
different between the TS and non-TS modes. This means that the
base-mode hook will not see a mode that is ready for work, only its
beginning.
> In fact I'm happy to see exactly the strategy I suggested is already
> done in ruby-mode.el and ruby-ts-mode.el. What problems are caused
> by it?
Some modes succeed in that, others don't. I guess it depends on the
language grammar.
> > and this various
> > things that you'd want to do in a mode hook are impossible in the
> > base-mode hook.
>
> I don't follow this part either. Can you give an example using, say
> the existing ruby-base-mode.
Again, look at the two examples I mentioned above.
> In summary, my position is that regardless of Stefan's patch, which
> I'm not opposed to, we should:
>
> 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when
> possible.
>
> 2. have a remove-derived-mode-parent (for the other bug)
>
> 3. perhaps tighten up what we mean by derived-mode-p in the docs
I have no opinion on that.
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.