@snoe: yup, that's one of the things which were strange. but since it takes time and thinking and self-observation before i can ask well formed questions, i was hoping i could just get a better feeling for it from seeing some one else using it.

we were test driving visual studio code, btw, so see if we can transition to it from sublime. the main motivation for the switch is the integrated git support with the great side-by-side, editable diff interface. until now not having any explicit clojure editing support was a show stopper, so i had high hopes for parinfer, but the learning curve has a non-obvious shape

@chrisoakman: if u haven't used paredit, how were u writing clojure before?

our company just started using clojure about a year ago and the 1st ~6 weeks we did without paredit, but it was a major pain. we often fired up lighttable to fix unbalanced parens, because we used hoplon which compiled to clojurescript and it didn't throw any errors about certain paren unbalances and we just got an empty page... we used tabs for indentation to remedy this situation to some extent but then i bit the bullet and learnt paredit, figured out how to configure for sublime and since then we never looked back. the rest of the team picked it up in about a week or two too.

it would still be a pain to worry about indentation, so since we found the lispindent sublime extension we hardly ever worry about indentation anymore. we have even switched back to spaces for indentation, though it makes using proportional fonts non-feasible... 😞

I was surprised that parinfer didn't help me with "". Has there been discussions around that?

@maxt quotes are the bane of my work with parinfer

they simply cant be inferred like parens, because (a) multiline string conventions dont follow indentation rules and (b) quotes are non-directional so their contents can turn inside out if a single quote is typed behind them

You're right, that's too bad 😞

i dont know how to fix it

if keyboards had directional quote keys, this wouldnt be a problem

imagine if we didnt have directional paren keys

we'll just have to start writing qoutes like \`\` ''

parinfer is not the only reason unidirectional quotes are poor

right

actually parinfer could handle them fine if it werent for semicolons

well parinfer could never infer quotes

but semicolons in strings or a single quote in comments actually break parinfer by causing intermediate states to be parsed by parinfer

by break i mean corrupt strings after quotes are typed one at a time

@maxt do you have any references on unidirectional quotes causing problems in other domains?

No, sorry, I was mainly referring to that it makes it harder to read. Quotes where originally directed but that was simplified with the advent of the typewriter (well, I don't have a referrence for that either ) In addition to that I've experienced many syntax-highlight errors in editors which probably could have been made less severe if it wasn't for the even/uneven issue

alright thanks

@onetom: before Parinfer I wrote Clojure like a caveman; manually closing parens and indenting everything by hand

that never bothered me, but it did seem to bother other Clojure developers who watched me 😉

now seems sort of crazy to write any Clojure without Parinfer

but u had some matching paren indicator or how could u stand it?

maybe we can bind some keys to open and close quote “ ” to indicate to parinfer our intention and it rewrites them to the unidirectional "

</brainstorm>

I used whatever Sublime Text does by default

@onetom what editor were you using that doesnt highlight matching parens? i thought most did that

@shaunlebron: sublime has some limit built in regarding how many characters should it match parens across (for performance reasons) we wrote a lot of html equivalent code, so we crossed that limit often

@snoe im afraid we'd have to do something like that

also sublime doesnt show extra parens either

oh that makes sense

vim has a "go to matching paren" key that i use all the time, i bet a sublime paredit plugin has that

@snoe i hope theres a better way, other than forcing editors to create a "view" for directed quotes, and then save the file with unidirectional, then re-infer directed quotes when opening

the simplicity of parinfer would be marred by this

I agree, I suspect that there's probably a non-perfect answer though that will fail safe

right now, I need to keep an eagle eye on my diffs 😛

@snoe im still thinking about your proposal to remove comments before transforming

but typing 'foo ;"' and prepending a quote would just never resolve

hrm if we saved invalid states it's possible we could save the fact that the ;" is a comment

for the record, I'd give up reversibility in comments if it preserved my code strings

that might have to be the compromise