Digging deeper, the problem is specific to ProjectRemarkupRule::getObjectIDPattern. That returns:

Step 2: Remove irrelevant character class exclusions:

Disentangling that monster regex, step 1:

Indeed https://devina.io/redos-checker says the aformentioned regex is exponential time worst-case

I monkeypatched the code to print preg_last_error when the problematic preg_match returns null. The error is "Backtrack limit exhausted".

This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.

Taking the best from the two: what about assuming a default @link /book/group/best-document-ever-about-link - but still allowing custom @link to allow easy migrations?

This is an issue in https://we.phorge.it/source/phorge/browse/master/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php . In getObjectEmbedPattern(), preg_quote($prefix) returns \# and the method finally returns (\B{\#([^.\s?!,:;{}#\(\)"'\*/~]+(?:[^\s?!,:;{}#\(\)"'\*/~]*[^.\s?!,:;{}#\(\)"'\*/~]+)*)([,\s](?:[^}\\]|\\.)*)?}\B)u.
Within apply($text), $text becomes null after that first preg_replace_callback, so the second call barks.

I think GitHub allows that syntax only in comments 🤔

In T15744#18236, @20after4 wrote:

I was unaware of `#0969DA` syntax from github/gitlab.

I was unaware of #0969DA syntax from github/gitlab. I'm not sure if I like that syntax better than {} but I am generally in favor of using the same syntax as other systems in order to converge towards defacto standardization.

Thanks again @20after4 for the efforts.

(re-opening, there's more work left here)

To implement this, you may want to start from this 🌈

Anyway, even with this fix, for some reasons I can't still use this feature with a comment like {#0000ff} in my local installation 🤔 I'm confused since the unit test works.

@valerio.bozzolan yes, just now. I have only realized that there is a fix already after opening the ticket raised as a concern. Hadn't checked this in the past few days, so here I am, finally with my account approved and the issue is fixed. Thank you. :)

@zajdee have you already tried to update to latest master? After 6ab2b56a1a4a6 I mean. Thanks for this confirmation

EDIT: This was already reported and resolved in T15802: Regression: HTML entities rendered as plain text in config option descriptions, I'm keeping the comment just to track this.

Or wrap a text with a background color - (something like What if I can change the background color here (and no italics)?)

I'm somehow even more inclined to propose to base this feature on a new custom parser, like cowsay {{{ asd }}}

Minor clarification.

Well, you know what would be next level for a dev? If (s)he clicks on it, the color is copied to the clipboard. We can't use this behavior, because behaviors loose their state in the remarkup cache...

This D25540: Add PhutilRemarkupHexColorCodeRule, a new remarkup rule to format color codes should be ready to merge now, if someone wouldn't mind reviewing it.