Fork me on GitHub

🔥 probably the most promising idea for Locus was just posted by @ivanreese here


you’ll have to read the discussion that follows for full context


looking forward to trying it out


(Locus is what I alluded to in my talk to help reading lisp, to complement how Parinfer helps writing lisp)


@shaunlebron — It didn't occur to me to come by Slack until just now. I'm here if you feel like hashing things out in a more verbose form, hah.


I'm apparently rate limited on Twitter...


I couldn't view the tweet until late morning. It was odd.


@shaunlebron You mentioned the other day that you saw bad performance with parinfer in the CLJS project in Cursive. I’m looking at it now and I’m not seeing that.


Were you doing anything specific? What were the performance issues you saw?


@shaunlebron Ok, thanks. I think that’s just an artifact of the fact that the highlighting is asychronous.


I don’t think I can do much with that, unfortunately.


not sure if you could see, so let me clarify


i hit backspace on the red area to correct the indentation


and there was a ~1 second delay before it took effect


Right, but I think that’s because the highlighting tasks are run asynchronously. That highlighting isn’t driven directly by changes in the editor. When the doc changes, IntelliJ then re-highlights the whole file, and the highlighting pass which adds those markers is run again, checks indentation over the whole file and adds markers where needed.


For such a big file, that can take a while.


you have an idea why you’re not seeing the same behavior on yours?


It’s unfortunate, but trying to do it incrementally as the user is editing would be really complicated. I might be able to raise the priority of the highlighting task, I’m not sure.


Let me check again. It may just be that I’m seeing what I expect, and you’re not seeing what you expect 🙂


IntelliJ users are generally used to the highlighting not being immediate.


but it’s not highlighting that’s slow


i’m probably still misunderstanding


You’re talking about the red markers being taken away when the indentation is corrected, right?


I hit backspace here:

it takes ~1 second before I see:


So you’re talking about a delay for the actual text to be updated?


i hit backspace, and it took a long time for it to take effect


Ok, then I don’t see that. I do see a delay for the marker to be removed, but the text moves immediately.


Ok, one sec


Yeah, I see that in that case, however it’s not parinfer-related, I also see that when parinfer is disabled.


It seems to be specific to the thing you did. So you hit backspace at the start of a line, and what IntelliJ does in that case is tries to be clever, and deletes the whitespace at the start of that line and puts the caret at the end of the previous line. I think that requires it to calculate formatting information, and I just think that’s slow on a file this big.


So if I type on that line, or just delete some normal whitespace that doesn’t require any formatting info, it’s fast.


so you can reproduce?


cool, same page now then


But I won’t investigate that as part of this change, since it’s not related to parinfer.


I suspect my formatting model creation code could be faster (I need to switch to transducers rather than seqs), which would probably help that. Not having 11k line files would probably also help.


Re: the other feedback, as we discussed F2 is standard in IntelliJ and does find those markers. One issue with that though is that the markers are set to have warning level. The way that F2 works is it finds things in order of priority - if you have error level markers then it’ll only cycle through those, then all the warnings etc.


So in that file, it takes a while to find the indentation issues because they get buried in all the unused symbols etc.


Similarly with the gutter markers - the indentation ones do appear there, but not in red since that’s the colour for error level markers. They’re there in yellow, but they get drowned out by all the other crap in that file.


Again, because the file is enormous, all the warning markers in the file get compressed into the single gutter space. It’s not ideal in this case, but I can’t change it easily.


I don’t want to give those markers higher priority, because they’re not actually errors. If people start reporting this as an issue, I’ll think about a specific “Jump to indentation problem” action.


Hopefully finding them also won’t be an issue if I only run over affected top-level forms, since you’ll only have to correct indentation where you’re actually working anyway.