Hi! Wonderful that you want to contribute. I checked that list, and it’s still valid, I’d say, but it’s far from comprehensive. I’ll have a look and see if I can tag some more issues for this. One thing that pops to mind is the formatting of deftype where the user has to fight with Calva to get it formatted correctly. You should find it among the issues. The code around this is a bit untidy, but still I think it can be encouraged to do something smart around deftype to format the right amount of context. Then it comes down to what you think is fun to tackle.

I'll make sure to do that, then. Thank you for the advice! I guess this is the issue with deftype. Should I mention in the comments that I want to try to resolve it? https://github.com/BetterThanTomorrow/calva/issues/1957

Yes, a comment there would be nice. Thanks!

I added a comment with an idea for how I think this can be handled. Please don't hesitate to reach out for help finding your way around the codebase, @ahtunget.

Ok, thank you!

Hi guys, I have a question about codestyle in the project. Is it ok to refactor some TS code in declarative way (e.g. https://github.com/BetterThanTomorrow/calva/blob/f97bebaf6213cdf7799954faa1fc073c078d420f/src/cursor-doc/indent.ts#L163) using map/foreach or was it intentionally written like this?

We generally want to move to a more functional style. In some tight loops, like this one, it could be a performance issue, so it could be good to measure any such impact. That said, generally we want the PR to be focused on its thing, so it would only be a question for this PR, if it otherwise changes this code. If that makes sense? In this case I guess it might be relevant code for the PR, and to make the code clearer might make sense.

Hello @U0ETXRFEW! Are there any important bugs to deal with right now? I can try to pick it up. Or if not I'll go to find something in issues 🙂

@ahtunget Take a look at the issues and see what you might enjoy taking on.