Superadmin is a technical user. The most technical one actually. Thus it makes sense to provide the technical editor for it.
This is such an assumption that the “most technical user” is not supposed to be able to function without knowing the xwiki 2.x syntax in detail. I am also a technical user, and I sometimes use the wysiwyg editor because I just don’t know all the details of the syntax by heart (esp. the parameter names for the macros).
The wiki editor allows to do everything and without risking mistakes. When using the WYSIWYG ones, it’s easy to make mistakes and break things when you edit technical content (extra new lines, conversions, etc). The text editor is not easier to use for making tech changes but it’s also safer.
Let’s not forget 2 details:
- Don’t forget that the “source” button is available for most of these wysiwyg editors, so if you want to take full control in a wysiwyg, you can use the source button which is there for that, for superadmin users but not only.
- Even if the button would not be present (because of fancy wysiwyg config) you’d still have the option to change the default editor in the settings to “text” and restart the wiki, since what Enygma was proposing here is to keep the current situation for the editor instead of changing it to text. But one would still be able to change it, if needed.
The superadmin user is off by default and is a user that’s not supposed to be used except when you broke your permissions in your system and you need to change them back. It’s definitely not a user that you should use to edit pure content. It should only be there to edit technical content and the text editor is the best editor for technical content.
Of course there is discussion that can be done here, and we could start discussing all the other parameters of the superadmin users that could be set, based on one usecase or another.
If the superadmin is only for the permissions system, then why are we even talking about the editor, since the editor is not used in creating users or changing rights.
Also, if it’s about writing a script as superadmin to programatically manipulate rights, please note that this is why admin is advanced user as well, to easily be able to access the wiki editor of a page to write a script in the “technical editor”, so I would say that about 80% of the “technical content” is covered.
Also, the editor of a textarea field of a class has a setting about what type of editor to display (wysiwyg, text, puretext) and this is supposed to be defined properly upon class definition, in coherence with the type of textarea (is it for content, is it for script), to make that object properly usable (e.g. ssx & jsx objects, wikicomponent objects, etc.). Most of these classes are defined properly in the standard distribution (otherwise it wouldn’t be possible to develop with a user that doesn’t have text editor as their default editor) so yet another category of content on which you shouldn’t be bothered by the fact that the wysiwyg editor is configured by default (since they are displayed w/ text editor).
I honestly see very little cases that remain impacted by the default editor of the superadmin, other than the inline forms for applications, which are mostly about content, and having another editor than the default one of the wiki would look much more like a bug than like a feature.