#4385 - Unable to display two consecutive Hyphen-Minus characters in code boxes
| Identifier | #4385 |
|---|---|
| Issue type | Minor issue (breaks specific functionality) |
| Title | Unable to display two consecutive Hyphen-Minus characters in code boxes |
| Status | Completed |
| Handling member | PDStig |
| Version | 10.0.31 |
| Addon | core_comcode_pages |
| Description | Saving a Comcode page with two Hyphen-Minus characters next to each other converts them into a single longer dash, by design. If I place two Hyphen-Minus characters next to each other within a code box, they are not replaced in the editor upon saving, but they are still displayed as a single longer dash in the rendered page, which is incorrect.
The Hyphen-Minus character is also known as: * HTML entity: - * UTF-8 encoding: 0x2D I thought I was working around this issue by using the HTML entity instead of the regular character, but that workaround is not currently working, so the behavior may have changed or I may be remembering wrong. At this point, I've tried to work around this in various ways: --texthere --texthere <span>-</span><span>-</span>texthere In all of these cases, the rendered page displays a single En Dash character (\u2013) instead of the two minus characters. |
| Steps to reproduce | Create a code box with two Hyphen-Minus characters followed by some other text (just two minus characters instead creates a horizontal rule):
[code] --test [/code] |
| Additional information | The use case for two hyphen-minus signs in a code box is displaying Bash commands, which use two hyphen-minus characters to begin long flags:
* certbot --apache * msktutil --computer-name While I can understand converting to an EM dash for normal text, the code box should render text exactly how it was entered. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
Fix one thing, another thing breaks.
I've been maintaining a unit test with various cases to address this.
This issue is now resolved with a major cleanup of how the code is handling code+WYSIWYG, and the test set extended to cover this specific case.