Re: Unifying "foo-mode"s and "foo-ts-mode"s

[Theodor Thornhill <theo@thornhill.no>]

Philip Kaludercic <philipk@posteo.net> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> You can try.  I would like to start a full feature freeze in a day or
>>>> two, so I'm not sure you will have enough time.  And it isn't like we
>>>> didn't try various approaches during the past two months, so frankly I
>>>> don't think that a better way even exists.  But if you come up with
>>>> some very bright idea, who knows?
>>>
>>> I have attached a sketch of my proposal with support for Python.
>>> Instead of a separate python-ts-mode, we regulate tree-sitter support
>>> using a user option `treesit-enabled-modes'.  It can either be a list
>>>
>>
>> [...]
>>
>> IIUC this will make all other config run before the treesit-related
>> code?  
>
> If that is the problem, that we can solve that by re-adjusting the order
> in which the expanded code occurs. 
>
>>        In that case I think this cannot work, because we _don't_ want to
>> set all the before/after-change functions many modes set, for example.
>
> What exactly is the issue here?  Can't we overwrite it again if
> necessary?
>

For example the CC modes set up lots of functions in the mode init, many
of which override things like '*-function' variables, that if either not
overriden explicitly by a treesit alternative or removed before mode
init will impact performance.  There are some modes that will be worse
in this regard than others, but one of my earlier suggestions was to
just:

(define-derived-mode foo ........

  (cond
    (use-treesit-p
     (init-all-the-treesit-stuff))
    (use-hypothetical-future-thing
     (init-all-the-hypothetical-future-stuff))
    (t
     (init-all-the-other-stuff))))

In this case we don't let any code bleed in between the modes, which IMO
is necessary.  At least we should be very careful with _when_ it is ok
for such settings to bleed in.  Things like comment-start/end etc can
bleed in just fine, but stuff like

```
  (c-init-language-vars js-mode)
  (setq-local indent-line-function #'js-indent-line)
  (setq-local beginning-of-defun-function #'js-beginning-of-defun)
  (setq-local end-of-defun-function #'js-end-of-defun)
  (setq-local open-paren-in-column-0-is-defun-start nil)
  (setq-local font-lock-defaults
              (list js--font-lock-keywords nil nil nil nil
                    '(font-lock-syntactic-face-function
                      . js-font-lock-syntactic-face-function)))
  (setq-local syntax-propertize-function #'js-syntax-propertize)
  (add-hook 'syntax-propertize-extend-region-functions
            #'syntax-propertize-multiline 'append 'local)
  (add-hook 'syntax-propertize-extend-region-functions
            #'js--syntax-propertize-extend-region 'append 'local)
  (setq-local prettify-symbols-alist js--prettify-symbols-alist)

  (setq-local parse-sexp-ignore-comments t)
  (setq-local which-func-imenu-joiner-function #'js--which-func-joiner)
```

Should absolutely not.

Does that make sense?  I don't think this is impossible, but my biggest
argument was that we need to keep things distinct, or at least be very
explicit on when we share code.

Theo