PARENS does require the bidirectional mapping, but that can be fixed trivially.

@cfleming: modifying parinfer for the lexer may be more trouble than it’s worth, especially since kotlin parinfer is really fast

chris and I will maintain the ports as the canonical one is updated

might be difficult to continue updating the kotlin fork

@shaunlebron: Yeah, I’m not sure if it’s worth it yet. It does have some nice features - everything is simpler because the state tracking is easier, and it works better with the existing infrastructure (everything is tracked using source offsets rather than line/col, allowing minimal updates to happen)

I’m going to evaluate tomorrow and see where it’s at.

oh okay, that sounds cool then if you got it figured out

But merging in future changes is definitely a concern.

yeah

Well, I have it figured out but not finished yet

btw

you gave an example I didn’t address

(let [x 10]<caret>)

just run paren mode when pressing enter

and you’ll get

(let [x 10]
  <caret>)

To ensure that the paren stays on the caret line?

Hmm

mike fikes does this in replete

The problem is that parinfer is run asynchronously after the event happens.

It’s actually surprisingly hard to detect “this change is as a result of this action"

I’d need to detect cases like “a change that only inserts whitespace including a newline” which would catch that case.

not sure about that heuristic

Me either.

The async nature of this integration makes a lot of the edge case rules pretty hard.

do you at least have a guaranteed order?

i.e. key event comes before document update event?

Yes, but it’s tricky due to the multiple document model.

I may have to try something more complicated where I try to detect key events and work out whether doc changes are as a result of them.

More or less what Dmitry suggested in the forum.

But events like cut & paste are tricky, since someone could paste a carriage return in there instead of pressing enter.

And doc changes as a result of other events like code reformatting are hard too, or at least have potential for lots of edge cases.

yeah, these edge cases seem difficult

that is my fear when I think about straying from mode invariants

yeah, I can totally understand that.

But things like the paren clamping are already changing those invariants to make things more intuitive/correct.

BTW I really like the idea of having the tests in Markdown - I wish I’d thought of that.

Currently I have a ton of test cases with the before/after cases in strings, which is really ugly.

I was going to have them in separate files, but then you end up with thousands of them.

I’ll be stealing that one

haha, cool

I just hate escaped syntax

what are your test cases for?

Tons of things - all the paredit stuff, for example.

I create files in syntax like (some test <caret> code) which I use to create an editor with a caret, then I run an action (e.g. slurp, barf, whatever) and then check that the output matches (some test) <caret>code or whatever.

But lots of them are multiline, and the formatting is important, so I can’t just use quoted forms.

IntelliJ actually has very few unit tests, they’re mostly of that type - set up a scenario, do some interaction, check the result. It’s much more robust to refactoring the underlying code than unit tests are.

I have a mix but probably 90% are interaction tests like that.

cool, seems like a lot to test then

Yeah, I have around 2000 tests I think.

i’m a bit spoiled by parinfer testing, it’s nice just thinking of pure functions

rather than interactions I mean

Right - lots of the tests are quite complex: Set up file1 to look like this, file2 to look like this, then make file3 look like this, run autocompletion, select the element called “foo” and make sure that the output of the files looks like file1’, file2’, file3'

Even with all that, things still break - it’s just so complicated.

really interesting

And lots of UI stuff is difficult to test.

I’m really curious about how others do UI testing

it seemed like a mess when I tried it

so many different layers to it

It generally is a mess.

and also trying to decide at which level to test

JetBrains basically don’t test the UI, nearly all their tests are model based as I described, and they assume that the UI works.

and brittleness of tests is a big issue for UI, unless design is done

They probably do some manual testing too I guess.

i was handed a spreadsheet of things to check before our last deploy at stripe

made me think, hmmm

yeah, I think that’s really common.

For web stuff, Selenium is really good I think, but it doesn’t help with design/layout bugs.

There are tools that compare image snapshots, but I think they’re very brittle.

stripe uses bitmap testing for the style guide, i think that makes sense

but for UIs in development, i don’t see much value in that

i was looking at a stub/mock/spy framework that we use

so much effort going into stubbing out function paths and verifying if certain things are being called, and how many times

Ugh

Those are really brittle too, in my experience.

and my last job had me writing tests in english, using cucumber

so the PM and QAs could write them

just didn’t work in practice

Did you like cucumber? A few people have asked for it.

for what I tried anyway

For Cursive, that is.

Ok

I didn’t read the full cucumber book, so I may not have used it correctly

I think there’s a lot of value in them being able to understand the tests.

I really liked the philosophy of it

Not necessarily write them.

agree

I think it’d work great outside of UI actually

In my last job we made a graphical UI and language for modelling transaction flows. The idea was that technical business analysts would be able to design the flows, but that turned out to be a pipe dream. But it was really valuable that they could understand them.

right on

even though this idea might fail a lot, i think it’s important to keep trying for sure

Parinfer, you mean?

oh, invisible segue

hehe

ha

it reminded me of visual representation for designing flows

nasa tried something similar for creating their software, so that requirements could be specified in flow, and then directly executed

Interesting.

We found it didn’t work that well.

We would have been better off with a language or DSL that forced a strict development model on actual code, which you could then introspect to produce the graphical flows from for consumption by BAs or whoever.

it turns out that text is better for skimming large code bases, and visual flowcharts lose their benefit once they get too large

One thing it did work extremely well for was selling the project.

Customers love a pretty picture.

yeah, that DSL idea seems ideal

everyone loves a pretty picture

Not the developers when they’d rather express what they’re doing in code

haha, true

did you design cursive website?

yeah, I did

It could use a little love

A lot, in fact. I’m about to start re-vamping the doc, which is sadly out of date.

nah, I think the typography is good

I’m actually considering trying to pull the whole user guide into the IDE as an interactive tutorial.

Thanks, that’s mostly Skeleton’s doing.

Although I swapped out their font, I don’t like Raleway

The animations are neat, though, I stole the idea from the competition: http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.html

nice

i wonder if mp4 is supported enough

and if it would look as sharp

Probably not, that’s basically lossless true colour

And even if you rely on canvas and ditch the fallback, it still works pretty much everywhere (including phones etc)

ah, there you go

I found the images got a lot bigger when doing non-trivial demos including autocomplete dropdowns etc - the diffs got a lot bigger.

If I did this as an interactive tutorial I could do something similar to what you did with codemirror.

Which would be much easier to keep up to date - some of those animations on the website are from IntelliJ 12 and a version of Cursive from 2 years ago.

I have about half a system written that would allow me to record them as macros, but there’s still a bunch of manual steps I’d have to do for things you can’t script easily.

(much like testing).

right, but not even sure how you would simulate cursive in the browser...

Well, if i did them as an interactive tutorial they’d be inside Cursive itself.

And I wouldn’t even have an online user guide.

I have some ideas about something like a typing tutor for paredit, for example, that could work well with that.

that makes more sense, haha

yeah, that’d be great

Ok, got to go. I think this change is probably getting too big. I’m going to try a smaller refactoring tomorrow which would create a small set of diffs instead of replacing the whole thing, and a few related changes.

alright, sounds good

I think I’m going to modify paren mode to return the lines which need reindenting, and then I’ll reindent them accurately using the Cursive engine.

yeah, auto-indent has to happen somehow like that

you might be able to get away with just auto-indent the parent form altogether, unless speed is really that bad

but yeah, talk to you later

That’s what I’m thinking, I’ll identify the top-level forms and wholly reindent them. Cursive will have to do the expensive part of the reindentation for that anyway.

Ok, seeya

i got parinfer returning the cursor position this morning

gonna add more test cases tonight to confirm

thanks cfleming for the push. way simpler than i thought. really important feature too

@shaunlebron: that’s pretty cool, is that mainly to make it easier to reposition the cursor after hitting enter? i’m adding parinfer to paren-soup and already got that working but it would still be useful

@sekao: oh hey zach 🙂

yeah this actually takes care of a few other cases. not just pressing enter

for example, it will keep your cursor from moving if you insert a close-paren that parinfer removes

any case where some part of the line before the cursor is added or removed

hey greetings shaun — that sounds perfect, i’ll keep an eye out for that update. i only spent last night shoehorning it into paren-soup and it is already way nicer to use than the current release version. i definitely want to add this to nightcode as well.

@shaunlebron: Oh great, thanks for that! I’ll look at the change and if I have time I’ll port the changes over to the JVM version.

I’m going to see if I can get the tests running in the JVM version using Gradle too, to avoid having to install before testing.

great, i'll post a note in here about the change when i release

luckily the change is really small, so we can update ports pretty easily

@sekao: excited to see parinfer in night code! also glad parinfer-jvm is already taken care of for that