Fork me on GitHub
#calva
<
2018-12-14
>
richiardiandrea00:12:04

btw I am in the process of porting some cljs to orchard, stay tuned! 😄 Sooner or later we are going to have a cljs nrepl/lsp server going 😉

parrot 4
pez05:12:52

@richiardiandrea, I am staying tuned!

pez07:12:26

This is a very interesting project as well: https://github.com/snoe/clojure-lsp?files=1

pez08:12:29

@mseddon: Now develop is using the cond etc fixes. It's pretty nice! So nice that I published it. 😃

mseddon09:12:38

great! 😄

mseddon10:12:08

clojure-lsp, huh. yeah that does look pretty cool.

mseddon10:12:10

@pez ah, uhoh! couldn't find pez.cljfmt.0.0.3-SNAPSHOT, when trying to build calva-lib. Is that just a renamed version of cljfmt on master published to your local maven?

mseddon10:12:38

ah, no, a bit of detective work says it is the calva-fmt branch of your fork here https://github.com/PEZ/cljfmt/tree/calva-fmt/cljfmt 🙂

pez10:12:43

Did I foget to publish it?

pez10:12:19

Thinking about it… with this build process I might not need to have my own Clojars entry for it. But maybe it gets a bit too complicated if people must clone that repo out as well and lein install and stuff, even if they are not going to hack on that part (I am hoping we shall need hack on that fork as little as possible.)

pez10:12:00

There, now deployed. 😃

pez10:12:07

I need to automate much of the process…

mseddon11:12:01

oh, alright let me try that 🙂

mseddon11:12:19

yep, it found it, thanks 🙂

pez11:12:13

:the_horns:

mseddon11:12:52

do you want me to just replace my formatter.cljs into the one on calva-lib? there seem to be quite a few changes, but mostly relating to whether you :refer stuff, some old zprint cruft, etc. I'm trying to work out if there's anything that actually wants to be kept from calva-lib.

pez11:12:33

The most important part is probably if things are properly exported.

pez11:12:29

I tend to litter the files down a bit with (comment) block experiments. 😃

pez11:12:59

I blame Calva, making it so easy to evaluate top level forms inside comment blocks.

mseddon11:12:32

yeah I can't see anything major- I'll move the :exports from the old calva-fmt into lib

mseddon11:12:37

see what breaks 😉

pez11:12:53

That :refer sounds interesting. Might be that I have required clojure.string because the new build conf uncovered that breakage.

mseddon11:12:19

aha, yes! I see that

mseddon11:12:24

I will add that one back in

pez11:12:26

About those comment blocks and various playground.clj* files you might find. I have been thinking if maybe I should add a Calva command for automatically creating a playground file for the file I am editing and open it up, split view, so then you I can play and experiment there. And these files would be meant to be commited to the repo.

mseddon11:12:18

yeah, there was something like that for intellij/scala... i forget what they called them, 'worksheets' or something

mseddon12:12:10

they had a special extension to differentiate them from standard source iirc

pez12:12:23

.playground in Swift XCode.

pez12:12:49

But maybe you are thinking about notebooks, rather?

mseddon12:12:34

oh, maybe! it's been ages since I used IntelliJ 🙂

pez12:12:26

I was thinking about Maria and Gorilla REPL stuff, rather.

mseddon12:12:55

oh yeah, gorilla repl is really cool 🙂

pez12:12:26

Did you merge the crlf-dabble branch into latest develop when you created your crlf branch?

mseddon12:12:47

not at the time, i'm basically doing that all now 😉

mseddon12:12:03

I think I have some sane merges now

mseddon12:12:57

although on the calva-lib side i've basically nuked formatter.cljs with the crlf one.

pez12:12:36

I'm a bit worried that I might have done something else important since I failed to fix the crlf thing.

mseddon12:12:13

I couldn't see much on the cljs side, but there were a bunch of tweaks with 'extraConfig' and things in the .ts side of clj-fmt, which I've tried to accomodate

pez12:12:00

Those extra configs were the eol stuff, or?

mseddon12:12:27

you have a js object passed in called extraConfig, which gets merged into the config passed into formatter.cljs on the ts side

mseddon12:12:40

and i've added in the extra :eol key from that side as well, now

pez12:12:21

extraConfig is a bad name, i have no memory about what it could be about 😃

mseddon12:12:41

just about to play the npm link game and see if anything still works...

pez12:12:43

I think I might also have moved all parinfer stuff to inferer.cljs.

pez12:12:06

But the tests should have told you that… 😃

mseddon12:12:15

the compiler is bitching currently, 🙂

mseddon12:12:35

apparently we don't have zprint.core anymore.

pez12:12:06

I think that is commented out in shadow-cljs.edn

pez12:12:27

But what would be trying to use it, I don't know.

mseddon12:12:38

totally pointless dep- it's only commented out in formatter.cljs

pez12:12:32

Clean away all zprint stuff, it is just leftovers from when I thought I could use it.

mseddon12:12:04

ah, okay, a few bits, (I love code restructures don't you? ;)), util/current-line-empty? etc is missing in calva-lib, but I can move them over...

pez12:12:31

missing? that sounds strange.'

pez12:12:58

No, I moved those to formatter,cljs.

pez12:12:10

I moved anything that ”knows” things about the mmap from utils.cljs.

pez12:12:14

Maybe it is better to start from calva-lib fresh and apply the crlf things on it by hand.

mseddon12:12:22

aaaaaah, right, okay that's easy enough to put back then.

mseddon12:12:56

basically it's down to my merge of clrf:formatter.cljs, I just nuked out some of those utility functions 😉

pez12:12:44

I guess we will see when we diff things from what it looked like before you dropping that nuke.

mseddon12:12:07

it's a noisy diff 🙂

pez12:12:59

I have mostly been busy getting the new build conf to work, so not all that many things could have happened with the actual code. 😃

mseddon12:12:10

you're right though, it may be easier to just manually put the crlf changes back... 🙂

pez12:12:06

It's amazing how fast a branch can rot even with just one dev who has very little time with the project. 😃

mseddon12:12:34

😄 We all end up here.

mseddon12:12:56

it's just too easy to create forks 😉

mseddon12:12:23

no version or publisher fields, but I assume this wants to resolve to "@cospaia/calva-lib": "^0.0.17"

pez12:12:06

Haha, it's much tricker than that. 😃

mseddon12:12:33

uh oh 😄

pez12:12:50

The package.json for the calva.lib the npm module is in /packages

mseddon12:12:20

so I will want to compile and then run npm link from THERE, I guess.

pez12:12:23

The one you found is mainly the build scripts for building the module.

mseddon12:12:36

lol. I just published junk locally. 😉

pez12:12:41

Yes, I hope I got it right on the wiki.

mseddon12:12:50

I probably didn't read it right, let me go back. hurrr

pez12:12:20

The missing version field stops me from publishing junk on http://npmjs.com 😃

mseddon12:12:48

ah yes, there it was 😄

mseddon12:12:54

and good plan 🙂

pez12:12:31

Maybe we should add something in that json file about where to find the real one. 😃

pez12:12:55

Maybe even a README for the calva-lib repo! Haha

mseddon12:12:06

😄 early days

mseddon12:12:14

but yeah it probably ought to be cleaned up

mseddon12:12:44

but this crlf merge is going to be a nasty PR I suspect so I don't want to do a million other things as well 🙂

pez12:12:14

Zero other things seems like the perfect amount of other things.

pez13:12:21

If I can assume correctly where the calva-fmt project is checked out I can do the link as part of the watch and release tasks.

mseddon13:12:03

link only needs to be performed locally once

mseddon13:12:15

unless you trash your node_modules dir of course

mseddon13:12:58

well. everything works except my crlf fix... 🙂

mseddon13:12:01

it's not quite as terrible a diff as I feared once I'd cleaned it up a little

mseddon13:12:02

check the review notes though, for some reason shadow-cljs exports have nerfed and so we're back to a snake_case api for TS, which sucks, and I'd like to remove that 'feature'.

pez14:12:08

snake_case wasn't introduced by crlf, however.

pez14:12:38

With the old build conf you had to specify the function names manually, which wasn't too fun. Also that API sucked more since it wasn't namespaced at all.

mseddon14:12:57

ahh, fair enough

mseddon14:12:18

hold off merge for now though, I am seeing some test failures... sigh

mseddon14:12:16

ah, it was easy, forgot to pass :eol "\n" during the tests. Okay, that ought to work now, back to the 6 new-index-at-top-level failures.

pez14:12:12

I'd like for us to not revert the library API with this PR. The API will fatten when Calva starts to use it as well. snake_case is a price i am willing to pay.

mseddon14:12:43

no problem, I will remove those :exports declarations

❤️ 4
mseddon14:12:40

(and look into those damn new-index-at-top-level failures)

pez14:12:21

I think those should be handled by trying to stop vscode to indent anything at all.

mseddon14:12:35

ah, right, are you fighting it there huh?

pez14:12:07

I have been fighting it everywhere.

mseddon14:12:24

can we kill it dead if we override the return key?

mseddon14:12:36

that may kill two birds with one stone if we reformat+insert \n then

pez14:12:43

Certainly.

pez14:12:04

But i think this one might be as simple as just configuring vscode to not indent. Just that i only thought about that option first time a few days ago.

mseddon14:12:25

🙂 I will have a dig around and see.

pez14:12:48

I won't be by a computer for a while now.

pez14:12:08

Hours. Not days. 😀

mseddon14:12:40

🙂 phew. Anyway I am in no mad rush to merge+publish that crlf fix, take your time and check through, I may still be being an idiot somewhere. It should be good as far as I can tell though.

pez14:12:32

I think i bad some out-commented test for crlf. Not sure if i kept it, though.

mseddon16:12:49

yick. so I've spent the day with the docs. vscode is.. rather lacking in many places in the API.

mseddon16:12:06

I am considering biting the bullet and building a full blown language server to deal with it

mseddon16:12:21

since the more I dig into the good extensions the more I see they gave up and did that 🙂

mseddon16:12:39

for example, solving the toplevel indent issue is pretty damn hard without performing a lot of extra work tracking the AST as the changes come in

mseddon16:12:11

plus also we don't really want to be passing the whole document across to the plugin for formatting long term because of fun performance issues

mseddon16:12:49

BUT, I can't even gain access to the tokenization information from the buffer, so that would have to be performed by us again, which is silly.

mseddon16:12:21

e.g. in emacs it's really quite easy to write a decent lisp formatter, because you can peek at the partial parse state across lines, we literally just have a blob of text, despite the fact somewhere in vscode, it knows the extent of folds, parenthesis, etc 😕

pez17:12:58

Vscode language servers are constrained by the same API as language extensions, aren't they?

mseddon17:12:11

yeah, technically we can do it inside vscode

mseddon17:12:46

but e.g. if I know that the first character of a line is inside a string, I can wind back one line until we're not inside one

mseddon17:12:12

then lex it forwards to figure out where we are. Without that information locally lexing like that is just not possible

mseddon17:12:28

so.. yeah. I can see why you throw the whole document about 😉

mseddon17:12:21

I think the main 'reason' for considering going the LSP route is that other editors also support it, like vim, sublime etc. so at least it's reusable.

mseddon17:12:42

that and/or backing off into jvm land for those extra cpu cycles

mseddon17:12:33

hmm. although sort of all that data seems to be being maintained inside paredit, right?

mseddon17:12:19

bleh. that is also consuming the whole document.

pez17:12:55

As is, Parinfer. While maintaining speed, even. 😉

mseddon17:12:16

going to try Ctrl+W on that giant file and get back to you there 😄

mseddon17:12:17

12k line file containing only this repeated over and over:

(defn sqr [x]
  (* x x))

mseddon17:12:30

Ctrl+W takes 4 seconds to expand the selection 😉

mseddon17:12:07

huh, it did seem to speed up to around 300ms, but that's still pretty sluggish.

pez17:12:17

Probably optimization no kicking in.

mseddon17:12:05

so for e.g., one stupid solution to the line terminator is to just mash Ctrl+W to get the whole range of the toplevel expr, then look at the column of the selection start...

pez17:12:12

Which will be zero.

mseddon17:12:10

oh, sorry i mean the selection END

mseddon17:12:24

basically we need to know if we're in a toplevel

pez17:12:40

There is already a command to get the top level selection. Try ctrl+alr+w space.

mseddon17:12:54

ah. yes. him.

mseddon17:12:14

okay well from that I think I can botch around the indent at end of expressions

mseddon17:12:17

although it's... yick.

mseddon17:12:29

and also then there is a hard dependency on calva-paredit in calva-fmt.

pez17:12:34

Calva-lib is using paredit.

mseddon17:12:37

all of these contortions are silly, of course, because somewhere inside vscode, it knows where the parens are.

mseddon17:12:57

ooh, right, sorry I am thinking of how everything was yesterday 😉

pez17:12:14

It was yesterday too.

pez17:12:22

So when indenting the current form, it uses paredit to figure out what the current form is.

mseddon17:12:21

oh, also I am confused slightly about the (let [indent-token "0"] ,,,), in add-indent-token-if-empty-current-line it looks to me that somehow it would barf on literal "0"'s in the text, but mysteriously it does not.

mseddon17:12:50

is it because it will ALWAYS be paired with remove-indent-token?

pez17:12:20

It's the trick i use to figure out the indent when the cursor is on a new line.

pez17:12:55

Haha, that’s why I have asked for the community formatter to consider the cursor position.

mseddon18:12:42

doh! s'cuse my n00bishness. 🙂

pez18:12:12

It would be sweet to have a CI pipeline set up to catch things like this.

mseddon18:12:25

yeah we should look into that.

mseddon18:12:38

i get a couple of test failures btw

mseddon18:12:00

FAIL in (format-text-at-range) (at C:475:6)
expected: (= "(foo)\n(defn bar\n  [x]\n  baz)" (:range-text (sut/format-text-at-range {:eol "\n", :all-text "  (foo)\n(defn bar\n[x]\nbaz)", :range [2 26]})))
  actual: (not (= "(foo)\n(defn bar\n  [x]\n  baz)" "(foo)\n  (defn bar\n    [x]\n    baz)"))

FAIL in (format-text-at-idx) (at C:475:6)
expected: (= "(defn bar\n    [x]\n\n    baz)" (:range-text (sut/format-text-at-idx {:eol "\n", :all-text all-text, :idx 11})))
  actual: (not (= "(defn bar\n    [x]\n\n    baz)" "(defn bar\n    [x]\n  \n    baz)"))

pez18:12:40

I wonder if we can “advertise” somewhere for someone with experience with it CI for vscode extensions.

pez18:12:31

We should steal that formats-to? function from cljfmt. 😃

mseddon18:12:35

yeah, i am a bit worried about crlf's toasting those multiline strings

pez18:12:26

I only get those 6 “expected” failures..

mseddon18:12:33

then.. that is probably what has happened.

mseddon18:12:43

does the crlf mode behave as expected?

pez18:12:29

Haven’t tried it yet. Went for a release build first thing. Will try now.

mseddon18:12:28

the dac9531 one should fix the derpy release issue

pez18:12:01

dac9531?

pez18:12:12

ah, a new commit?

mseddon18:12:20

yeah, that fixed release

mseddon18:12:29

or at least, didn't blow up for me.

mseddon18:12:40

it may introduce weird test failures on those 2 cases.

mseddon18:12:59

I think I may have been staring at this code too long today. 🙂

pez18:12:02

CRLF mode misbehaves for me. (Haven’t pulled dac9531 yet)

mseddon18:12:49

ah, yeah, i think that may have been toast, hence the new test failures...

mseddon18:12:25

the difference was somewhere i managed to omit the call to normalize-indents, so everything wound up working as before for a bit

pez18:12:58

I’m a noob with PRs. How do I pull dac9531?

mseddon18:12:14

just re-pull

mseddon18:12:21

should get the latest version

mseddon18:12:40

I force-push upstream to and that should update the PR

pez18:12:15

It complains about no tracking information.

pez18:12:38

I need to run now. Will figure it out later.

mseddon18:12:07

probably just git branch -D it and start over 🙂

koala punch19:12:59

hi, is calva suppose to highlight code that wont compile?

koala punch19:12:32

so it’s something that is coming soon then?

pez19:12:40

Sort of. You'll need to switch linting on.

koala punch19:12:55

i like the plugin its bette rthan then other ones

koala punch19:12:07

how do i switch linting on

pez19:12:10

Glad to hear!

koala punch19:12:13

is that a setting in the repl?

koala punch19:12:19

i get linting for bad tests

koala punch19:12:22

but not bad code :~

pez19:12:31

It's a Calva setting

koala punch19:12:50

i see inthe docs now

koala punch19:12:47

that’s better

koala punch19:12:02

in your video you showed things like inline evaluation

koala punch19:12:08

but the evaluation that I get is in the terminal

pez19:12:13

They are separate commands. Check cmd+shift+p and type calva.

koala punch20:12:31

there are like 10 evaluate commands

koala punch20:12:34

and none of them mention inline

koala punch20:12:07

8 evaluate commands sorry

pez20:12:20

I think those not mentioning inline are inline. 😃

pez20:12:11

I mean, those not mentioning the terminal. (I’m a bit tired)

pez20:12:59

My favorite is ctrl+alt+v space for evaluating the top level form the cursor is in.

pez20:12:48

It also works inside comment forms (disregarding the comment form, so to speak).

pez20:12:44

Generally the evaluation commands with alt+ after the chord are terminal equivalents of the inline ones.

koala punch20:12:34

well thanks for your help

koala punch20:12:50

evaluate current selection was the one i was looking for 🙂

mseddon20:12:20

@pez, okay, so I've been poking around vscode internals all day. I think I have a good solution to a lot of the irritating fiddles we have with formatting atm, but it's going to take a while to put together. All the bits I need are there. Watch this space 🙂

pez20:12:10

Cool. Please share some of your findings!

mseddon20:12:37

I shall! It's a bunch of upfront work but I'll let you know when it (begins) to work 😉

mseddon20:12:34

fortunately I have a lot of the pieces sitting around on my hd..

pez20:12:48

@christopher.paul, I most often evaluate current form instead, ctrl+alt+e. So if you have the cursor right before or right after a form, that will be evaluated. (But evaluate selection comes in handy at times too, of course.)

pez20:12:10

@mseddon, I’m a curious guy. 😃 What are the fiddles and what are the findings are two questions in my head right now.

pez20:12:48

Why do you need to force push to your crlf-fix branch, btw? Github won’t show me the diffs when that has happened.

mseddon20:12:13

oh, sorry that's just habit from scala.js 🙂

koala punch20:12:25

yea i think i prefer ctrl+alt+v space now

mseddon20:12:45

@pez I'll stack the updates until it passes code review, then squash the commits into a single one for merging, sound good?

mseddon20:12:58

that way we get a clean 1 commit per feature/fix, so we don't play untangle the commit history later

koala punch20:12:35

shouldn’t need to force push, that’s usually bad 🙂

mseddon20:12:52

it's okay for PRs, but for heaven's sake don't do it on master 🙂

pez20:12:25

I’m fine with a granular history.

mseddon20:12:45

alright, we'll do it that way then 🙂

pez20:12:12

But even if you squash your local history, you should not need to force push, right?

mseddon20:12:57

that ought to work, although i got complained to for not squash/force pushing on another project. 🙂

mseddon20:12:33

It's a little bit of cargo culting on my part though, I'll admit.

pez20:12:19

Yes, people really have different prefs. But this is still a very small project so I think we can manage the history.

mseddon20:12:35

that's fine by me. also less scope for screwups on either end

pez20:12:11

I think it is nice to be able to check the diffs on github just to orient myself on what it is I am pulling.

mseddon20:12:31

regarding the fiddles- the main issue is we're basically re-doing a lot of work vscode is doing incrementally in one big lump on newline... which just makes me cringe. It makes it really difficult to track where everything is from within the extension trivially

mseddon20:12:02

so I've figured out on paper and through some tests I can quite easily build an incremental lexer that works from editor events, that only redoes exactly the work it needs

mseddon20:12:29

but because it's incremental, I can build a data structure that will always let you correlate the clojure AST to a file offset

mseddon20:12:24

which suddenly means, for trivial format on type, we can use much simpler, incredibly quick formatting rules based on cljfmt, and drop to clj-fmt proper for 'full' formatting

koala punch20:12:03

you can squash commits without force pushing

mseddon20:12:54

I am not touching -f again 😉

koala punch20:12:17

i’ve been there and got mysef in many messes

mseddon20:12:36

I've remained unscathed so far. let's quit while I'm ahead. 🙂

koala punch20:12:06

do you do this stuff just in your free time, pez?

koala punch20:12:11

or is it your job 😄

mseddon20:12:36

but it seems with a push +[branch], that is not necessary

koala punch20:12:59

i’m pretty sure you can squash your commits against your fork

koala punch20:12:01

then just do a PR

pez20:12:04

I think that what @christopher.paul and I are saying is that this is key: ” If you’ve already pushed commits to GitHub”. If you haven’t then no need to force.

koala punch20:12:19

you can always force to your fork i guess

koala punch20:12:28

but can then do a clean PR to origin

mseddon20:12:30

yeah, it's basically, once the PR is sent, the only way to squash without force is to close the the PR and open a new one

mseddon20:12:43

yeah, so I'm pushing to my fork in a PR

mseddon20:12:03

because that way only I feel the searing pain of my own stupidity 🙂

mseddon20:12:20

except it bit pez. so... that didn't go well 😉

pez20:12:41

Hmmm, but I don’t think we need to squash away earlier pushed commits when adding commits to a PR.

mseddon20:12:18

that only really applies if you want a '1 commit per issue' policy

pez20:12:25

Personally I think it is totally OK to push all intermediate commits when preparing a PR.

pez20:12:00

But, yes, if it is a lot of commits involved and it has taken a while, maybe a rebase -i and curating the history could be good. But subsequent commits after the PR is sent will be hard to follow if they are force pushed.

pez20:12:42

No “1 commit per issue” policy applies to Calva, I would say. 😃

mseddon20:12:55

works for me 🙂

pez20:12:49

Awesome. Let’s hope so many people are throwing themselves at Calva contributions that we will feel the need to reconsider policies. 😃

mseddon20:12:21

😄 exactly. that is a good problem to have

pez20:12:31

I get those two extra test failures now, btw.

mseddon20:12:46

ahh, yeah. weirdly I can't reproduce them in the editor proper

mseddon20:12:14

but I didn't write those tests, so it's possible there was a particular situation you were thinking of

pez20:12:05

The tests look sane to me. 😃

mseddon20:12:33

🙂 i may just be going mad at this point

pez20:12:50

The tests are a bit hard to “read” because of newlines being entered as escapes. I like how that is handled in cljfmt.

koala punch20:12:15

pez, vscode doesn’t seem to recognise this setting: “calva.autoAdjustIndent”

koala punch20:12:28

i’m trying to disable it as i like to use parinfer

koala punch20:12:34

is that definatly the right key?

pez20:12:48

I think some things around these tests have moved between my attempts to fix the crlf thing and now. Getting more and more convinced it is better to apply the crlf fixes on develop HEAD:

mseddon20:12:51

yeah, I think I may have missed something you did in crlf-dabblings

pez20:12:03

Calva isn’t really very compatible with the parinfer extension, @christopher.paul. What error do you get with that setting?

pez21:12:29

There is some little parinfer built in to Calva, to compensate for this incompatibility. So you can get parens inferred with ctrl+alt+p for instance. And indent stuff with parens being inferred meanwhile with ctrl+i (dedent ctrl+shift+i).

koala punch21:12:06

yea it seems pretty funny

koala punch21:12:14

i really like parinfer in other editors

pez21:12:18

I think that setting, calva.autoAdjustIndent might have moved to Calva Formatter and I might have forgotten to remove it from Calva. (It is not obvious maybe, but when you install Calva you also install Calva Formatter and Calva Paredit and those have their own settings keys.

pez21:12:37

Me too! Parinfer is awesome.

pez21:12:57

But VS Code doesn’t have the API:s Parinfer needs so they can’t really make it work fully as it is working in other editors.

pez21:12:26

And the parinfer extension that is there now competes with Calva Formatter (and often wins, because it is faster).

koala punch21:12:10

i wondered why shaun had said he’d come back to it later

koala punch21:12:15

i guess it’s easier to do in ato

pez21:12:37

Search for “Format as you type” in settings to find the option to switch off Calva Formatter’s help with that. (Even if I think it is a better choice to settle with Calva Formatter’s on-command inferring of parens).

koala punch21:12:56

i’ll stick with your one for now

koala punch21:12:15

parinfer greys out the closing parens

koala punch21:12:18

what do you think of that

koala punch21:12:23

i think it’s really nice if it’s doing them for you

pez21:12:25

I love it. 😃

pez21:12:42

That should be added to Calva.

pez21:12:49

Maybe Tonsky’s Clojure Warrior is compatible with Calva… at least he is a Calva user and probably would have complained otherwise, I’ll try that extension now. It says it adds some coloring of the paren trail.

kstehn21:12:26

Yes it works i use it for the coloring 🙂

pez21:12:34

Nice! Trying it now. Will take me a while to get used to the coloring, but I’ll stick with it a while.

koala punch21:12:07

i dont like colors

koala punch21:12:14

i like one colour but the end ones faded

koala punch21:12:21

becuase different colours to me mean different context

koala punch21:12:37

sometimes blue sometimes green is hard for my brain

pez21:12:45

OMG. Now I can switch off VS Code’s stupid highlighting of matching brackets. <-- @pedrorgirardi

pedrorgirardi02:12:19

OMG thank you @pez! VS Code’s bracket highlighting tricks me. 🙂

kstehn21:12:42

the coloring is pretty helpful because it is based on intendation level so it gets easier to see when one form is not in the right level

koala punch21:12:38

maybe i just have to get used to it

koala punch21:12:49

the brackets are more eye catching than the code

pez21:12:41

That’s what I was addressing with that it might take me some time getting used to. Maybe a careful selection of colors will be easier on the eye: clojureWarrior.bracketColors.

mseddon21:12:36

@pez, huh, he's doing what I'm doing in this test 😉

pez21:12:26

Which test?

koala punch21:12:15

well used the to massively grey them out

koala punch21:12:19

so that’s kind of nice )

mseddon21:12:21

attempting to figure out what the hell is going on inside a vscode buffer 🙂

mseddon21:12:41

although I'm working incrementally on the data as you type

mseddon21:12:07

(and not re-scanning the whole document like he is)

pez21:12:30

@christopher.paul, this greys them out and keeps some of the nesting level info:

"clojureWarrior.bracketColors": [
        "#fff",
        "#ddd",
        "#bbb",
        "#999",
        "#888",
        "#777",
        "#666",
    ]

pez21:12:59

Who is”he”, @mseddon?

koala punch21:12:20

i’d set them all to 777 🙂

mseddon21:12:59

@pez Tonsky in that bracketcolors extension

mseddon21:12:38

effectively I'm doing the same thing he does in his updateRainbowColors, but i cache the state of the lexer (inside string, etc) for each line,

mseddon21:12:09

so i trigger an update at the edit point, and scan down each changed line

mseddon21:12:26

but then i can know where all the brackets are, what symbol starts a term, and the indent level

pez21:12:49

Can you make a config of the formatter that behaves like his suggestions with that?

mseddon21:12:45

In principle, sure!

pez21:12:12

Yeah, but I thought maybe cljfmt isn’t needed for this. But maybe it is.

mseddon21:12:32

oh, it's not needed for my little experiment- the idea here is to have a fast path formatOnType

mseddon21:12:47

which has a little better control over what's going on than we currently have

pez21:12:23

How are you planning to get the rules of cjfmt enforced?

mseddon21:12:51

working off a copy of his rules

pez21:12:15

I see. Nice!

mseddon21:12:27

but of course, this is fast but imperfect, it may not be 100% cljfmt compatible

mseddon21:12:37

but for indenting whole blocks of code, we can still use cljfmt

pez21:12:51

Really cool.

mseddon21:12:56

mostly because in those cases we don't have anywhere near the horrible problems of cursors jumping around

pez21:12:59

I hope you succeed!

mseddon21:12:05

wish me luck 😄

mseddon21:12:35

you.. quite literally were 😄

pez21:12:53

You should be able to source the rules from cljfmt, right?

mseddon21:12:06

those indent rules basically drive cljfmt, and should be fairly easy to translate

mseddon21:12:18

i don't think cljfmt does any fun pretty print conditional newline stuff

pez21:12:27

I mean without copying them manually.

pez21:12:37

No, I don’t think it does.

mseddon21:12:00

well, i will naturally write a script to transform those rules into a bit of json 🙂

mseddon21:12:14

I don't want to spend the rest of my life manually keeping them in sync 🙂

pez21:12:38

You’re not doing this in cljs?

mseddon21:12:50

i'm keeping it in ts atm, mostly because it's very mutable statey

mseddon21:12:04

plus it's easier to have intellisense on the vscode api for now..

pez21:12:05

yeah, i can relate.

pez21:12:11

But when you have it pinned down, I’d like to see how it can be factored so that most of the “logic” is in cljs. 😃

pez21:12:52

See, I’m already banking on that you will pin it down.

mseddon21:12:52

no pressure 😉

pez21:12:27

How about we divide the labour such that I apply your crlf fixes on develop HEAD and you focus on that incremental indenter?

mseddon21:12:33

sure thing!

mseddon21:12:54

I suspect I missed something you did in your work and accidentally removed it anyway 🙂

pez21:12:03

I have been the only one working with this stuff and that has “allowed” me to be a bit sloppy with things.

pez21:12:02

How about this, @christopher.paul?

"clojureWarrior.bracketColors": [
        "#666",
        "#777",
        "#888",
        "#999",
        "#bbb",
        "#ddd",
        "#fff",
    ]