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

[Philip Kaludercic <philipk@posteo.net>]

Theodor Thornhill <theo@thornhill.no> writes:

> 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))))

This also looks good.

> 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.

Yes, I do understand this point, yet my impression has been that this
was not always necessary.  The relative complexity of cc-mode might
necessitate a separate mode, but I don't see why that should be the rule
instead of an exception?