Re:Making bracket pair colorization faster
by AaronFriel on Wednesday September 29, 2021 @05:57PM
(#28700519)
Using the "Custom CSS" extension you can do this. It looks like the bracket colorization is applied via CSS styles, via classes:
bracket-highlighting-1 ... bracket-highlighting-6
unexpected-closing-bracket
Re:Making bracket pair colorization faster
by rory on Wednesday September 29, 2021 @11:56AM
(#28695450)
The challenge here would be that nesting levels can be added inside or outside the previous level, so to prevent reflow, bracket size would be dependent on order of addition and could vary wildly between different "nests".
Re:Making bracket pair colorization faster
by snovv_crash on Wednesday September 29, 2021 @01:30PM
(#28697036)
You could just adjust the height, not width of the bracket. There is usually plenty of space between lines to support this.
Re:Making bracket pair colorization faster
by cscharenberg on Wednesday September 29, 2021 @03:31PM
(#28698698)
I have a strong memory of using an IDE that behaved like this - using size and font to communicate structure - at a job around 2005. I can't currently remember the name but think it it started with 'source'?
If someone else remembers this and the name I'd appreciate it. I could be remembering wrong too about how far it went with such decoration.
Re:Making bracket pair colorization faster
by pacaro on Wednesday September 29, 2021 @09:40PM
(#28702280)
SourceInsight
Re:Making bracket pair colorization faster
by alexfoxgill on Wednesday September 29, 2021 @05:08PM
(#28699972)
that probably wouldn't be sufficient to instantly grasp which bracket in a set of five opening brackets corresponded to its closing bracket. humans are not great at visually assessing minor differences in absolute size
Ideally, unlike in TeX, additions to nesting levels wouldn’t require a re-flow (i.e. typing a bracket wouldn’t make the code constantly shimmy around on the screen), but rather these would just be changes in the perceived size of these characters, while keeping them where they are on a monospace grid (since a lot of code assumes a pure monospace layout for indentation et al.)
In my imagination, this would work by just having a set of bracket/paren/brace/etc. graphemes in each font, that have increasingly-long ascenders/descenders, while the base size of of the “functional” part of the grapheme remains constant. As if there were five versions of the letter g, with an increasing length of the stem on which the lower hook rests.
As such, these magnified brackets would be rendered similarly to the way emoji are rendered in terminals: the grapheme would eventually “leak out” of its monospace box (in the emoji case to the sides; in this case above and below), to the point of eventually overlapping surrounding graphemes, rather than re-spacing the text to give it room.