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.

(I've put a note in Dependencies for now)

Updated Pygments with pip to 2.17.2 und cut the time in half. So yeah, that's already an improvement.

I guess we could also try to cache the individual rendered code-blocks.

Well, good to know that it is not something in the phorge codebase. Our server has pygmentize 2.14.0 - but the server itself is really not the best, so that could be an explanation. Maybe we could make some remarks about performance and keeping the versions fresh on the diviner page...

Update: I've installed pygments (2.15.1), and it took about 3 seconds to render. It takes about 14 seconds here (with pygments 2.3.1).

mm, dumping this file in my dev env renders pretty much immediately; that's a good sign that it's the code blocks, because (1) pygments is known to be slow and (2) I don't have it installed.

I'm quite sure the problem is limited on repeated code blocks.

"slow remarkup" often boils down to 1-2 inefficient regexp in a rule somewhere.

Can reproduce

Added documentation in D25547: Diviner: Improve documentation for remarkup code blocks