This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # announcements (1)
- # aws (3)
- # beginners (41)
- # boot (109)
- # braid-chat (2)
- # braveandtrue (5)
- # cider (11)
- # cljs-dev (38)
- # cljsjs (15)
- # cljsrn (5)
- # clojure (87)
- # clojure-berlin (16)
- # clojure-ireland (1)
- # clojure-japan (10)
- # clojure-madison (3)
- # clojure-nl (3)
- # clojure-poland (6)
- # clojure-russia (115)
- # clojure-sg (1)
- # clojurebridge (35)
- # clojured (8)
- # clojurescript (36)
- # core-async (24)
- # cursive (18)
- # datavis (1)
- # datomic (27)
- # dirac (22)
- # editors (1)
- # emacs (3)
- # events (19)
- # hoplon (149)
- # ldnclj (7)
- # lein-figwheel (1)
- # luminus (1)
- # off-topic (70)
- # om (196)
- # onyx (63)
- # parinfer (155)
- # proton (36)
- # re-frame (69)
- # reagent (2)
- # ring (2)
- # ring-swagger (1)
- # slack-help (4)
- # spacemacs (9)
- # testing (11)
@cfleming: modifying parinfer for the lexer may be more trouble than it’s worth, especially since kotlin parinfer is really fast
@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)
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.
The async nature of this integration makes a lot of the edge case rules pretty hard.
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.
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.
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 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.
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'
JetBrains basically don’t test the UI, nearly all their tests are model based as I described, and they assume that the UI works.
For web stuff, Selenium is really good I think, but it doesn’t help with design/layout bugs.
so much effort going into stubbing out function paths and verifying if certain things are being called, and how many times
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.
even though this idea might fail a lot, i think it’s important to keep trying for sure
nasa tried something similar for creating their software, so that requirements could be specified in flow, and then directly executed
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
I’m actually considering trying to pull the whole user guide into the IDE as an interactive tutorial.
The animations are neat, though, I stole the idea from the competition: http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.html
And even if you rely on canvas and ditch the fallback, it still works pretty much everywhere (including phones etc)
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.
I have some ideas about something like a typing tutor for paredit, for example, that could work well with that.
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.
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.
you might be able to get away with just auto-indent the parent form altogether, unless speed is really that bad
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.
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
for example, it will keep your cursor from moving if you insert a close-paren that parinfer removes
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.