I had a false positive on this component. I think it may be from the bullet point items? I made all the text lorem ipsum but the structure is the same:
Hi,
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
https://www.discourse.org
Lorem ipsum dolor sit amet, consectetur adipiscing elit:
* pull_request
* pull_request_review
* pull_request_review_comment
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis `nostrud` exercitation ullamco `laboris` nisi ut aliquip ex ea commodo consequat.
https://www.discourse.org
Lorem ipsum dolor sit amet:
* push
* commit_comment
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Thanks,
Martin
But isnât pull_request, pull_request_review, etc actually code? I guess I need more specifics on exactly what was in that list⌠Iâd view it as a correct positive, not a false positive?
I would argue itâs not a correct positive because it is not a block of code, it is in a list. And those are GitHub webhook âactionsâ that I have listed. But not a huge deal I guess, just seemed odd to me and I thought I would report it in case.
Minor nitpick: The default for the warning_modal.content is asking for the âcodeâ toolbar button, but this button is called the âPreformatted textâ button in the editor when you hover over it with your mouse.
To make it easier for new users to find this button (they will not find any code button), the warning_modal.content should be changed from âcode buttonâ â âPreformatted text buttonâ.
I just noticed that changing even a single character in warning_modal.content breaks the formatting.
Even worse: Just clicking into the warning_modal.content input field and then moving the cursor by the arrow keys makes the input field highlighted. After clicking the green checkmark to save the âeditedâ warning_modal.content (no change at all has been done, just moving the cursor one character), the formatting is broken as shown above.
@codinghorror@lionel-rowe Maybe you should look into this and adjust the default warning_modal.content accordingly regarding spaces and backticks (missing spaces within the heavily with backticks equipped âmultiplelinesâ section were causing the problems described above).
The user obviously tried to follow the instructions, but chose the wrong key for the code fences ( ' instead of `). In the past I have also seen ... instead of ```. Both cases indicate that users need more explicit instructions which key to choose.
Alternatively: Donât confuse users with those keys and just say: Use the âPreformatted textâ button and you are done.
@lionel-rowe How can I customize the detection behaviour?
Currently the shebang is not detected as code, and I would like to change this.
Expected behaviour: #! indicates the beginning of a script and therefore should be detected as code.
In addition to this, it would be useful for us if root@ would be detected as code.
root@OpenWrt:~# ip link add link eth0 name eth0.9 type vlan id 9
root@OpenWrt:~# brctl addbr br-foo
root@OpenWrt:~# brctl addif br-foo eth0.9
root@OpenWrt:~# ip link set eth0.9 up
root@OpenWrt:~# ip link set br-foo up
There isnât any way to have per-site customizations at the moment, no. We could certainly look at adding shebang and shell prompt detection to the âcode energyâ system though.
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:
Does this also check for unformatted JSON? Iâve installed this plugin and added it to my theme, then tested with code examples (like the example in the gif) as well as JSON and I cannot get it to detect and warn me.
Iâve just encountered an issue with trying to edit a post with an indented codeblock. It appears this theme component does not like that style anymore and insisted on backticks.