Digging deeper, the problem is specific to ProjectRemarkupRule::getObjectIDPattern. That returns:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Dec 9
Thu, Dec 5
Sat, Nov 23
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".
Oct 25 2024
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.
Sep 16 2024
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?
Aug 5 2024
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.
Aug 4 2024
Jul 29 2024
Jul 1 2024
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.
Jun 30 2024
Thanks again @20after4 for the efforts.
Jun 29 2024
Jun 27 2024
(re-opening, there's more work left here)
Jun 26 2024
Jun 23 2024
May 2 2024
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.
Apr 30 2024
Or wrap a text with a background color - (something like What if I can change the background color here (and no italics)?)
Apr 29 2024
I'm somehow even more inclined to propose to base this feature on a new custom parser, like cowsay {{{ asd }}}
Minor clarification.
Apr 11 2024
Apr 2 2024
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...
Apr 1 2024
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.
Mar 26 2024
Mar 25 2024
Mar 19 2024
Mar 15 2024
(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...
Mar 14 2024
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
Mar 9 2024
Feb 29 2024
Added documentation in D25547: Diviner: Improve documentation for remarkup code blocks
Yeah enjoy this feature! Already part of our glorious 2023 Week 32
Hahah I guess I could have tested it first.
I think we already did - @valerio.bozzolan ?
Feb 28 2024
Gotcha. Probably this is generating the attachment transactions but should be "ignored on no effects":
This feature is not complete also for Conpherence AFAIK
Feb 27 2024
In T15743#15855, @valerio.bozzolan wrote:
- https://github.com/xemlock/php-latex (PHP server side)
Feb 26 2024
Interestingly, I just discovered Wikimedia has a pretty cool project to render math on the server side, by transpiling some js into php:
There is also MathJax, a subset of LaTex that only covers the mathematical notation without the page layout functionality.
Feb 25 2024
I see that it depends on a NodeJS external script (server-side).
This would be useful for discussions about design, specifically I wished for this feature while reviewing D25491: Improve contrast of Links in Dark Mode
Feb 7 2024
Jan 31 2024
Jan 28 2024
Jan 22 2024
Jan 19 2024
Values given in em units may produce unexpected results...
Jan 18 2024
Jan 17 2024
If it's only for a small number of such words, they should probably just be added to the blacklist remarkup.ignored-object-names - in fact, we should probably add S3 at least as a default; And probably find a way to expose this config option. Maybe a button on the Remarkup box that will help adding things to the blacklist?
Jan 16 2024
In T15712#15124, @avivey wrote:Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?
Looks like the tickets end in a Wontfix in https://secure.phabricator.com/T5301; I didn't follow the whole thing, but often the reasoning in Remarkup boils down to performance.
mm, see this one: https://secure.phabricator.com/T5301#211340