emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Average-user-facing interface for tree-sitter


From: Yuan Fu
Subject: Re: Average-user-facing interface for tree-sitter
Date: Mon, 17 Oct 2022 02:07:15 -0700


> On Oct 14, 2022, at 10:05 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Oct 14, 2022, at 8:26 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>>> (add-hook 'xxx-mode-hook
>>>         (lambda () (when (eq major-mode 'xxx-mode)
>>>                      (treesit-mode))))
>>> 
>>> Which again is a bit awkward.
>> 
>> Awkward but possible.  Another approach can be:
>> 
>>   (add-hook 'xxx-mode-hook #'treesit-mode)
>>   (add-hook 'yyy-mode-hook (lambda () (treesit-mode -1)))
> 
> With the central variable approach, you can do (push ‘(xxx-mode t nil) 
> treesit-settings), where t means enable, nil means don’t inherit.
> 
>> 
>>> So maybe a central variable isn’t that bad an idea.  Could you layout
>>> why mapping modes to some information is bad?
>> 
>> Because it needs to be able to say "for this mode and all its derived
>> modes" but also "for this mode only" as well as various combinations,
>> and then you need to document how it interacts with the major mode's
>> hook, ...
> 
> Do you mind elaborate on: What are the other combinations? What are the ways 
> a central variable can interact with major mode hooks? 
> 
>> Maybe we should devise a way to "centrally" control the value of some
>> vars depending on major modes, but if so we should carefully design
>> a thing specifically for that, make sure it's sufficiently flexible, and
>> then use it for several (any?) variable.
>> 
>> All the vars I've seen so far which do that do it quite naively, which
>> works OK for simple cases but breaks down one way or another when you
>> start taking derived modes into account.  Hence my considering it a code
>> smell (just like most uses of the `major-mode` variable).
> 
> How about a function mode-specific-value that takes any variable with the 
> following shape:
> 
> ((MODE VALUE INHERIT)…)
> 
> And returns the right VALUE for the current mode? INHERIT decides whether 
> VALUE is inherited by MODE’s derived modes. Something like:
> 
> (defun mode-specific-value (central-var)
>  (cl-loop for setting in central-var
>           for mode = (nth 0 setting)
>           for value = (nth 1 setting)
>           for inherit = (nth 2 setting)
>           if (and (derived-mode-p mode) inherit)
>           return value
>           finally return
>           (if-let ((default (alist-get t central-var))) ; t sets the default 
> value for all mode.
>               (car default)
>             nil)))
> 
> This function would handle derived mode ok, but I don’t know what are the 
> other problems you are think of, maybe you can tell me what this function 
> falls short for. And we can go from there.

If no one has opinions on this, I’m going to implement the central-variable 
approach, since IMO that one is most fit.

Yuan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]