This document explores the ramifications of four ideas, ranked by disruptiveness:
The following options share the following details:
doc.language.id !== “image”
getActiveEditor()can return an "immutable" editor, it seems like
getFocusedEditor()could return the same.
getFocusedEditor()is null would be pretty buggy already anyway...
Also known as Glenn's proposal
getCurrentFullEditor()in this case.
getCurrentFullEditor()would return an ordinary Editor whose
_codeMirrorinstance would still exist (behind the image div), but would be read-only. Is that still true? If so, we should explain that, and mention that our intent would be to make it so that instance basically never takes user input.
Also known as the original proposal - based on the discussion and outline here
Random and incomplete collection of extensions will likely break:
code folding, delete-line-start-end, superclipboard.js, case-converter, brackets-special-html-chars, brackets-minifier, brackets-indent-guides, spell-check, brackets-xunit, brackets-beautify, camden.w3cvalidation, cezarwojcik.cleaner, dehats.annotate, dehats.prefixr, dehats.togist, fontParser, enturn.quick-search, fontface.brackets-vimderbar, mikaeljorhult.brackets-autoprefixer, ...:
Note on the meaning of breaking: In many cases errors will only occur if i.e. a command provided by an extension is invoked while an image is displayed. The extension may continue to work fine on regular text documents. But some extensions will be rendered completely broken, i.e, those that make calls to changed APIs on startup.
seems to be the least likely choice, being the most disruptive.
This is not fully fleshed out as it doesn't seem to be the obvious choice.
I suggest to implement Glenn's proposal for the following reasons
While this relatively small change enables a solution with a good user experience it seems small enough to revert, i.e in case of the need for more flavors of viewers and editors. During feature discussion the need for displaying additional types of documents was rated unlikely.