Dealing with different paren types separately

[samaaron]

So, I merged your pull request into the live-coding config, and then went about getting it working with my personal emacs config and I totally love the speed, but one thing that I do have an issue with is that nested parens of different sorts are now mixed.

Before, the colouring of my parens would be determined by the depth of that particular type of paren whereas now the colour is determined regardless of paren type.

( ( <- here I expect the second ( to be my 2nd paren colour for ( parens

( { <- here I expect the first { to be the the 1st paren colour for { parens

Previously I had one colour sequence for ( parens and a separate colour sequence for { [ parens (this is because i was using rainbow-parens for ( and rainbow-delimiters for [ and {

I really liked this behaviour:

• colours only affected by nesting of a particular paren type within similar parens of the same time
• separate colour sequence for each paren type

Is this something that might be possible in a future update? Otherwise I might be tempted to revert back to the old, (slow) version which I'm very comfortable with.

[jlr]

On Tue, Jan 10, 2012 at 1:24 PM, Sam Aaron <
reply@reply.github.com

wrote:

So, I merged your pull request into the live-coding config, and then went
about getting it working with my personal emacs config and I totally love
the speed, but one thing that I do have an issue with is that nested parens
of different sorts are now mixed.

Oops! Yep, this is something I haven't redone yet. I actually have most of
that already done in a branch somewhere. So far there's just checkboxes to
enable/disable highlighting of each type of delimiter - not what you want.

To be honest I'm surprised - at first I thought using separate delimiter
colors would be great in Clojure, but when I actually tried it, I found it
very chaotic and confusing. That's why I removed it. I've found that when I
have a map or a vector at the same level as other arguments and sexps, I
expect it to be the same color if it's at the same level. The only place I
might want that to be different is function signatures. How did it work for
you? In the overtone video brackets are all white, so I don't see how your
personal color theme looked.

I do plan on adding that behaviour in again (it's on the todo) especially
for C hackers, but I'm quite curious to learn how independent depth
tracking worked for a Clojure hacker.

Glad you pulled in the mode. I think I'll add independent delimiter colors
next, since it's easier than html tag support (which needs a parser) and
you're the second person who'se asked for it. I'll send a pull request to
live-coding-emacs when it's done.

Thanks,

• Jeremy Rayman
  jeremy.rayman@gmail.com

Before, the colouring of my parens would be determined by the depth of
that particular type of paren whereas now the colour is determined
regardless of paren type.

( ( <- here I expect the second ( to be my 2nd paren colour for ( parens

( { <- here I expect the first { to be the the 1st paren colour for {
parens

Previously I had one colour sequence for ( parens and a separate colour
sequence for { [ parens (this is because i was using rainbow-parens for (
and rainbow-delimiters for [ and {

I really liked this behaviour:

• colours only affected by nesting of a particular paren type within
  similar parens of the same time
• separate colour sequence for each paren type

Is this something that might be possible in a future update? Otherwise I
might be tempted to revert back to the old, (slow) version which I'm very
comfortable with.

---

Reply to this email directly or view it on GitHub:
#6

[milanmitrovic]

I'm using the mode in C++ and there I have a similar problem.

I don't want to color {} as they are quite easy to spot with the indenting scheme, but even if I turn coloring off they still affect the nesting depth of my other delimiters. I found this super-confusing. Do you plan to fix this?

[Fanael]

Development has moved to https://github.com/Fanael/rainbow-delimiters. If the issue still persists, please report it there.