No way to recognize additional function definition macros

[jasonjckn]

Libraries like https://github.com/gnl/ghostwheel have a macro >defn for defining functions, in one of my codebases i define >defn myself, but it's implemented with malli.experimental/defn

There's no way to adjust clojure-ts-mode syntax highlighting without forking the repo, e.g.

  (defconst clojure-ts--definition-keyword-regexp
    (rx
     line-start
     (or (group (or "ns" "fn"))
         (group ">def"
                (+ (or alnum
                       ;; What are valid characters for symbols? is a negative match better?
                       "-" "_" "!" "@" "#" "$" "%" "^" "&" "*" "|" "?" "<" ">" "+" "=" ":")))
         (group "def"
                (+ (or alnum
                       ;; What are valid characters for symbols? is a negative match better?
                       "-" "_" "!" "@" "#" "$" "%" "^" "&" "*" "|" "?" "<" ">" "+" "=" ":"))))
     line-end))

  (defvar clojure-ts--function-type-regexp
    (rx string-start (or ">defn" "defn" "defmethod") string-end))

There should be a general extension mechanism.

---

One random idea is we parse PROJECT/.clj-kondo/** edn files for :lint-as, e.g.

 :lint-as {
           mynamespace/>defn       schema.core/defn
           richelieu.core/defadvice clojure.core/defn
           }

Although doing this the proper way would probably add too much complexity.

[sogaiu]

Sort of related to:

There should be a general extension mechanism.

FWIW, for janet-ts-mode there was a similar request:

I would like to add a customizable variable janet-ts-indent-special-words to add extra custom values to indent-special. Mainly because I have been working on a DSL which includes a lot of defn-like macros which don't start with "def", and would like to be able to get good indentation for them without modifying janet-ts-mode directly.

So we did this.

[dannyfreeman]

Yeah we're going to have to add something similar to janet-ts-mode. Once semantic indentation is in I think I would like to consolidate some of the regular expressions and add an extension mechanism.

As for reading files, maybe reading cljfmt configuration files (based on the current project) would be worthwhile. See https://github.com/weavejester/cljfmt#configuration

[bbatsov]

@rrudakov has already addressed the part about the indentation and this is well documented in the README.

Regarding font-locking - I'm guessing we can add some configuration option similar to clojure-ts--builtin-symbol-regexp that will be appended to it, although it's a bit of a slippery slope here if we want users to be able to add symbols to every syntactic category that already has some hardcoded list of symbols. @rrudakov what do you think about this?

[bbatsov]

Note - the #4 ticket created by me is more or less on the same topic, so I'll probably close it.

[rrudakov]

@rrudakov has already addressed the part about the indentation and this is well documented in the README.

Regarding font-locking - I'm guessing we can add some configuration option similar to clojure-ts--builtin-symbol-regexp that will be appended to it, although it's a bit of a slippery slope here if we want users to be able to add symbols to every syntactic category that already has some hardcoded list of symbols. @rrudakov what do you think about this?

We partially discussed it here. Basically with font-lock it's a bit more complex, we could probably allow defining extra built-in keywords, but IMO it's not enough. For example I recently saw the following in Hiccup library:

In order to highlight the forms properly user should be able to express somehow in the configuration that those forms should be fontified as defn, but there might be other macros with different semantics, and highlighting only the first symbol would be not enough in the most cases.

Defining some DSL to describe fontification rules for different forms may be convenient for the users, but I think it will have huge impact on performance.

We can consider adding some defcustom, like clojure-ts-extra-font-lock-settings, where users would just add custom queries that will be merged with the default settings on clojure-ts-mode activation and will have zero performance impact. It would be very "low-level", but I think it would give users more freedom.

WDYT?

[bbatsov]

Sounds reasonable to me.

We can consider adding some defcustom, like clojure-ts-extra-font-lock-settings, where users would just add custom queries that will be merged with the default settings on clojure-ts-mode activation and will have zero performance impact. It would be very "low-level", but I think it would give users more freedom.

I assume that 90% of the use-cases for this will some custom def-like forms, so perhaps we can have some more generic defcustom and one geared towards things like defelem in your example, of >defn that started this conversation (e.g. clojure-ts-extra-def-forms).

[rrudakov]

Sounds reasonable to me.

We can consider adding some defcustom, like clojure-ts-extra-font-lock-settings, where users would just add custom queries that will be merged with the default settings on clojure-ts-mode activation and will have zero performance impact. It would be very "low-level", but I think it would give users more freedom.

I assume that 90% of the use-cases for this will some custom def-like forms, so perhaps we can have some more generic defcustom and one geared towards things like defelem in your example, of >defn that started this conversation (e.g. clojure-ts-extra-def-forms).

How would we know if the form has args vector? Or docstring (and at which position)? Or are just going to assume that all forms in this defcustom will be fontified exactly the same as defn?

[bbatsov]

@rrudakov We don't really need to know - the users who'd use this setting should know. :-) They'd use it if it fits their use-case or fallback to the more generic custom queries approach that you suggested earlier. In general most defn-like forms behave more or less the same, so I think this would be both simple and effective.

[rrudakov]

I think it can be closed now.