Macros are being shown unexpectedly

Observed Behavior:
We have a macro on our install which is a somewhat common word within the company. Normally this is fine because it is rare for this word to appear by itself on a line unless the user intended to show the macro. It seems, however, that the macro is firing in some other cases, which we didn’t expected (and I think it didn’t use to work this way). Specifically, [] macro_name and - macro_name are rendering the macro.

Expected Behavior:
I expected [] macro_name to render as <li class="remarkup-list-item remarkup-unchecked-item">macro_name</li> and - macro_name to render as <li class="remarkup-list-item">macro_name</li>.

Phabricator Version:

  • rPedda40aa3b931ed064c52536af5b65fd6611e841
  • rARC4d22e0f89f10b8a7f47f6ee615e0ccf0f354e582
  • rPHU3e6a9946bcfc39591dbd9a571d1f56c8c27d4a0a

I can also reproduce on https://secure.phabricator.com

Reproduction Steps:
Type - abandonmemaybe into a comment box on https://secure.phabricator.com.

I think this is currently expected, and how things have worked for a long time.

The documentation says “any time you type [the macro string] on a separate line it will be replaced with the image of a dancing banana”, but this isn’t really exhaustive because the actual rule is slightly more complicated.

The actual rule is more like “when a macro name is the only non-whitespace text in an inline subcontext”. So this produces a macro:

shiba

…but so does this (leading whitespace, not implied to work by the documentation):

  shiba

…and this (quoted text):

> shiba

…and this (macro in a table cell):

| shiba |

I think these are probably all expected/desirable.

But this rule also means that - shiba, [ ] shiba, [x] shiba, and # shiba produce macros.

These are probably not desirable.

I’d ideally sort of like to get rid of oneword macros as a supported syntax (it’s somewhat common for installs to struggle with policing macro creation of common words, even with the modern restrictive ruleset), but I don’t really see a clear path forward on that that doesn’t make everyone unhappy.

It would probably be reasonable to narrowly disable macros inside list items to solve this specific problem, but I’m not thrilled about that because it’s a narrow fix to a symptom of a broader policing / syntax-is-inherently-too-easy-to-trigger problem.

I must be missing something, but the regex in PhabricatorImageMacroRemarkupRule is ^\s*([a-zA-Z0-9:_\x7f-\xff-]+)$, which should match shiba and shiba, but not - shiba or [] shiba.

Block rules are applied first. ListBlockRule matches - <anything> and [] <anything> and # <anything>. TableBlockRule matches | <anything> |. QuoteBlockRule matches > <anything>, and so on.

Inline rules are applied to the <anything> inside each block, after the block markup is removed.