It depends how much the rules can be edited; I’m unclear how the rules are edited. Can you clarify a bit @david in the first post?
I’m afraid at the moment the rules can’t be edited. The sensitivity can be adjusted, and html detection can be turned on/off.
There are some built-in rules which should help with these. If you’d like to try it out, try posting some code in a PM to yourself here on Meta.
However, I think the example you posted is unlikely to be detected, since it doesn’t contain any special characters or timestamps which match our detection patterns.
The original vision I had was for a component where you could specify how much “energy” a given character (or complete string, such as C:\) adds, especially as that character (or string) begins repeating in the same nearby area over and over, multiplying the code energy score.
Sensors:
System Temperatures: cpu: 78.0 C mobo: 36.0 C gpu: nouveau temp: 56.0 C
Fan Speeds (RPM): cpu: 0 fan-1: 3139 fan-3: 0 fan-5: 0
Power: 12v: N/A 5v: 2.90 3.3v: N/A vbat: 3.34
This is rather colon heavy. So ideally if you wanted to tweak this, you’d set an energy level for the colon, and a repetition bonus.
I guess that is not possible at the moment, it is unfortunate all the rules are hard-coded.
Just to clarify @tmomas’s note - We use a custom version of this plugin with some additional code-matching patterns not in the stock version. We also added a bit of user-interface to add (albeit unchecked and with much caution), custom regex patterns. Refs:
11 posts were split to a new topic: Can the Unformatted Code Detector be disabled per user?
There is an error referencing this component in my browser console:
[THEME 230 ‘Unformatted Code Detector’] Attempted to modify “service:composer”, but it was already initialized earlier in the boot process (e.g. via a lookup()). Remove that lookup, or move the modifyClass call earlier in the boot process for changes to take effect. Using modifyClass to change core behavior
Thanks @Moin , we are aware of this, it has already been reported internally and is scheduled to be updated as soon as possible.
Thanks for the reports! This should be resolved following this core change
