@thehogfather thank you for the PR.
In general, from now onwards, the inline directives are mostly forbidden (there are still some exceptions).
In this case you can put MutationObserver after ArrayBuffer both in .eslintrc.json and .brackets.json.

I think @marcelgerber or @petetnt are better to review this one.

Looks like #10864 is fixed now, but I still see the other issue with the active line highlight

(This is Brackets running without extensions on the preinstalled Brackets Dark theme)

@marcelgerber could you share a link to the active line highlight issue? This PR only addresses the issues mentioned in the description. Neither of those have anything to do with active line highlights.

Ah, I see now. #11577 mentions the issue, but I thought it's all about it.
This may not even be the fault of this extension.

No I don't think the extension introduced the issue - although to be honest I am not actually sure what the expectation is here - so a little difficult to explore a solution.

Small general nit: Would be nice if all the magic strings would be moved to constants in the file, would make modifications somewhat easier / safer (can be done in another PR too though)!

Good job @thehogfather once again 👍

Is this waiting for anything @petetnt ?

I'll try to test this out once more and run the tests ASAP and merge this in if all is good.

There are some failing Code Folding tests which are unrelated to this PR which are being tracked in #12724.

This PR LGTM, merging.

Getting back to this, related to #12726 (comment) I believe this should be reverted, using MutationObserver is not a good thing. Especially if some other extensions tries to do the same thing, I expect we start to get infinite loops?

cc @marcelgerber @petetnt @thehogfather

This is a symptom of an underlying limitation (within the core libraries CodeMirror and brackets) - i.e., the absence of a rich API for manipulating the gutter in the editor.

At the moment, every extension (that requires the gutter) splices and directly manipulates the gutter without regard for how any other extension might be using the gutter wrt relative position / placement etc. Indeed it is difficult to preempt how many different ways the gutter might be used by other extensions.

What might be immediately useful in a hypothetical API would be the notion of an anchor gutter or gutters (say the line numbers gutter) such that placement of other gutters are requested relative to said anchor gutter(s). So one might say insert the code-folding gutter after the line-numbers, insert the git gutter before the line-numbers, insert theseus-gutter after git, before line numbers etc.

If such an API (or a much refined variation) existed, then there wouldn't be need for the MutationObserver (since all requests to manipulate would go through said API).

Re: infinite loops,
Totally possible if different extensions decided to use mutationobservers directly as well. The implementation in this PR itself should not cause infinite loops as it disconnects the observer while updating the gutter.

cc @zaggino @marcelgerber @petetnt
ref #12726

We should definitely set up an API in brackets, make this work with that API and let authors fix their extensions to use the API. Current state is not maintenable, and if we add this, another authors will do the same for their purposes and then we'll have a hell around a simple feature.

Haven't/didn't run to #12726 but let's revert this one and let's think of a nicer API for doing this.