From: Theodor Thornhill <theo@thornhill.no>
To: Yuan Fu <casouri@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: Tree-sitter indentation for js-mode & cc-mode
Date: Thu, 27 Oct 2022 20:36:28 +0200 [thread overview]
Message-ID: <541CF451-6FAC-4531-A8AF-8C86FBB9D40B@thornhill.no> (raw)
In-Reply-To: <A9F73048-7234-41D8-B092-DE1E277CD689@gmail.com>
>> This is cool, but do we really want/need this? I mean, now we're really
>> binding these implementations together and allowing all the legacy of CC
>> mode to blend in. We also need knowledge of how CC mode names their
>> syntactic definitions. IMO one of the big selling points of tree sitter
>> is that you can look at other editors implementation and get inspired
>> immediately. Now we need deep knowledge of cc mode, don't we? Also,
>> why would we want cc mode to calculate this for us? I see what you're
>> trying to do, but _I_ think this is a step in the wrong direction.
>
>You have a point. I tried to blend in cc-mode because that’ll allow us support “styles” and existing user customization. (Also I started out thinking it will be easier to write indentation rules this way which turns out to be not true.) Perhaps it’s better to come up with a new system for customizing indentation style. I’ll revert this change.
I think we can do something similar to the font lock features, can't we?
>>
>> But the new one renders it like this:
>> ```
>> const fooClient = new Foo({
>> bucket: process.env.foo,
>> region: process.env.foo,
>> });
>> ```
>>
>> I know this is a matter of tweaking, but it immediately makes me
>> question the reasoning to blend them.
>
>It’s largely my slip-up rather than inherit defect of the system, but I agree with your opinion above.
Yes, absolutely. My intention was just to make the point with confusion in mixing semantics etc. By the way - I think adding more helpers and anchors like you've done is nice, so don't just revert blindly, unless you have to :-)
>> looking up way to much the root of the tree, but you know the internals
>> here better than me. Is this something we can optimize away? See the
>> attached report at the bottom.
>
>This is very strange, I need to look into it.
>
I'm happy to provide more info and profiling, as well as testing if need be!
>>
>> centralized variable to get most, if not all of the "auto-enabling"
>> benefits by just lifting it up:
>>
>> ```
>> ;;....
>>
>> (cond
>> ;; Tree-sitter.
>> ((treesit-ready-p 'js-mode 'javascript)
>> ;; init all treesitter relevant stuff - can add in _some_ other
>> ;; non-cc-mode settinigs, such as comment-start, etc above this.
>> ;; We don't need the cache, detection of js-jsx or any of the
>> ;; before-change-functions
>>
>> (treesit-major-mode-setup))
>> ;; Elisp.
>> (t
>> ;; enable in normal cc mode stuff
>> )))
>>
>> ```
>>
>> This way other hypothetical tree-sitter-v2 in the future is just a
>> simple cond, and no need to worry.
>>
>> If I'm missing something important here, please let me know, but I
>> _really_ don't understand the reason for merging these implementations.
>
>I don’t have an educated opinion on this. If no one has objections I’ll follow your professional advice ;-)
>
Hah - no professionalism here, but I've spent quite some time in the cc mode machinery.
>> Anyway, thanks for your continued hard work!
>
>Many thanks to you, too!
>
>
My pleasure!
Theo
next prev parent reply other threads:[~2022-10-27 18:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 1:43 Tree-sitter indentation for js-mode & cc-mode Yuan Fu
2022-10-27 9:11 ` Theodor Thornhill
2022-10-27 9:28 ` Theodor Thornhill
2022-10-27 9:58 ` Theodor Thornhill
2022-10-27 15:21 ` Yuan Fu
2022-10-27 18:36 ` Theodor Thornhill [this message]
2022-10-28 8:15 ` Yuan Fu
2022-10-28 8:59 ` Theodor Thornhill
2022-10-28 9:10 ` Theodor Thornhill
2022-10-28 19:43 ` Yuan Fu
2022-10-28 19:49 ` Theodor Thornhill
2022-10-29 1:05 ` Yuan Fu
2022-10-29 5:53 ` Eli Zaretskii
2022-10-29 6:54 ` Yuan Fu
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=541CF451-6FAC-4531-A8AF-8C86FBB9D40B@thornhill.no \
--to=theo@thornhill.no \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--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.