Accommodating kerned spans in WebKit about codemirror5 HOT 14 CLOSED

It worked like that (cursor being inline element) at some point, but, if I remember correctly, I got rid of it for two reasons:

• Slight efficiency gain -- don't need to re-render lines when the cursor is moving
• Couldn't find a way to create zero-offsetWidth inline elements in IE6

from codemirror5.

Sorry, I think I wasn't clear... what I mean is determine the x of the cursor based on the x of the current span + the width of the inner text, rather than the width of the line's entire text. That way the spacing of the spans is removed from the equation, because the span's x already takes it into account. The current method is to put text into the hidden div and calculate its width overall, which becomes inaccurate if the spans aren't spaced as expected.

from codemirror5.

This requires DOM walking and munging though, which is notoriously inefficient. Still, we probably don't need to do it all that often, and there could be an option (variableWidthFont: true) so that only people who need it pay the price.

from codemirror5.

Well, in that case then the better solution is to continue calculating x as-is, but reproduce the span structure within the hidden div. I've tested this out in charX and it works fine. The cost of doing it is so infinitesimal I can't imagine an option would really be worth it. Besides, it's not only variable width fonts that affect this issue but also margins, bolding etc. Basically any styling is off-limits unless a high fidelity copy of the line content is made before placing the cursor.

from codemirror5.

So how are you building the HTML? Extra argument to getHTML? (Or just put your code in a github fork.)

from codemirror5.

In my test I just grabbed the lines[line].styles property and looped over its elements to create dummy spans until the text content length exceeded cursor position, then trimmed off any excess characters. I haven't had a chance to fully absorb the new design yet so I'm not sure if getHTML would be more efficient.

from codemirror5.

This won't work if the line has marked or selected styles that influence the width, and since the logic is already there, adding a limit argument to getHTML seems more effective.

from codemirror5.

Ok cool. I'm glad there's hope because without full styling and font support I'll have to stick with CM1 :/ Thanks for considering this.

from codemirror5.

Wontfix.

from codemirror5.

Well past caring...

On 17/03/2011, at 11:51 PM, marijnh wrote:

Wontfix.

Reply to this email directly or view it on GitHub:
https://github.com/marijnh/CodeMirror2/issues/30#comment_884860

from codemirror5.

How is this possibly a wontfix?

from codemirror5.

David has indicated he is no longer interested in CodeMirror. I personally don't care about variable-width fonts. Until someone else volunteers to work on this, it is off-radar.

from codemirror5.

I guess I don't care about variable-width fonts in a code editor either. Just thought it should be supported.

from codemirror5.

It's not just variable-width fonts, it's any width-related CSS formatting like bolding even. It's a pretty fundamental flaw, and fixing it would probably help resolve the lack of line wrapping as well.

On 18/03/2011, at 1:17 AM, marijnh wrote:

David has indicated he is no longer interested in CodeMirror. I personally don't care about variable-width fonts. Until someone else volunteers to work on this, it is off-radar.

Reply to this email directly or view it on GitHub:
https://github.com/marijnh/CodeMirror2/issues/30#comment_885179

from codemirror5.