Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Since I can, thanks to that revision, at work I've put this additional CSS rule for extra nonsense scary climax.

I had communicated these upstream (almost exactly a year ago~) and some helpful information was provided

Note: the <ins> tag is typically rendered as underlined text, so this would be very similar to the <u> formatting that is produced with __foobar__ → foobar. In fact, it might be worth repurposing that rule to produce <ins> instead, since ~~foobar~~ actually creates a semantic <del> tag rather than the presentational equivalent <s> (strikethrough) tag.

Ugh. I added this to the UX project but forgot to remove the test content from the comment box, so my changes ended up coupled with a comment that said "- List Item". I tried to delete the comment but now it looks weird like some sort of redacted content :( anway, though I'd leave the note here in case anyone is confused with the deleted comment.

While it could be nice to have this, in the meanwhile I think that having something minimal like D25434 would be nice

• Automatically continued bulleted list upon new line

Should this be documented here? I think yes

Workaround 😎

(The file F315310 is not public)

Interestingly, it works ._.

Interestingly, Remarkup allowed too many things, so this Task cannot be 99.99999% safe.

Please describe the thing using 3 backticks like in this comment (see raw remarkup)

I think the current revision is a good compromise. The current behavior makes no sense from the perspective of modern UX patterns:

In T15161#4416, @avivey wrote:

I agree with this, but I think we should let this wait for broader discussion - there maybe good counter-arguments.

Another use case: Drag & Drop on a new Object description, even if the Object is not already created, should attach by default to it.

I think a more generic solution here is "Make the Remarkup Help Page Extensible", so that Remarkup rules can add their own sections (Possibly under the Guides application, if it still exists?)

Premising I am trying to make few variations to the current behavior implemented by Evan

You are the best, thanks for this tip

Thanks a lot!

By the way you are now a Trusted Contributors :) Thanks

Ah nice thanks @smith - feel free to move that as Answer

You can do it using HTML tags and literal line breaks, like this:

But you probably already know that, given that the task you quoted was closed by committing this revision.
(<br> doesn't work here, but I think it should, even if it's ignored in plain Remarkup.)

There’s possibly other reasons why they left it undocumented but it was a while back and I haven’t gone digging in the upstream for details.

Historically the reason why these aren’t documented is that they originally required installing 3rd party tools on the server. They were documented in tasks upstream but there was a security issue found with using graphviz so at that time out of caution they reimplemented figlet and cowsay in php rather than passing arguments to a 3rd party executable. After the implementation change documentation was never updated.

Discovered from D25142

(Sorry for the ping poing, re-adding Remarkup hoping to be useful since this seems an issue in Remarkup itself, but last word to avivey)

Premising that very probably a fix there would not 100% resolve that upstream issue but surely this deserves a fix :D

Hi @Dylsss thanks again for your improvement. Have you any idea about why that message happens?

(Ignored unrelated build failures, see fix: D25133)

Rebased and applied suggested changes

In D25052#4102, @Dylsss wrote:

I reverted to a previous commit (36dba82224de1b64bf571ebae5e944ce8a02e7c2) and still get this error when uploading from the remarkup toolbar upload button. So I don't think it is related to this change.

In D25052#4034, @valerio.bozzolan wrote:

WARNING: After this change, in my JavaScript console I can see this exception: Error: JX.DOM.scry(<yuck>, ...): first argument must be a DOM node. - I do not understand a shit about Javelin so I really don't know what does it mean

In D25052#4020, @MCPCN wrote:

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

Amazing @Dylsss you have green light here. Feel free to land.

In D25052#4020, @MCPCN wrote:

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

Using the upload button has different behaviour to drag&drop - files uploaded using the upload button need to be manually attached to the object which is a bit of a faff (not sure if there's a way to automatically do this?):

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

I start triaging this to Normal priority since this problem creates situations that don't happen with many proprietary weird alternatives like Trello, Asana etc., where their Drag & Drop "just works" since their file are always visible to all members and so it's considered as "working" for their end-users (well, thanks to the fact that Trello etc. have a terrible permission management system, thousand years back from Phorge, and they really have no concept of "single file permission", and so they win easy in these confrontations where the user expects something basic and it doesn't happen as default by some of our "attach to something" corner cases).