From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: 68246@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Fri, 05 Jan 2024 18:51:41 -0500 [thread overview]
Message-ID: <jwvmstj2w15.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CALDnm52YJ6hPXWnvMMMp1+E8V1DO9r--58ojEKUrsSpE8z9e8Q@mail.gmail.com> ("João Távora"'s message of "Fri, 5 Jan 2024 23:20:26 +0000")
[ IMO, it would indeed be a good idea to try and write some abstraction
layer so we can share more code between modes parsing with
syntax-tables/tree-sitter/wisi/SMIE/younameit. It will also be very
useful when tree-sitter goes the way of the dodo.
But that's a difficult job, and with limited immediately-visible
benefits to the end users. In the mean time, we're stuck with major
modes that don't share much code. ]
Whether it's worthwhile to have a `FOO-base-mode` or not depends on
the specifics, but it's largely an implementation detail. More
importantly it's not directly relevant to this here bug, because
I want to say "FOO-ts-mode is a kind of mode for FOO, so it's
a kind of FOO-mode". There are very few YASnippets for FOO-base-mode,
instead they're all for FOO-mode. Similarly, Eglot doesn't have rules
for FOO-base-mode, only for FOO-mode.
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.
IOW, in my patch, I'm using `FOO-mode` not really as the name of a major
mode, but rather as the name of a *file type*.
I already mentioned this distinction in the bug-report where
I introduced `major-mode-remap-alist`: Emacs usually conflates
file-type and major-mode, which works great where there's only one major
mode for a given file type, but less great where there are
several alternatives.
Stefan
João Távora [2024-01-05 23:20:26] wrote:
> On Fri, Jan 5, 2024 at 6:57 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > 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.
>
> electric-pair-mode uses scan-sexps. Scan-sexps works perfectly to
> navigate nested mixed delimiter structures of modes that are not Lisp,
> otherwise e-p-m couldn't do it's auto-balancing job.
>
>> > 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.
>
> As I am trying to explain, it doesn't have to be a "Lisp sexp".
> It just has to be something that scan-sexps can navigate, and
> scan-sexps works in all modes. I'd think that at least
> with a good enough grammar it's perfectly possible to do
> e.g. show-paren-mode with TreeSitter alone. And the way this
> could work in Emacs is for TreeSitter to feed into scan-sexps.
>
>> > > 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.
>
> ? You write this precisely in the point where I _agree_ with you.
> That's the really the opposite of brushing aside.
>
>> > 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.
>
> As I am trying to explain, even a one-line empty base mode is useful.
>
>> > > > 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.
>
> Very well, we are violently agreeing.
>
>> This means that the
>> base-mode hook will not see a mode that is ready for work, only its
>> beginning.
>
> Correct. But a major-mode doesn't have to be "ready for work" (I presume
> you mean ready for editing) for the hook to be useful. That hook would
> be perfectly suitable for setting variables used by minor modes and other
> things. (eglot-server-program, flymake-diagnostic-functions, company-backends,
> mode-line-format, etc etc)
> For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-mode,)
> For binding commands.
>
> And even without the hook the mere fact that foo-mode and foo-ts-mode
> are derived from foo-base-mode according to derived-mode-p makes it
> useful.
>
>> > 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.
>
> I don't see the problem, really. Now I see that many mode "base modes" already
> exist. That's great! That's at least four simplifications to eglot.el's
> eglot-server-programs (ruby, python, js and bash/sh). I'd be happy to
> know of more if someone has a fuller list.
>
> And all the base mode definitions could well have settings for the
> upcoming eglot-server-program.
>
>> > > 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.
>
> I couldn't see the problem in either python.el or sh-script.el. What
> do you wish you could do in those base mode bodies on have the user
> do in the base mode hooks which is impossible?
>
> João
next prev parent reply other threads:[~2024-01-05 23:51 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 22:11 bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:02 ` João Távora
2024-01-04 23:05 ` Dmitry Gutov
2024-01-04 23:41 ` João Távora
2024-01-04 23:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:48 ` João Távora
2024-01-04 23:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 0:35 ` João Távora
2024-01-05 0:43 ` Yuan Fu
2024-01-05 7:51 ` Eli Zaretskii
2024-01-05 11:27 ` João Távora
2024-01-05 13:26 ` Eli Zaretskii
2024-01-05 15:16 ` João Távora
2024-01-05 15:34 ` Eli Zaretskii
2024-01-05 18:02 ` João Távora
2024-01-05 18:56 ` Eli Zaretskii
2024-01-05 23:20 ` João Távora
2024-01-05 23:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-01-06 0:16 ` João Távora
2024-01-06 4:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 14:36 ` João Távora
2024-01-06 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 22:22 ` João Távora
2024-01-07 6:55 ` Eli Zaretskii
2024-01-08 0:12 ` João Távora
2024-01-08 3:34 ` Eli Zaretskii
2024-01-08 10:50 ` João Távora
2024-01-08 13:13 ` Eli Zaretskii
2024-01-08 14:45 ` João Távora
2024-01-08 17:15 ` Eli Zaretskii
2024-01-14 2:19 ` Yuan Fu
2024-01-14 3:10 ` João Távora
2024-01-14 4:00 ` Yuan Fu
2024-01-14 7:02 ` Eli Zaretskii
2024-01-14 23:40 ` João Távora
2024-01-15 12:38 ` Eli Zaretskii
2024-01-15 14:45 ` João Távora
2024-01-15 15:00 ` Eli Zaretskii
2024-01-15 15:09 ` João Távora
2024-01-15 2:10 ` Dmitry Gutov
2024-01-15 12:46 ` Eli Zaretskii
2024-01-15 18:32 ` Dmitry Gutov
2024-01-15 18:52 ` Eli Zaretskii
2024-01-15 20:17 ` Dmitry Gutov
2024-01-15 20:27 ` Eli Zaretskii
2024-01-15 15:27 ` João Távora
2024-01-15 20:51 ` Dmitry Gutov
2024-01-15 23:11 ` João Távora
2024-01-16 2:09 ` Dmitry Gutov
2024-01-16 11:06 ` João Távora
2024-01-17 2:41 ` Dmitry Gutov
2024-01-17 10:20 ` João Távora
2024-01-18 0:47 ` Dmitry Gutov
2024-01-17 17:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 5:05 ` Dmitry Gutov
2024-01-18 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 19:55 ` Dmitry Gutov
2024-01-18 21:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 1:28 ` Dmitry Gutov
2024-01-19 12:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 12:53 ` João Távora
2024-01-19 13:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 14:01 ` João Távora
2024-01-19 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 22:47 ` João Távora
2024-01-20 7:03 ` Eli Zaretskii
2024-01-20 10:16 ` João Távora
2024-01-21 0:32 ` Yuan Fu
2024-01-21 9:54 ` Eli Zaretskii
2024-01-24 6:20 ` Yuan Fu
[not found] ` <jwvfrxt5e75.fsf-monnier+emacs@gnu.org>
[not found] ` <86v86ovp6j.fsf@gnu.org>
2024-03-09 15:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-20 5:43 ` Dmitry Gutov
2024-01-14 6:33 ` Eli Zaretskii
2024-01-14 23:18 ` João Távora
2024-01-15 12:35 ` Eli Zaretskii
2024-01-15 14:49 ` João Távora
2024-01-08 4:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 11:11 ` João Távora
2024-01-08 12:45 ` Eli Zaretskii
2024-01-08 18:57 ` Dmitry Gutov
2024-01-08 19:55 ` Eli Zaretskii
2024-01-08 20:06 ` Dmitry Gutov
2024-01-08 22:12 ` João Távora
2024-01-09 3:28 ` Eli Zaretskii
2024-01-08 19:18 ` Stefan Kangas
2024-01-08 19:57 ` Eli Zaretskii
2024-01-08 20:05 ` Dmitry Gutov
2024-01-09 3:27 ` Eli Zaretskii
2024-01-16 2:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 23:29 ` João Távora
2024-01-17 0:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-17 0:49 ` João Távora
2024-01-17 3:45 ` Dmitry Gutov
2024-01-19 5:12 ` Yuan Fu
2024-01-20 5:47 ` Dmitry Gutov
2024-01-20 7:46 ` Eli Zaretskii
2024-01-21 0:32 ` Dmitry Gutov
2024-01-08 19:04 ` Dmitry Gutov
2024-01-09 0:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 0:39 ` João Távora
2024-01-09 0:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:05 ` João Távora
2024-01-09 1:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:11 ` João Távora
2024-01-09 3:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 10:52 ` João Távora
2024-01-10 1:18 ` Dmitry Gutov
2024-01-10 16:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-11 3:41 ` Dmitry Gutov
2024-01-09 4:49 ` Stefan Kangas
2024-01-09 7:24 ` Kévin Le Gouguec
2024-01-09 1:09 ` Dmitry Gutov
2024-01-09 1:31 ` João Távora
2024-01-09 3:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 11:05 ` João Távora
2024-01-10 1:15 ` Dmitry Gutov
2024-01-10 1:59 ` João Távora
2024-01-10 16:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 17:02 ` Dmitry Gutov
2024-01-10 17:31 ` João Távora
2024-01-10 1:41 ` Dmitry Gutov
2024-01-10 6:24 ` Stefan Kangas
2024-01-10 15:51 ` João Távora
2024-01-11 3:49 ` Dmitry Gutov
2024-01-16 2:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 10:34 ` João Távora
2024-01-16 17:45 ` Dmitry Gutov
2024-01-16 22:00 ` João Távora
2024-01-17 2:05 ` Dmitry Gutov
2024-01-17 10:31 ` João Távora
2024-01-17 23:37 ` Dmitry Gutov
2024-01-06 8:12 ` Eli Zaretskii
2024-01-06 8:07 ` Eli Zaretskii
2024-01-06 13:52 ` João Távora
2024-01-05 19:03 ` Stefan Kangas
2024-01-05 23:37 ` João Távora
2024-01-06 8:09 ` Eli Zaretskii
2024-01-06 3:19 ` Yuan Fu
2024-01-06 3:36 ` Dmitry Gutov
2024-01-06 4:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-07 6:59 ` Yuan Fu
2024-01-06 14:54 ` João Távora
2024-01-08 18:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 7:40 ` Eli Zaretskii
2024-01-05 18:43 ` Stefan Kangas
2024-01-05 19:11 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvmstj2w15.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=68246@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.