[wp-trac] [WordPress Trac] #12423: Include Ace (or similar) as default code editor

[WordPress Trac]

#12423: Include Ace (or similar) as default code editor
-----------------------------+----------------------------
 Reporter:  scribu           |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  4.8
Component:  Editor           |     Version:  3.0
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:  accessibility
-----------------------------+----------------------------

Comment (by FolioVision):

 Hi Iseulde.

 Adding a proper code editor would be a huge improvement to the core
 editor. I have some ideas about also  [https://foliovision.com/2017/02
 /better-wordpress-editor splitting Visual into Preview and Writer] but
 that's a bigger jump. You wrote:

  So a code editor could also mean no more auto-p!

 Yes to that. When we wrote [https://wordpress.org/plugins/foliopress-
 wysiwyg/ Foliopress WYSIWYG] (the low ratings came in a period where we
 were had decided to end of line Foliopress WYSIWYG and migrate to the core
 Editor. In the end we were unable to do so as too many complex posts were
 broken on save in TinyMCE. Most of our users stopped using Foliopress
 WYSIWYG during that period. It does work well enough that there were about
 10,000 active installs at its peak) we contended with exactly those issues
 with WP auto-p. We ended up disabling auto-p completely. Yet we had to
 count on people turning our editor on and off. So we wrote some code
 (which is in the current editor) to deal with posts that are counting on
 WP auto-p in a resilient way.

 We'd be happy to help with a migration forward which eliminates WP auto-p
 going forward yet does not break existing posts on open or require active
 intervention from end users.

 '''Syntax colouring'''. For the new code editor to be truly useful, syntax
 colouring is essential. This mania for low contrast design is just a
 fashion trend.  It will swing back. Form should follow function. I think a
 subtle colour scheme would be far more useful for WordPress publishers
 than a trendy low contrast look. I should add that for those users in
 their forties and beyond, low contrast is almost unreadable/unusable. For
 accessibility reasons alone we should include coloured syntax.

 If you look at the [https://ace.c9.io/build/kitchen-sink.html full Ace
 Demo], there's a lot of skins available. I'd suggest both Eclipse and
 KatzenMilch could be subtle enough colour schemes to fit in well with
 WordPress.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12423#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform