This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-22
Channels
- # beginners (24)
- # boot (80)
- # braid-chat (11)
- # cider (89)
- # clara (11)
- # cljsfiddle (5)
- # cljsjs (9)
- # cljsrn (63)
- # clojure (114)
- # clojure-austin (1)
- # clojure-berlin (5)
- # clojure-brasil (4)
- # clojure-dusseldorf (5)
- # clojure-hamburg (17)
- # clojure-india (1)
- # clojure-new-zealand (3)
- # clojure-poland (1)
- # clojure-russia (91)
- # clojure-taiwan (1)
- # clojure-uk (54)
- # clojurebridge (3)
- # clojurescript (170)
- # core-matrix (1)
- # cursive (14)
- # datomic (8)
- # emacs (13)
- # hoplon (96)
- # immutant (20)
- # jobs (9)
- # jobs-rus (13)
- # kosmos (3)
- # off-topic (8)
- # om (111)
- # onyx (41)
- # parinfer (116)
- # pedestal (2)
- # proton (4)
- # re-frame (46)
- # reagent (7)
- # ring-swagger (24)
- # slack-help (2)
- # testing (1)
- # untangled (8)
hey cfleming, congrats on the release , haven’t had a chance to try it out yet sorry
what you described is by design
I played with it for a week in the demo editor when I posted it here before releasing that
i played with allowing the cursor to move right, but it was inserting a lot of spaces
@shaunlebron: Thanks! There’s a bunch of teething issues but nothing serious. I’m hoping to get another release out tomorrow to fix them.
err, you could press right indefinitely
so I thought it might be apparent to just press spacebar
|)
after pressing right 5 times => |)
parinfer can be jarring
its rules can lead to surprises, either pleasant or confusing
how I can keep track of feedback from cursive users?
just on github?
Yeah, there’s been some discussion on the issue tracker, and some on the mailing list too: https://cursive-ide.com/archive/1882.html
There are a few issues in the tracker too, I’m working through them now for the next release.
work never ends!
this cursive mailing list design looks good btw
I’m planning to improve it, currently it’s based on the text version of the emails but I’m going to use mailgun’s API to get the stripped HTML version.
I’m also going to replace the search with a Google custom search - DDG just doesn’t work that well.
ah, bummer
just as they would have it
i’m gonna be following this mailing list then, try to answer some questions regarding parinfer core
how frequent is the digest version?
But it’s pretty low traffic in general - yesterday and today there have been some mails due to the release, but generally it’s a couple of mails a week.
I’m actually considering an auto-indent mode for Cursive for when parinfer and paredit are both off, and also for paredit.
I’m not sure if I should try to just make my paren mode indent correctly using Cursive’s semantic knowledge, or just have a lighter-weight thing that works ok but needs occasional full formats.
auto-indent mode?
I think people would like that
his parinfer-notes repo?
Based on comments, I’m getting the feeling that parinfer isn’t as intuitive for new users as I’d hoped. I’ll be very interested to hear @sekao’s comments after he runs his class.
yeah, I’m starting to think that paren mode is more intuitive
I thought about it a lot this weekend
I think auto-formatting of indentation makes sense
but there is a subtle difference between aggressive indent and paren mode
aggressive indent enforces exact indentation, and paren mode just constrains to thresholds and preserves chosen indentation when expressions shift
aggressive indentation would drive david nolen crazy for example
he uses two-space indentation for everything
today was the first day of clojure in my class, but i always spend the first day entirely in the REPL. technically i am running parinfer in nightcode’s REPL but i won’t be able to reach conclusions until we start working in a file tomorrow
I’m actually thinking about just trying to maintain indentation in the current form when typing, which will work up to a point, and then having a “format top level form” which will clean the whole form up correctly.
regarding the intuitiveness of paren vs indent mode, the reason i’m on the indent mode bandwagon is because i think manually managing indentation comes more naturally than manually managing parens and other delimiters.
when teaching Java, i never have to teach people how to indent properly when the scope changes — they just get it. but when it comes to delimiters, they often would accidentally forget to copy a closing brace when moving code around.
indentation is very visually apparent, while delimiters are subtle and easy to overlook
the problem is that Lisp is cubist, if that makes sense
you’re essentially shown two different perspectives, and you’re forced to reconcile one when the other changes
indentation is intuitive when you see it on its own, but parens create a kind of noise around it that creates hesitation I think
this is exacerbated by the fact that a multi-line expression can start in the middle of a line
that’s not a problem in python, but since it’s possible in lisp, it creates fragile indentation points
fragile in the sense that changing text before the expression can necessitate reindenting of several lines
i wonder if that hesitation comes from those who have already edited lisp using traditional modes and are experiencing something contrary to their expectations. my students haven’t edited any lisp at all, so i’m curious if they will just learn to “trust the indentation”
the latter point is certainly true. hopefully they will be able to manually re-indent in that situation
i have not had an environment for user-testing, so I’m really looking forward to hearing about reactions from new users
it’s not just manually reindenting that is the problem
the most troubling thing about indent mode since the quote bug is the unmatched close paren behavior
insert [
at (foo|) bar
=> (foo [ bar])
parinfer indiscriminately removes unmatched close-parens, which is the problem there. but I’m revisiting that right now
uncovered more examples: https://github.com/shaunlebron/parinfer/issues/102
I think I’m gonna have to delete the “Paredit emerges" section on the website
i feel like andrew wiles after someone found a mistake in his theorem… gonna have to backpedal a bit
@shaunlebron: This is also not behaving as I expected:
In the Cursive implementation, that originally had another closing paren - paren mode removed it.
Actually, I lie - this happens in the reference impl too. It’s not paren mode that removes it, it’s indent mode.
Copy that text with an extra close paren, and put it in the reference impl in paren mode.
PANIC MODE
(me right now)
Ah that might explain my regex of #"//"
getting rewritten to #"\/\/"
it happens rarely enough that I haven't been able to track down the source... Maybe not
I've personally gone to an aggressive indent style of wrangling code. I think that lisp will always require thinking in trees in some capacity, yet indent mode becomes an imperfect proxy for that thinking. Aggressive indent makes the structure more apparent through indentation but structure is directly determined and executed by the parens.
As far as paren mode vs aggressive; we use the emacs standard indentation, so if I'm writing code and the indentation of my form doesn't match the code around it, I have more trouble reading it. I'm constantly reindenting to match code style and confirming that the shape I built matches the shape in my head/shapes around it.
I think it would be hard (and wrong) to force a team all to use the same editor and plugins so some sort of style and indent rules need to exist to write code in a team.
@sekao: "hesitation comes from those who have already edited lisp using traditional modes and are experiencing something contrary to their expectations" --> I agree with this so much
Has this been posted to the channel yet? https://github.com/noctuid/parinfer-notes
So much in there that I disagree with; I might have to write a commentary on it. I suspect that's the same guy who posts in every reddit thread about Parinfer about how it's so inferior to Emacs + plugins.
Meanwhile, beginners believe that Parinfer is "pure magic": https://twitter.com/SoftwareWarlock/status/710895116232364036
People have stockholm syndrome with their tools
@shaunlebron: if it makes you feel better, today’s class was a big success. my last class was pandemonium by day 2 of clojure, when i was using unassisted and paredit mode with my students. after every line i had to fix unbalanced parens or remind them how to splice with paredit.
today i just told them to forget about the parens and focus on indentation. there were only two times the whole lecture that a student had a bug related to misplaced parens, and i was able to show both of them that they could fix it by simply fixing the indentation. the rest of the issues were just stupid nightcode bugs 😃
i’ll keep updating you as we go along of course. i’m doing two weeks of clojure so there will be plenty of time to observe how it goes
that is huge feedback @sekao
thanks for the real-world report
@chrisoakman: I think he makes some valid points. This is pretty crazy, for example: https://raw.githubusercontent.com/noctuid/parinfer-notes/master/parinfer_demos/parinfer-downsides-3.gif
I agree with him that the understanding of how parinfer works required in order to use it accurately is greater than I hoped.
I haven’t used it enough to be sure, but I’m starting to feel like some sort of auto-indent like paren mode might be the solution.
And I definitely agree that I think there’s some kind of hybrid mode in there somewhere, but I’m not clear what it looks like. I don’t think that switching modes is ideal.
@cfleming: the few downsides and edge cases of parinfer have so far not bothered me because the alternatives have downsides too. nothing is perfect. with no structured mode, you get unbalanced parens, and with paredit mode, you get bewilderment. those problems don’t show up easily in a cute gif but are painful for beginners nonetheless