Since it uses Local Storage when the user switches browser (goes back home, change from FF to chrome, etc) the setting will be lost. Right now we've never used LocalStorage in xwiki-platform and instead relied on user preferences. I'm not sure Local Storage is the best since user prefs seems to support more use cases. Local Storage could be a first version though.

Small remark: "Enable" would be nicer than "Allow".

@Caty: any feedback on the placement and UI?

Personally I think it takes a bit too much space and I'd rather have the config located in the user profile since I don't think the user is going to switch continuously back and forth (a shortcut could be nice to enable/disable it fast though).

Vincent Massol
added a comment - 15/Dec/15 18:02 - edited Thanks for the screenshots Yann.
Since it uses Local Storage when the user switches browser (goes back home, change from FF to chrome, etc) the setting will be lost. Right now we've never used LocalStorage in xwiki-platform and instead relied on user preferences. I'm not sure Local Storage is the best since user prefs seems to support more use cases. Local Storage could be a first version though.
Small remark: "Enable" would be nicer than "Allow".
@Caty: any feedback on the placement and UI?
Personally I think it takes a bit too much space and I'd rather have the config located in the user profile since I don't think the user is going to switch continuously back and forth (a shortcut could be nice to enable/disable it fast though).

The problem with the current implementation proposal is that it is not thought out all the way and just does it (exactly as you`ve mentioned) exactly the way it was done for the RTWiki extension. In the case of the RTWiki extension, that might be enough, since you have a single editor instance on the page.

Thanks for the screenshots Yann Flory, but could you please add a screenshot with the object editor having more than JSX object? (maybe 1-2 SSX objects as well?)

As commented on the commit, the current implementation adds a checkbox next to each editor but has the effect of controlling the same preference (the same key is used in local storage). Controlling preferences for individual editors is tricky, as it involves correctly identifying the editor instance for which you save preferences, even after a page reload (when you want to apply the saved preference).

This is the reason for my initial question, as to what do you wish to achieve in the end. If it is just an option to temporarily disable syntax highlighting for a particular editor instance or if it is about allowing a user (non-admin) to control whether he wishes to benefit or not from the syntax highlighting feature (user preference). While the first version might be useful during development, in practice it would become more of a useless bloating of the UI, as the user either wants highlighting or not, but as Vincent Massol mentioned, it's not something the user changes constantly and needs to be 1-click distance from him all the time.

One suggestion for this temporary disabling option to still be there is to add it as an option, even configurable by an admin, since we already have an administration section for the application. It would not involve saving any preference, but just disabling and re-enabling a particular editor instance. By default, this option would be disabled.

Eduard Moraru
added a comment - 15/Dec/15 18:32 The problem with the current implementation proposal is that it is not thought out all the way and just does it (exactly as you`ve mentioned) exactly the way it was done for the RTWiki extension. In the case of the RTWiki extension, that might be enough, since you have a single editor instance on the page.
Thanks for the screenshots Yann Flory , but could you please add a screenshot with the object editor having more than JSX object? (maybe 1-2 SSX objects as well?)
As commented on the commit , the current implementation adds a checkbox next to each editor but has the effect of controlling the same preference (the same key is used in local storage). Controlling preferences for individual editors is tricky, as it involves correctly identifying the editor instance for which you save preferences, even after a page reload (when you want to apply the saved preference).
This is the reason for my initial question, as to what do you wish to achieve in the end. If it is just an option to temporarily disable syntax highlighting for a particular editor instance or if it is about allowing a user (non-admin) to control whether he wishes to benefit or not from the syntax highlighting feature (user preference). While the first version might be useful during development, in practice it would become more of a useless bloating of the UI, as the user either wants highlighting or not, but as Vincent Massol mentioned, it's not something the user changes constantly and needs to be 1-click distance from him all the time.
One suggestion for this temporary disabling option to still be there is to add it as an option, even configurable by an admin, since we already have an administration section for the application. It would not involve saving any preference, but just disabling and re-enabling a particular editor instance. By default, this option would be disabled.
WDYT?

Another idea would be to simply add a keyboard shortcut that simply disables the editor and brings back the standard textarea that it was augmenting. It avoids completely the UI problem of where and how to display it, while still allowing the feature to exist, if it should really be needed by some buggy usecases that are asking for the editor to be disabled. Of course, the settings used when initializing the editor should be saved in the textarea's DOM so that they can be reused when re-enabling the editor instance, if this re-enabling functionality is desired (since a simple page refresh could easily take its place otherwise).

This idea could also be extended in the Syntax Highlighting application, if you like, to be able (when focusing a textarea) to perform a keyboard shortcut and augment the focused textarea with a CodeMirror editor using a mode that the user picks from a modal popup/dialog. You could see it as similar to the popular browser add-on "It's All Text", but using codemirror instead, inside the browser. Perhaps this last part deserves its own issue

Eduard Moraru
added a comment - 18/Dec/15 17:04 Another idea would be to simply add a keyboard shortcut that simply disables the editor and brings back the standard textarea that it was augmenting. It avoids completely the UI problem of where and how to display it, while still allowing the feature to exist, if it should really be needed by some buggy usecases that are asking for the editor to be disabled. Of course, the settings used when initializing the editor should be saved in the textarea's DOM so that they can be reused when re-enabling the editor instance, if this re-enabling functionality is desired (since a simple page refresh could easily take its place otherwise).
This idea could also be extended in the Syntax Highlighting application, if you like, to be able (when focusing a textarea) to perform a keyboard shortcut and augment the focused textarea with a CodeMirror editor using a mode that the user picks from a modal popup/dialog. You could see it as similar to the popular browser add-on "It's All Text", but using codemirror instead, inside the browser. Perhaps this last part deserves its own issue