This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-25
Channels
- # aatree (10)
- # beginners (59)
- # boot (314)
- # braveandtrue (4)
- # cider (50)
- # cljs-dev (12)
- # cljsrn (6)
- # clojure (206)
- # clojure-austin (2)
- # clojure-gamedev (90)
- # clojure-japan (1)
- # clojure-poland (12)
- # clojure-russia (10)
- # clojure-sg (1)
- # clojurescript (86)
- # core-async (2)
- # core-matrix (3)
- # cursive (40)
- # datomic (2)
- # dirac (13)
- # editors (25)
- # emacs (7)
- # hoplon (2)
- # immutant (10)
- # jobs (24)
- # jobs-discuss (1)
- # ldnclj (8)
- # lein-figwheel (19)
- # leiningen (1)
- # mount (7)
- # off-topic (34)
- # om (147)
- # onyx (11)
- # parinfer (151)
- # pedestal (2)
- # re-frame (31)
- # reagent (13)
- # ring-swagger (7)
- # spacemacs (1)
- # yada (11)
yeah; I would think that would be close to impossible unless you had it implemented
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.
my general sense would be to try that first and then see if it's fast enough
sounds like IntelliJ is quite different than these other editors though
It’s actually amazingly sophisticated - people complain about the performance but don’t realise what it’s doing behind the scenes.
And with the new zero-latency stuff it’s more responsive for typing than everything but gvim.
I'm amazed that people were ever willing to use an editor that had any typing latency 😉
that seems like such a fundamental UX violation for a text editor
I suppose the criteria is "below a noticeable threshold"
That could be their new tagline: Atom - the performance of an IDE with the functionality of a text editor!
I'm a fast typer, but I don't think I would ever notice a difference between 10 and 20ms
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.
I skimmed it; need to go back and give it a full read
one of these days I'm going to write an editor in a language that deals with concurrency properly
like Erlang or Pony
this is on my todo list once I have infinite time and infinite money
IntelliJ has really good concurrency support, but editor modifications are still serialised.
I've given this some thought; haven't implemented anything to test it out yet
but my thinking would be to completely separate these logically different parts of the system
so the UI never has latency and only communicates through message passing
I like the idea that "the syntax highlighting can crash" and have zero effect on the rest of the system
so could any plugin
hot-code swapping, live-updates, etc
like a true Erlang OTP system
I was reading the Pony docs last night 😉
the UI-portion would be pretty complex
Erlang has some support for wxWidgets, but I would love to not build the UI in wxWidgets...
In general, Erlang is actually quite slow, and an editor wouldn’t take much advantage of its benefits IMO
you think it would be too slow for editing tasks?
that's the crux of the problem; I wonder how possible that would be
It’s hard. It might be easier for something like Clojure, where each top-level form is essentially independent.
But the problem is always when your code is invalid, which is pretty much the standard state of things while editing.
this might be an architectural dead-end; just something I've been thinking about the last year or so
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.
Using Erlang or Pony or something like that, you might be able to use an actor per line, or something.
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.
I wanted to give this a try: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e#.d1in32l59
man - text editing is such a tricky problem
very involved; lots of moving pieces
Cursive already does something simplistic like this, and has the opportunity to do much more. Currently I highlight symbols from clojure.core differently.
But I could relatively easily highlight local vars differently, or macros - I have an issue about that somewhere.
yeah - one thing that essay / idea doesn't take into account is function scope
it assumes that if you have a symbol, it should be the same color in any scope
which may be what you want, and may be what you don't
ok; I need to give that a deep read
I also just skimmed it
so the editor has to have some knowledge of the underlying program then
in order to do that
I’m also going to use that soon for intelligent autocomplete, so autocomplete in different contexts shows different things.
later
@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.
I saw SolidOak when it first came out, but didn't dive too deeply
@chrisoakman: Your original JVM port was based on 1.5.3, right?
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?
Parinfer-JVM is returning:
(defn foo
[arg]
bar)
For the cross mode preservation, which looks right to me.hi @cfleming, looking at it now
I added test cases for errors
(foo
in paren mode returns an unclosed-paren
error
so idempotent tests should only be run against successful results
right: https://github.com/shaunlebron/parinfer/blob/master/lib/test/cases.js#L38-L44
well, it’s not Mocha’s choice right
the end of the code block I linked will return
from the test case early if the result has an error
I’m also having problems with some of the paren mode tests, which are modifying indentation in the idempotency tests.
I don’t understand why paren mode modifies:
(let [foo 1
bar 2
baz 3])
to
(let [foo 1
bar 2
baz 3])
that’s new too
uses cursorDx
there are three stages here
if there is a cursorDx, it’s no longer an idempotent operation
day one at stripe, patrick explained that to us, four weeks ago
blown away
Haha, it’s hard not to talk about some of the things you hear about at companies like that.
yeah for sure
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
that was a word soup lol
anyway, fun company, I like patrick
all companies have their list of values, but patrick goes out of his way to communicate to us how each product represents those values
Yeah, pretty amazing guys. It’s a little worrying that John is literally young enough to be my son.
you mean inspiring
yeah, they’re 25?
richard branson said the same of elon
It’s great when companies have good values, articulate them clearly and then explain how what they’re doing follows them.
i think respect, integrity, etc… were official enron values
@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
Hi Zach
did you get those stickers?
@cfleming: this is keeping up with the latest from parinfer.js?
right
I need to port those changes to parinfer.py and update the Sublime plugin
I've been working on a different project the last week or so
yeah - that Github thread keeps getting pinged by people who want Parinfer 😉
Yeah, no doubt - I’ll go with what I have now for the first release, in the interest of just getting something out there.
BTW are you still highlighting the inferred parens differently? I can’t see any difference in Atom.
We're working on it: https://github.com/oakmac/atom-parinfer/issues/26
it's tricky; requires making changes to Atom's clojure language package
Shaun has been working on it this week actually; there's a PR where it works: https://github.com/oakmac/atom-parinfer/pull/50
but I'd rather pull those grammars changes into the main language package than distribute a custom one with the parinfer extension
but either way, it's close to getting there
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
seems like they just copied it over from TextMate and then called it good
I suspect most of the core Atom developers aren't using Clojure on a regular basis