Currently when writing in code view, Octo Preview doesn't get updated. Maybe need to trigger changes on the textarea somehow or ask for upstream integration.

https://github.com/DrewML/octo-preview

Love this extension! I noticed though that specifying the language results in extra classes that aren't currently captured by rules that apply font-family: monospace.

For example:

And after applying a language:

Note that the parentheses and spaces (which are trickier because they don't have an associated span) are no longer monospace.

Applying monospace to.CodeMirror-wrap pre catches the whole text box so that I didn't immediately see a solution.

Glad to submit a PR if there's an easy solution; just didn't happen to see one. Thanks again for the plugin!

From: #5 (comment)

Not entirely sure how simple it is, but it would be great if we just used the same fonts / highlight colors as GitHub itself.

Codemirror does have theming capabilities. Not sure what's involved.

I am using Safari as my primary browser and I would be happy to have this extension. Or you can pack this as “user script” or “user style” to use with Stylish and/or Tampermonkey.

Maybe when we've decided this is super stable, hide the Write tab, but for now I want to be able to break this extension without breaking GitHub.

I think we should create an options tab. Normally I subscribe to the "sensible defaults" school of thought, but editor config is just too personal. A biggie (I think) is keymap support. People will want to be able to use the same keymaps as their favorite editor.

Really, I think we could have very robust options, especially as it relates to all the addon features. In that case, supporting the "options" is already implemented, we are just creating a UI to configure them:

We could define most of codemirrors options pretty simply:

{ 
  name: 'closeTags',
  displayName: 'close tags'
  description: 'automatically close tags'

  // type boolean creates a checkbox
  type: 'boolean',
  default: 'true',

  // the scripts that need to be loaded
  scripts: [
    'codemirror/addons/editor/close-tags.js'
  ],

  // values that need to passed to Codemirror when selected
  injectedOptions: {
    autoCloseTags: true
  }
}

https://github.com/codemirror/CodeMirror/wiki/CodeMirror-addons

Need to determine if there is any noticeable performance impact.

Considering pulling in some of the more popular languages on GitHub

Feature Request

I spend most of my day not in github.com, but on my company's own github enterprise. Much like refined-github supports GitHub Enterprise, making my life a lot easier, it would make code review at work significantly easier if I could use this fantastic extension there too.

Colors are not compatible with https://github.com/StylishThemes/GitHub-Dark

Please consider providing a dark theme.

ctrl+meta+p is currently used by GitHub to cycle through the Write and Preview tabs. Should add support for the Code tab to be included.

GitHub handles this currently by setting data-hotkey="ctrl+P,meta+P on the next tab that should be cycled to.

I cannot switch to the “Code” tab; clicking on it triggers nothing. On browser console I saw

Uncaught TypeError: Cannot read property 'classList' of null
    at dom.js:4
    at Array.forEach (<anonymous>)
    at removeClasses (dom.js:4)
    at TabHandler._onBtnClick (tab-handler.js:103)
    at HTMLBodyElement.<anonymous> (tab-handler.js:81)

Would love to see this in Firefox.

We can probably improve performance by splitting the large bundle up, and loading language modes on demand.

We could perhaps keep track of the users most recent modes in storage, and always load them.

Codemirror already has an addon module to support this: https://codemirror.net/doc/manual.html#addon_loadmode

We would ship all the modes with the extension, but not waste time loading jade and tiki for everyone.

If codemirror/codemirror5#5891 passes.

OctoEdit requires <? or <?php opening tags to apply syntax highlighting to ```php blocks, Github syntax highlighting is broken by the opening tags.

This could be awesome: https://codemirror.net/doc/manual.html#addon_lint

Demo here: https://codemirror.net/demo/lint.html

I think you would need to be selective about the linter rules you applied. You want people to be able to write incomplete snippets. But we could probably just select eslint rules that would catch dumb mistakes.

I would mark this as "low-priority".

I have 0 design skills, so this will never be done by me :)