Why is that so?

It's fundamental to working out how to draw the coloured boxes in the right places.

Are there any concerns that would block using the proper setting?

Yes.

How to query that setting in client javascript?

In the same way as any user preference; mw.user.options.get( 'editfont' ) in this case.

In T245568#5895138, @Jdforrester-WMF wrote:

Why is that so?

It's fundamental to working out how to draw the coloured boxes in the right places.

No, it works perfectly with a serif font, see:

Are there any concerns that would block using the proper setting?

Yes.

?

How to query that setting in client javascript?

In the same way as any user preference; mw.user.options.get( 'editfont' ) in this case.

Thanks.

Change 573018 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/CodeMirror@master] Remove the unnecessary 1.5em padding in MinervaNeue skin that misaligns highlights.

https://gerrit.wikimedia.org/r/573018

The patch 572876 fixes this bug for WTE 2010.
The solution for WTE 2017 is very different.

Why is that so?

The standard highlighting package applies bold and italics to bold and italic text. Without monospace this would affect the letter width which would break 2017WTE implementation. Given that using the edit font feature is pretty rare it was easier just to disable it for people who wanted to use syntax highlighting.

Change 573018 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Remove the unnecessary 1.5em padding in MinervaNeue skin that misaligns highlights.

https://gerrit.wikimedia.org/r/573018

Change 572876 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/CodeMirror@master] Fix the font-family: monospace; caused font-size mess-up: inherit the font setting from the parent in WTE 2017. Font set with style attribute in WTE 2010

https://gerrit.wikimedia.org/r/572876

In T245568#5897582, @Esanders wrote:

The standard highlighting package applies bold and italics to bold and italic text. Without monospace this would affect the letter width which would break 2017WTE implementation. Given that using the edit font feature is pretty rare it was easier just to disable it for people who wanted to use syntax highlighting.

I admit I haven't investigated bold/italics in detail. Now I've done a more thorough research, here's the result:

• CodeMirror highlights text in place, using in place html markup: it's the browser's job to render bold/italic/background in the right place, which it does, regardless of the font used, there can't be misalignment.
• WTE 2010 highlighting and text selection works as expected with any font.
• WTE 2017, on the other hand, does a weird thing with overlaying CodeMirror over VisualEditor, keeping the content of the two editors in sync and does something unexpected: the contenteditable=true attribute is on the quasi-hidden VisualEditor element, not CodeMirror's and CM is also not accepting input (pointer-events: none;), although
• the text in VE is hidden with: .ve-ce-documentNode-codeEditor-webkit-hide { -webkit-text-fill-color: transparent; }

The result is that text is selected in VisualEditor and the selection is visible behind CodeMirror. VE can become misaligned from CM as seen in T245532 and also bold and italic highlights from CM aren't transferred to VE, causing the cursor and text selection to appear in the middle of characters, misaligned if the font is not monospace. This is not an implication of CodeMirror, but how WTE2017 uses CM and duplicates the edited text in an invisible VE layer.
Note that while experimenting I noticed that a change in the font/size also causes such misalignment of the selection in WTE2010. This only happens if the font is changed after the editor was loaded, not in normal usage.

I've suspected the reason for doing this is so that CTRL+C copies rich text without highlighting. This is not the case, both WTE 2010 without this trick and WTE 2017 seem to be copying unformatted text. I'm still looking for the reason to do this.

The reason we did this is because NWE uses ve.ce.Surface as the edit surface. This is where all our input support is coded, including things like RTL and IME support, which are more buggy in CodeMirror, and also things like inline inspectors (like the link inspector). The two surface approach is a workaround to allow us to keep using the ve.ce.Surface.

In T245568#5907931, @Esanders wrote:

The reason we did this is because NWE uses ve.ce.Surface as the edit surface. This is where all our input support is coded, including things like RTL and IME support, which are more buggy in CodeMirror, and also things like inline inspectors (like the link inspector). The two surface approach is a workaround to allow us to keep using the ve.ce.Surface.

That's a good reason.
How is this handled in WTE 2010? Using CodeMirror, it's just a bit buggy?

It's just buggy.

In T245568#5916078, @Esanders wrote:

It's just buggy.

If anything, in particular, comes to mind, that would help me understand the implications.

Change 572876 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Don't let CodeMirror set the font to monospace if it's set on an ancestor.

https://gerrit.wikimedia.org/r/572876

NB for anyone else watching this task, the above patch does not change the behaviour outlined in the description.

Unfortunately, we can not prioritize this at this time.

Off the top of my head:

1. RTL issues: https://github.com/codemirror/CodeMirror/issues?q=is%3Aissue+is%3Aopen+rtl
2. Inspector placement. We need to know the bounding box(es) of the selected text to place things like the link inspector.

I understand these are issues, but not the technical reasons.

In T245568#6254833, @Esanders wrote:

1. RTL issues: https://github.com/codemirror/CodeMirror/issues?q=is%3Aissue+is%3Aopen+rtl

As I understand the current solution depends on CM rendering correctly (visually the same as VE). If there are issues in RTL, does that mean the two layers are misaligned when these bugs in CM take effect for RTL users?

2. Inspector placement. We need to know the bounding box(es) of the selected text to place things like the link inspector.

Without diving deep into the code I'd assume acquiring the bounding box for the selection would be done similarly in both layers. What is the difference? Is there some logic in VE that makes this easier, that's not available in CM?

In T245568#6255594, @Aklapper wrote:

Resetting task status as anyone is free to revisit the question.

Thank you. Hopefully someone would, I just doubt it with a 99% certainty.

@Esanders should I expect details to your answer in T245568#6254833?

I personally use the below style to patch the text misalignment on the 2017 Wikitext Editor:

.ve-ui-mwWikitextSurface :is(.ve-ce-attachedRootNode, .CodeMirror)
{
    font-family: revert !important;
}

Maybe the style would work on the older editors with slight modifications.