Why the square brackets? about cl-collider HOT 8 CLOSED

Glad to hear it's working well for you now! :)

I don't think there is an official cl-collider forum/chatroom or similar. I idle on the #cl-collider channel on libera.chat (IRC) just in case anyone drops by, but I haven't noticed any actual chatter there yet (and I think IRC has fallen a bit out of favor in general, sadly).

I'm not sure but maybe @byulparan would be willing to enable GitHub's discussions feature for this repo to allow users to share patches/sequences/Q&A/etc. It seems like it could be a good option in this case, and I'd be willing to help in the discussions if needed.

from cl-collider.

Ye~ I will turnon discussions feature soon!

from cl-collider.

Ah, great to know! Seems like the simplest solution for now is just to avoid square brackets and use the (list 1 2 3) syntax instead.

I'm a heavy user of tree-sitter in neovim, so I'd love for it to work in cl as well as everywhere else :-)

from cl-collider.

Makes sense. I'm already happy that I am able to get the thing up and running using standard, static syntax :-)

BTW: is there some kind of forum/group somewhere for cl-collider? I will most likely have a bunch of questions soon that aren't very suitable for github issues...

from cl-collider.

Great! Looking forward to it :-) Closing the issue now with this.

from cl-collider.

Hello and welcome to the world of Common Lisp :)

[1 2 3] is basically syntax sugar for (list 1 2 3). Simply replacing [ and ] with ( and ) won't be enough as then Lisp will expect that you are calling a function rather than creating a list.

The square brackets are indeed reader macros defined by cl-collider and are not a standard part of Common Lisp. They can be enabled using (named-readtables:in-readtable :sc), but they are optional and are not required if they break syntax highlighting/parsing in your environment.

In my experience they also seem to confuse SLY/SLIME as well, so I personally do not use them. I don't use tree-sitter for Lisp, and don't have a lot of experience with tree-sitter in general yet, so I'm not sure if it's possible to easily (re)configure it to recognize/parse them correctly. If you figure out a solution, please do share, as I'm sure there are users who would find that information helpful!

from cl-collider.

Oh, and let's see what the deal is with the issue over at tree-sitter-commonlisp. I suspect that this might be a bit tricky if it's purely a cl-collider macro...

from cl-collider.

Ah, I see your issue there (which you also mentioned in your initial post on this issue). I'm not sure they'd be interested in adding support for custom reader macros that are specific to this project, especially since other projects may set [ and ] to have entirely different meanings.

The ideal solution would probably be for tree-sitter-commonlisp to be able to automatically pick up the current *readtable* and reconfigure its parsing based on that. But I'm not sure if tree-sitter supports such a thing--from what I understand, it's mainly designed for parsing static syntaxes, and might not support handling redefinable syntaxes. I could be entirely wrong about that though, and maybe it is possible. I don't imagine it would be too easy though.

from cl-collider.