Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter? I don't know; it's a tradeoff between performance and flexibility. My feeling is that there's a lot more room to improve the implementation before we have to resort to reducing capabilities, but reasonable people can disagree.
Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.
The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really. Variable width text is generally considered easier to read, so why couldn't this also apply to code?
It's not just for neatness; either. Alignment shows where differences are between similar lines. And not necessarily consecutive lines. For instance, if we rapidly flip the editing window back and forth between two buffers showing similar code, we can see the differences as the moving parts in a two-frame animation.
Even in proportional fonts, the digits 0 to 9 get the same width. Why? So that tables of figures will look reasonable.
We don't want 1111.11 looking narrower than the 100.00 in the preceding row.
I want everything to be crisply aligned between lines like:
xr = x * cos(theta) - y * sin(theta);
yr = x * sin(theta) + y * cos(theta);
Because alignment.
>The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really.
Most programmers I know would argue otherwise, including me. Wanna try a poll?
>Variable width text is generally considered easier to read, so why couldn't this also apply to code?
Because it's only considered "easier to read" for general text (books, articles, etc) where you don't need to quickly see anything standing out of the ordinary, and alignment doesn't matter.
Even for traditional uses like accounting, "variable width" is not considered easier to read.
Which give even more credence to what the parent said: that "CSS isn't the right abstraction for styles in a text editor…".
We don't really need the "more power" in an editor, but we could use the less slugginess (and less conceptual overhead) than what CSS offer.
>Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter?
I'm pretty sure existing editors can do that today too, without CSS. Setting a different font size for comment lines for example.
Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.
To know how high the editor is, for scroll bars, Sublime Text-style minimaps, etc.
Computing metrics basically requires computing full style information. Doing cascading for any property isn't much more expensive than doing cascading for all properties.
> Based on my limited experience, most text editors don't have correct information for off-screen content anyways, as they tend to do lazy syntax highlighting, which you can sometimes see adjusting while you scroll.
Sure. The way to do that in the Web platform is to do what Atom is doing here: adjust styles only when elements come into view. IntersectionObserver can be useful for that.
It would be great to have a small high-performance subset. The subset needs not have low expression power, though.
That includes font-* and many other attributes that affect text rendering. It isn't possible to know the length of a line of text without computing most of the text layout in modern font rendering. Font family/size/variant, weight, kerning, vertical hinting, traditional horizontal hinting, and LCD subpixel hinting all influence character positions at 1/256 pixel resolution. I highly recommend this[1] paper for a good overview of how this works, which includes an analysis of why Microsoft's older font handling caused serious layout issues (cumulative x-length error) due to over-hinting that forced glyphs onto the pixel grid.
> editors
Monospace fonts usually let you ignore most of these issues, but some (crazy?) people program with proportional fonts[2], and we can't actually ignore Unicode...
(I just use an 80/20 solution: fast - and predictable - Terminus and Dina bitmap fonts most of the time, and let Unicode distort the layout with other stuff as needed)
[1] http://www.antigrain.com/research/font_rasterization/index.h...