[pcwalton]

CSS is more powerful than anything that popular native text editors can do. As far as I'm aware, in native text editors, generally, style can't influence (block-direction) layout, and that's why they can get away with determining what's visible before restyling. Once you have styles that can influence layout, this dependency is reversed, so any native text editor will have to restyle off-screen lines just as a browser must.

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.

[kazinator]

Should it be impossible for a theme to make comment lines taller or shorter?

Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.

[capnrefsmmat]

My Emacs Org-mode setup already has larger font (and taller lines) for headings, so this isn't too crazy. Not everything in a text editor is code; some of it is text.

[aninhumer]

Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.

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?

[kazinator]

Alignment isn't a minimal benefit; it is super important.

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);

This makes it easy to see where the differences are. Any gratuitous deviation from the alignment is visually distracting. I want to be able to scan the thing vertically y and see that I have two x's, two y's, cos/sin sin/cos, and -/+ at a glance.

[patrec]

This must be why math literature has been using fixed width fonts for hundreds of years! No way you could ever align something with (hugely more readable) proportional fonts. BTW, numerals are not automatically same width in proportional fonts; a good font will often have both (and for tables you'd explicitly switch to tabular figures, which will align properly).

[coldtea]

>Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to.

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.

[NTripleOne]

Fuck knows why it couldn't - but in my personal experience code is infinitely more difficult to read without a monospaced font.

[coldtea]

>CSS is more powerful than anything that popular native text editors can do

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.

[pcwalton]

If any editor has to restyle all lines, even lines that are off screen, and it supports declarative themes, then it must do the very same thing the browser does. And I suspect that any editor that does this styling will end up being slower than browsers are at this task, because of the sheer amount of optimization that has gone into browser styling at this point.

[cwzwarich]

Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information.

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.

[pcwalton]

> Why do you need style information for off-screen content in a text editor? It's not like you're going to have JS running that can query the computed style at any point. If it's for scrollbars then you can probably just use an approximation, or compute metrics without actually computing full style information.

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.

[nine_k]

CSS gives a lot of power; I'd say too much for a code editor.

It would be great to have a small high-performance subset. The subset needs not have low expression power, though.

[pdkl95]

> Is it worth restricting an editor to only styles that don't influence block layout?

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...

[2] https://news.ycombinator.com/item?id=1056683