Fork me on GitHub
#parinfer
<
2016-02-25
>
chrisoakman00:02:11

yeah; I would think that would be close to impossible unless you had it implemented

cfleming00:02:42

Anyway, I have to get a release out sometime soon, so I think I’ll go with this version and we can decide which implementation is better for the general version after some discussion.

cfleming00:02:57

To answer your earlier question, yes, IntelliJ can replace lines.

cfleming00:02:06

So I could use the original version and just update modified lines.

chrisoakman00:02:38

my general sense would be to try that first and then see if it's fast enough

chrisoakman00:02:59

sounds like IntelliJ is quite different than these other editors though

cfleming00:02:15

It definitely is - it’s way more complicated.

cfleming00:02:41

It’s actually amazingly sophisticated - people complain about the performance but don’t realise what it’s doing behind the scenes.

cfleming00:02:06

And with the new zero-latency stuff it’s more responsive for typing than everything but gvim.

chrisoakman00:02:15

I'm amazed that people were ever willing to use an editor that had any typing latency 😉

chrisoakman00:02:34

that seems like such a fundamental UX violation for a text editor

cfleming00:02:35

Well, Atom comes out pretty badly in the latency tests simple_smile

chrisoakman00:02:53

I suppose the criteria is "below a noticeable threshold"

cfleming00:02:11

That could be their new tagline: Atom - the performance of an IDE with the functionality of a text editor!

chrisoakman00:02:17

I'm a fast typer, but I don't think I would ever notice a difference between 10 and 20ms

cfleming00:02:23

Might not shift a lot of copies though.

cfleming00:02:55

Did you read the typing with pleasure article? It’s well worth a read, it’s really interesting and deals with perceived latency a lot.

chrisoakman00:02:19

I skimmed it; need to go back and give it a full read

chrisoakman00:02:47

one of these days I'm going to write an editor in a language that deals with concurrency properly

chrisoakman00:02:49

like Erlang or Pony

chrisoakman00:02:07

this is on my todo list once I have infinite time and infinite money

cfleming00:02:45

That shouldn’t take too long to achieve.

cfleming00:02:13

But most editor implementations aren’t actually concurrent at all.

cfleming00:02:31

IntelliJ has really good concurrency support, but editor modifications are still serialised.

chrisoakman00:02:53

I've given this some thought; haven't implemented anything to test it out yet

chrisoakman00:02:08

but my thinking would be to completely separate these logically different parts of the system

chrisoakman00:02:19

so the UI never has latency and only communicates through message passing

cfleming00:02:29

React Editor

chrisoakman00:02:50

I like the idea that "the syntax highlighting can crash" and have zero effect on the rest of the system

chrisoakman00:02:59

so could any plugin

chrisoakman00:02:09

hot-code swapping, live-updates, etc

chrisoakman00:02:13

like a true Erlang OTP system

cfleming00:02:44

Erlang is actually probably not a great choice though, I suspect.

cfleming00:02:48

Pony might be better.

chrisoakman00:02:07

I was reading the Pony docs last night 😉

chrisoakman00:02:18

the UI-portion would be pretty complex

chrisoakman00:02:35

Erlang has some support for wxWidgets, but I would love to not build the UI in wxWidgets...

cfleming00:02:37

In general, Erlang is actually quite slow, and an editor wouldn’t take much advantage of its benefits IMO

chrisoakman00:02:14

you think it would be too slow for editing tasks?

cfleming00:02:50

Well, I’m not sure - Erlang’s huge benefit is in parallelisation and robustness.

cfleming00:02:15

I suspect that in an editor, it’s very difficult to parallelise many of the tasks.

chrisoakman00:02:35

that's the crux of the problem; I wonder how possible that would be

cfleming00:02:20

It’s hard. It might be easier for something like Clojure, where each top-level form is essentially independent.

cfleming00:02:42

But the problem is always when your code is invalid, which is pretty much the standard state of things while editing.

chrisoakman00:02:45

this might be an architectural dead-end; just something I've been thinking about the last year or so

cfleming00:02:52

I think that you’d find you might be able to achieve parallelisation, but making it performant would be very hard since many of the tasks are intrinsically serial.

cfleming00:02:18

Using Erlang or Pony or something like that, you might be able to use an actor per line, or something.

cfleming00:02:49

But you still have the problem that your syntax highlighter for each line needs the state at the end of the previous line to do its thing.

cfleming00:02:41

Lunch: back in a bit

chrisoakman00:02:08

man - text editing is such a tricky problem

chrisoakman00:02:17

very involved; lots of moving pieces

cfleming00:02:49

Cursive already does something simplistic like this, and has the opportunity to do much more. Currently I highlight symbols from clojure.core differently.

cfleming00:02:11

But I could relatively easily highlight local vars differently, or macros - I have an issue about that somewhere.

chrisoakman00:02:57

yeah - one thing that essay / idea doesn't take into account is function scope

chrisoakman00:02:09

it assumes that if you have a symbol, it should be the same color in any scope

cfleming00:02:10

The linked KDE article talks about that.

chrisoakman00:02:13

which may be what you want, and may be what you don't

chrisoakman00:02:28

ok; I need to give that a deep read

chrisoakman00:02:32

I also just skimmed it

cfleming00:02:46

Each local var within a particular scope has an individual colour.

chrisoakman00:02:10

so the editor has to have some knowledge of the underlying program then

chrisoakman00:02:15

in order to do that

cfleming00:02:34

Right, and in Cursive I have a ton of semantic knowledge I can use.

cfleming00:02:00

I’m also going to use that soon for intelligent autocomplete, so autocomplete in different contexts shows different things.

cfleming00:02:04

Anyway: lunch, and then I need to actually do some work simple_smile

snoe00:02:34

@chrisoakman you need might be interested in looking at https://github.com/oakes/SolidOak one of the goals of neovim was to allow a GUI to embed and pass messages from the ui thread.

chrisoakman00:02:21

I saw SolidOak when it first came out, but didn't dive too deeply

cfleming03:02:37

@chrisoakman: Your original JVM port was based on 1.5.3, right?

cfleming03:02:28

I’m working on updating master to 1.6.1, but some of the new test cases fail.

cfleming03:02:28

So something I don’t understand. I’m looking at the paren-mode test for (foo. The tests for it all pass, except for the cross-mode preservation test, which returns (foo). But surely that is correct for indent mode?

cfleming03:02:20

Similarly for:

(defn foo
  [arg
  bar)

cfleming03:02:58

Parinfer-JVM is returning:

(defn foo
  [arg]
  bar)
For the cross mode preservation, which looks right to me.

shaunlebron03:02:29

hi @cfleming, looking at it now

shaunlebron03:02:16

I added test cases for errors

shaunlebron03:02:34

(foo in paren mode returns an unclosed-paren error

cfleming03:02:52

Oh, so if the error doesn’t match, Mocha doesn’t continue the test case?

shaunlebron03:02:56

so idempotent tests should only be run against successful results

cfleming03:02:17

That’s different from clojure.test, then, which is the problem.

shaunlebron03:02:37

well, it’s not Mocha’s choice right

shaunlebron03:02:58

the end of the code block I linked will return from the test case early if the result has an error

cfleming03:02:19

You’re absolutely right, my bad.

cfleming03:02:22

I’m also having problems with some of the paren mode tests, which are modifying indentation in the idempotency tests.

cfleming03:02:11

I don’t understand why paren mode modifies:

(let [foo 1
           bar 2
           baz 3])
to
(let [foo 1
       bar 2
       baz 3])

shaunlebron03:02:24

that’s new too

shaunlebron03:02:30

uses cursorDx

shaunlebron03:02:44

there are three stages here

cfleming03:02:48

Ohhh, these tests may not take that into account.

cfleming03:02:02

I’ll have to update the test harness a bit.

cfleming03:02:25

Got it, thanks.

shaunlebron03:02:27

if there is a cursorDx, it’s no longer an idempotent operation

cfleming03:02:38

Right, that makes sense.

cfleming03:02:05

Totally unrelated, Stripe Atlas is amazing.

shaunlebron03:02:38

day one at stripe, patrick explained that to us, four weeks ago

cfleming03:02:42

That totally came out of left field.

cfleming03:02:08

Haha, it’s hard not to talk about some of the things you hear about at companies like that.

cfleming03:02:12

Google was the same.

shaunlebron03:02:45

yeah for sure

shaunlebron03:02:58

it was just really cool that owners of the company talked to all the new recruits about the values of the company, and then they brought atlas as a case for how they direct their products with those values

shaunlebron03:02:21

that was a word soup lol

shaunlebron03:02:36

anyway, fun company, I like patrick

shaunlebron03:02:45

all companies have their list of values, but patrick goes out of his way to communicate to us how each product represents those values

cfleming03:02:59

Yeah, pretty amazing guys. It’s a little worrying that John is literally young enough to be my son.

shaunlebron03:02:21

you mean inspiring

shaunlebron03:02:26

yeah, they’re 25?

shaunlebron03:02:44

richard branson said the same of elon

cfleming03:02:17

It’s great when companies have good values, articulate them clearly and then explain how what they’re doing follows them.

cfleming03:02:23

It’s distressingly rare.

shaunlebron03:02:05

i think respect, integrity, etc… were official enron values

sekao23:02:10

@chrisoakman do you have plans to return the cursor position for parinfer-jvm? I'm adding it to nightcode and wondering if I should find the new position manually when enter is hit

cfleming23:02:39

@sekao: I have that change made, but I haven’t committed it yet. I’ll do it today.

chrisoakman23:02:34

did you get those cljs stickers?

chrisoakman23:02:27

@cfleming: this is keeping up with the latest from parinfer.js?

chrisoakman23:02:47

I need to port those changes to parinfer.py and update the Sublime plugin

cfleming23:02:50

It’s basically in line with 1.6.1, and the tests updated

chrisoakman23:02:04

I've been working on a different project the last week or so

cfleming23:02:18

Sure, no worries.

cfleming23:02:47

I’ve been investigating different parinfer approaches for most of the week.

cfleming23:02:11

I’m going to try to polish up the integration into IntelliJ today.

chrisoakman23:02:31

yeah - that Github thread keeps getting pinged by people who want Parinfer 😉

cfleming23:02:18

Yeah, no doubt - I’ll go with what I have now for the first release, in the interest of just getting something out there.

cfleming23:02:59

BTW are you still highlighting the inferred parens differently? I can’t see any difference in Atom.

chrisoakman23:02:15

it's tricky; requires making changes to Atom's clojure language package

chrisoakman23:02:40

Shaun has been working on it this week actually; there's a PR where it works: https://github.com/oakmac/atom-parinfer/pull/50

chrisoakman23:02:04

but I'd rather pull those grammars changes into the main language package than distribute a custom one with the parinfer extension

chrisoakman23:02:23

but either way, it's close to getting there

cfleming23:02:14

Ok cool, thanks.

cfleming23:02:30

Fortunately I bundle everything together so I can do this.

chrisoakman23:02:37

Yeah - the atom package for the clojure language is pretty slim. There are essentially no tests for it: https://github.com/atom/language-clojure/issues/38

chrisoakman23:02:03

seems like they just copied it over from TextMate and then called it good

chrisoakman23:02:16

I suspect most of the core Atom developers aren't using Clojure on a regular basis