Clojurians Log v2

@shaunlebron What is the best place to point people to when they ask what smart mode is?

The home page is still mostly about the dual modes.

Is there a summary documented anywhere public?

i was just about to record a quick video summary

but I wanted to demonstrate it in cursive

That would be great, a few people have asked about it.

but it doesn’t work here yet

In Cursive?

@cfleming: https://www.youtube.com/watch?v=QGzilYhqsPc

i probably just got the wrong version? intellij versions are confusing

That’s weird, it sounds like what @dave.dixon was reporting.

Versions look good, Cursive wouldn’t be enabled otherwise.

I think I’m seeing the same behavior, seemed like it was working for a while then ☝️

I’m going to try with the repo that Dave said was failing for him

hmm, i’ll try a new clojure project then

@taylor So it was working for you, then it started failing on the same code, or you opened some new code and it didn’t work there?

I was editing a large CLJS file and it was definitely (maybe?) working when I started, but then eventually it ran into some issues with unmatched parens/brackets that I had to manually fix, and after that it seemed to have stopped working?

Hmm, I wonder if the problem is that it’s not re-enabling after things break

ok so if I open said file, it doesn’t work. If I work on a new/trivial file, it works

@shaunlebron Does it work if you’re editing the main code of that project rather than a test file?

that was what I first tried

@taylor Could you restart IntelliJ and see if it starts working on that same file?

I tried it in a new clojure project generated by intellij, and it worked in the core.clj file

I just restarted before testing @cfleming

Hmm

then I pasted a long clojurescript file into a new cljs namespace in the project, and it didn’t work

oddly, it doesn’t seem to work on any CLJS files in my project at all now, not even a new blank one

it works for CLJ files in same project

I wonder if CLJS is the problem for some reason, I’ll see if I can reproduce that.

I only really work on CLJ.

should we move this to #cursive?

Probably, yeah.

@cfleming can you review this 60 second video before I tweet it? https://www.youtube.com/watch?v=sl6d9M8jkvU

or anyone awake in this channel wanna look at it?

@shaunlebron Looks good to me!

cool, thanks for checking

wanted to make sure i wasn’t leaving anything out important

@cfleming: looks good in cursive

only thing I found missing was the last part of the video—selecting a line to correct indentation in isolation

@cfleming: this is the line that just turns off smart mode when any line is selected: https://github.com/shaunlebron/parinfer/blob/3.12.0/lib/parinfer.js#L1543

@shaunlebron Ok, I’ll check that.

Cursive doesn’t currently do that, you’re right.

@doglooksgood i was thinking about the performance problem with your elisp port

180ms for 2k lines doesn’t sound too bad if we just process top-level forms only

atom-parinfer still doesn’t process the whole file, despite it being able to

it just assumes that lines starting with ( are top-level forms

could be a quick workaround for now

It currently does like this. so in the most cases, it's okay. but in a project.clj it may cause problem.

I'm wondering the dynamic module feature of emacs, that allow it load .so or .dll. If port parinfer.js to C, the performance should be good enough.

I believe that, parinfer should also work for XML or HTML

ha, I don’t see how that would work. thoughts?

I think they are same.

for XML and HTML, the close tag can be inferred by the indentation and open tag.

no theory to prove this.

I saw people who write JSX are painful for the close things. especially when they in some scopes like

xxxlist.map(x -> {
  <div>
    <h1>{x}</h1>
  </div>
})

maybe if html was written this way:

<div>
    <h1>{x}</h1></div>

no, they won't:joy:

haha, right

I’m just saying if we want to extend parinfer to other syntaxes, the closing tags have to be consistently placed (according to my current understanding)

maybe not though, i can already look at that and see how the closing tags can be correctly placed based on indentation, according to how people want it

yeah, maybe you’re on to something

I just think the close tag in xml can be inferred, no saying that parinfer should extended to do this stuff. but if we can determine where we put the closers, for most of the languages, this is the only difference I think.

the truth is , for most of the language, the indentation and the code block is relevant.

hmm

we can mock out this idea by replacing <div> => ( and </div> => )

assume divs for all tags

so now:

<div>
  <h1>{x}

(
  ({x}

(
  ({x})
)

<div>
  <h1>{x}</h1>
</div>

that would be a fun experiment 🙂

@doglooksgood cool idea, good insight

{x} is just like the string in lisp

right

it could be anything, I didn’t mean its brackets would be inferred

the code inside {} can have jsx tag too, so should wait { closed first. it's bit complex than lisp maybe

haha, we should probably just do HTML first

i wonder if it could work for JS too

it wouldn’t need anything from Smart Mode to work

1. determine where we put closer. 2. custom the opener and closer type. with these two enhancement, I think it will work for html at least.

to clarify why JS wouldn’t need Smart Mode stuff, replacing if with for below wouldn’t require the body to shift, since the body is always fixed indentation regardless of the position of the curly:

if (true) {
  foo()
}

yeah, i think you’re right, that could be pretty simple to make work for html

parinfer-html could be a pretty quick project 🙂

the smart-parens in emacs has these kind of work, it handle whatever thing you call them parens, not limited in normal parens.

cool

If parinfer work both in JS and HTML, it will help JSX a lot

I always think, write JSX is a pain.

JSX is nicer than HTML in terms of closing tag consistency

<input> vs <input /> and <div></div> vs <div />

yes, it is

honestly, I don’t struggle with writing JSX

easy to align the tags vertically, people like that. it’s just a bit verbose

but I struggle and a lot of my workmates struggled. I don't have to write JSX, we prefer clojurescript.

because it’s too much to type? or the fact that it doesn’t compose well with JS?

the JS interpolation is very awkward

I think the reason why I don't like it, I have to move the cursor here and there, you have to edit both begin and end, just like edit lisp without parinfer or paredit.

especially when you do wrap and raise from

<div>
  x
</div>

<div>
  <span>x</span>
</div>

ah okay, so it’s just the tag manipulation that you don’t like

another thing, i think why my parser in elisp is slow is that I try to save parse result in a vector

I should combine parsing and processing. for now, if I save result, parsing will cost 140ms, If I don't, will cost 50ms.

I think 50ms is good enough