I’m looking for a plugin that highlights all pairs ({}()[]""'' etc.) with each pair having a different color.
This highlighting could be done on demand, (for example when I’m looking for that one unclosed parenthesis).
I’m not sure if there is already a plugin for this, if not, I might attempt writing one.
I believe Kakoune handles this usecase by using power of m, <a-i>, and <a-a>, and with plugins like kak-tree you can have selections based on context information from standalone parser (treesitter).
That’s how I currently find missing parens (if I don’t have a linter that shows it), I use m on every opening paren, until I find one without matching closing paren, but I don’t see how I can do this faster (i.e. with one command).
If you have a suggestion, let me know.
Anyway, I think a rainbow-like plugin would make this easier, as a missing paren is more obvious due to the imbalance in colors.
You can accomplish this by setting the rainbow_faces to faces that highlight the background. And setting the rainbow_highlight_background option to true.
I’ve tested it on my emacs init.el (1354 LOC, 2456 parens in total) and it is pretty slow as of now. Maybe it should run in background?
Although I appreciate that you’ve added ability to color a background, and it is a nice feature, this is not really the same. It’s hard to understand it from static image (and I should have explained that better), but the highlighting on that screenshot is actually dynamic. It adds more and more colors depending on how deep your cursor is inside the syntax tree. So it is more like a dynamic indentation guides for Lisp.
Nice and very useful yet. The one annoyance I see is that it mess with my / registry.
I guess that -draft on a recursive eval won’t work, that’s why you did not add one. We need some kind of -recursive-draft option on eval. The context would be created and destroyed only on the first evaluation of the given evaluate-commands in the stack. I’m not even sure that the concept of stack exists in kak scripts . @mawww could tell.
I think recursive draft does work, I did not add a draft context there since it should not be needed because that function should only be called from the rainbow function, which calls it inside a draft context.
Edit: I pushed a fix to save the ‘/’ register, I thought this was saved automatically (like for execute-keys) but according to the docs this is not the case.
I made a similar plugin with a different approach:
The iterating over the selections is done in an external GNU Guile script, that forms the range-specs. Instead of highlighting the whole buffer, it only highlights the brackets in the current view. On my laptop is almost instant, but not “instant enough” to use it in a NormalIdle hook.
If new open bracket appears in the view, do color of all other brackets shift? I mean, that perhaps script starts coloring from specific clolor, say red, and then orange, yellow, etc.
( ( (
↑red ↑orange ↑yellow
We add one in front, or because of scrolling it appears in the veiw
↓new
( ( ( (
↑red ↑orange ↑yellow
Will it shift colors to the left, or it will be colored with right color bound or another color?
Thank you @andreyorst for this info, while I haven’t caught up with the conversation yet, with the lead on Paredit - I have come across this great wiki which Emacs users may have already seen Smartparens really well structured wiki on the topic.
In your example the new one will be red and all the following brackets change the color in order. The plugin analyzes all the brackets before the current view to get the right level. That’s why it is not instant. But the actual highlighting is done only for the last 500 brackets, so that the current view and some lines above and below that will be colorized. That way we we gain a lot of speed. I tried it on a 20,000 lines scm file, where the highlighting in every position of the file is done in less than a second.
I made yet another rainbow highlighter, but one that moves the colors around depending on cursor position. Still not exactly what @andreyorst was looking for, but it is fast enough to use in a NormalIdle hook, at least for me.