|
From: | Jostein Kjønigsen |
Subject: | Detecting tree-sitter based major-modes for end-user customization and third party functions/packages |
Date: | Tue, 20 Dec 2022 12:35:57 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
Hey everyone.
This may or may not have been answered in an earlier thread about the subject, but I couldn't really find it, so if this email and question represents a duplicate: sorry in advance.
With that said, I'll get straight down to business.
While as a major-mode author, I can decide to use tree-sitter to implement key functionality, we don't expect end-users to (need to) have the same level awareness about the technology used to implement the modes they are consuming.
However end-users often want to customize Emacs based on
major-mode agnostic properties of the current major-mode none the
less. Examples are adding hooks for prog-mode, c-mode-common-mode
(from cc-mode), etc. This may also apply to other third-party
packages, in how they interact with buffers (if prog-mode do this,
if text-mode do that, etc).
I expect these kinda of needs to arise for tree-sitter based major-modes sooner rather than later, where one may be able to leverage tree-sitter node-manipulation functions rather than use text-based equivalents.
But to be able to leverage tree-sitter based functions, one would
first need to know that one is interacting with a tree-sitter
based major-mode. And to customize one, one would need a hook.
So how do we plan to expose this to end-users and other
developers?
Looking at (treesit-major-mode-setup), I can't see it leaving any
traces to be reliably detected later. Should we add some
(documented) buffer-local variables to be able to detect this
later? Should we create a mostly empty minor-mode for easy
detection and ability to add hooks?
Or does anyone have any other suggestions for how we can solve
this user-facing need of tree-sitter?
[Prev in Thread] | Current Thread | [Next in Thread] |