Page MenuHomePhabricator

Code editor should work stand-alone, and not need the user to enable the 2010 wikitext editor (WikiEditor)
Open, LowPublicFeature

Description

Code editor does the line numbering, syntax highlighting and indentation, and it should stay that way. No need for *code* editor to provide *writing* tools.

When editing module with the code editor, user will hardly ever need clickable features from the WikiEditor (signature, links, bold, headline etc...), thus why such resource consuming tool should be loaded when not used.

Actually if there should be any clickable features, then rather a list of keywords for instance and other things relevant to the *coding*. (Nice feature would be list of function definitions eg. but that's for another bug, just an example here.)

Bug 26918 mentions editors should be standalone. And user should be able to choose which editor to load on given page / namespace.


Version: unspecified
Severity: enhancement
See Also:

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 2 support votes, and was ranked #94 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Miscellaneous#Ability_to_enable_code_editor_separately_from_.22enhanced_editing_toolbar.22

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:27 AM
bzimport added a project: CodeEditor.
bzimport set Reference to bz45850.
bzimport added a subscriber: Unknown Object (MLST).

What is the current problem, and what is your request?

When editing the Module, even when the enhanced toolbar is turned off in prefs, code editor still uses that and even if the code editor is turned off, still the enhanced toolbar is shown instead of the classical one.

Code editor switch button must be independent on the toolbar.

Enhanced toolbar must not be loaded when the code editor is off.

  • Bug 55936 has been marked as a duplicate of this bug. ***
  • Bug 55419 has been marked as a duplicate of this bug. ***

Change 130068 had a related patch set uploaded by TheDJ:
Persistent disabling of CodeEditor

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

OK, so the thing is that yes, in theory it can do that. But in practice, I don't want it to support too many modes. It's not like it gets too much eyes to begin with, it makes it more difficult to support.

Also I want to add a few buttons (bug 59924) etc and I have a patch to hide some of the normal wikieditor buttons that won't really apply (https://gerrit.wikimedia.org/r/#/c/118993/), so I do actually want some sort of toolbar.

I'm therefore proposing to make the coupling between the two even stricter (fixes of bug 46779) and better persisted and will close this as WONTFIX.

People without WikiEditor enabled will therefore also not be able to use CodeEditor.

There is absolute nonsense to provide dozens of buttons for visual editing which are useless for code editing.

Also, in the sense of bug 26918, every editor should be standalone.

When I don't want to use WikiEditor, I don't want to use it. No matter on which page I am, including css/js/lua. Wikieditor consumes lots of resources and that's why I (and many other people) have it in preferences turned off. MediaWiki must treat my preferences and not push me to consume my resources when I want to edit code pages.

However, while on css/js/lua page, if I would like to use the code editor, I want to turn on just the *code* editor, without those useless buttons OR have plain textarea. Now I am pushed to have the WikiEditor and you even plan to push people to have either nothing or both. That's wrong approach. The choice must be CodeEditor or plain textarea. No WikiEditor involved. If anybody will miss any button, CodeEditor can be easily customized like WikiEditor is.

Change 139760 had a related patch set uploaded by TheDJ:
[WIP] Try to split out wikiEditor vs codeEditor toolbar

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

Did some work on splitting this further out:

https://gerrit.wikimedia.org/r/139759
https://gerrit.wikimedia.org/r/139760

This is work in progress, i'm moving to a situation where in the case of disable enhanced toolbar, the code editor is able to build it's own toolbar, instead of adding to the WikiEditor toolbar.

It still would use the WikiEditor framework to communicate with ACE. The toolbar for ACE is one that uses the WikiEditor toolbar api. Still needs to take into account 'usecodeeditor' preference and needs a designated button in the editor to 'enable' the code editor if it is currently disabled.

He7d3r set Security to None.
He7d3r updated the task description. (Show Details)

Change 139760 had a related patch set uploaded (by Paladox):
[WIP] Try to split out wikiEditor vs codeEditor toolbar

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

There are several approaches that can be taken here:
1: Add something to the pile of preferences and create a deeper mess inside the toolbar/editor logic
2: Properly fix the toolbar logic to give people the option to choose an editor for each page type. Manage the registration of these editors. Note that you will probably require separate config options for several types of pages. I would advise consulting with the VE team, since they and Mobile have yet more editors for pages...

IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Jdforrester-WMF renamed this task from Code editor should not be cuffed to the enhanced toolbar to Code editor should work stand-alone, and not need the user to enable the 2010 wikitext editor (WikiEditor).Nov 6 2018, 4:23 PM
Jdforrester-WMF removed a subscriber: wikibugs-l-list.
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM