Opinion: How necessary is the syntax-highlighting?

[erosman]

I am hoping for some feedback on this issue.

Personally, I always use a dedicated editor for programming and then paste it into GM. Non-programmers hardly ever edit scripts and use them verbatim.

Therefore, how necessary is the syntax-highlighting in a GM type extension?

It looks better with it but it adds a lot of processing (and resources) in comparison with plain text free editing of textarea type input. Contenteditable elements can become very slow to process for browsers when there are many lines of code. Today, I tested JSfiddle and pasting a 12k line script, took 12 seconds to show in the editor.

I am working on an extension and although I have written the syntax-highlighting code (I never use libraries), I am not 100% sure which would be the better approach and therefore I welcome your opinion.

Regards e.

[Martii]

How necessary is the syntax-highlighting?

I assume you mean in the context of GM4. If so it's helpful for a visual aid. Humans make typos all the time whether they admit it or not and that can be one addition. Validation software is also nice but parallax, and other perceptual conditions, can come into play with non-changing text especially when staring at a logic issue for hours. Breaking up the visuals can assist.

in comparison with plain text free editing of textarea type input

The overhead depends on how many languages it supports. There's currently only a few handfuls that we usually support on OUJS but we include them all. Within a .user.js engine though that could be less than a handful.

Non-programmers hardly ever edit scripts and use them verbatim.

Depends on how much time is available. You're using a variant of Ace in this discussion and any time you do a GH commit.

I am not 100% sure which would be the better approach

Try a 65 million line script (humble me) and try to inspect it. DOM weight can be a factor too with other tools. Usually breaking up component lines (like most highlighters do) ensure improvement in parsing by handling smaller items. Performance improvements can occur with a highlighter in effect.

[erosman]

Thank you for your feedback.

The code is written by me (not Ace or CodeMirror or other libraries). The Syntax-highlighting is for user-scripts and only limited to a couple of languages.

The highlighting itself is not a problem. The associated issues have given me pause to think.

• For example, my code highlights a 5k line script in about 500ms but Firefox takes about 2 seconds to display it.
• Copy & paste in/from contenteditable does not behave as they do normally (some new lines get lost).
• There is no 'change' event for contenteditable so the option is limited to 'input' which fires on every single character entry or 'blur'; both of which have drawbacks. Mutation events also fires similar to 'input'. Refreshing the highlighting on every input takes a great amount of resources and can take time for Firefox to update the display thus result in lag. Refreshing on blur (which is the currently selected method) require the user to click outside the edit box which can be less user friendly.

These were my concerns.

[erosman]

Happy New Year @Martii

Just for Info, I have released my User Script/CSS Manager extension FireMonky.

I look forward to constructive feedback. https://github.com/erosman/support/

[Martii]

@erosman Kewl... I'll give it a whirl when I get a free moment (what are those anyways? ;) . Source looks great. :)