My initial thought is that we should maybe just parse strings in various "almost certainly time" formats -- rather than adding a special syntax -- like:

I have made these changes to the planning document which are hopefully more clear:

Just to confirm, there are no plans to implement this within some timeframe, right?

Your options always are, pay for us to build is soon, or wait for us to naturally prioritize it. We try to "plan" as little as possible so we can be more flexible.

Sorry for the misinterpretation. Just to confirm, there are no plans to implement this within some timeframe, right?

That isn't what the planning document is intended to convey. I'll update it to make it more clear.

In T3725#145540, @epriestley wrote:

@polybuildr, please see Planning.

Interesting. Thanks.

Phurl (T6049) is still a prototype and not yet documented.

@epriestley in above comment you've used double parenthesis syntax ((text)). I can't find reference to it on the Remarkup documentation page.

@polybuildr, please see Planning.

Are there plans to implement this anytime soon?

The garbage collection simulator is good exercise for that I hear.

Haven't seen any more issues since rolling the server; I'll keep my eyes peeled.

Looks like maybe I got all the cases? Tables seem to work fine too.

(This is likely an example of the issue.)

@avivey: Thank you for clarification and references. I understand the rationale behind the changes, though, I still see that Phabricator still allows executing "trusted" binaries (whatever it means). Anyway, I could not find documentation on using extensions, so I'm not too sure about how to use tex2im, tex2png or similar programs in Phabricator's context. Perhaps, someone could point me to the relevant documentation and/or, better, share some examples for that approach.

@ablekh: quite a lot has changed in this front since April - see T9408: Upgrading: `dot` (Graphviz) support removed, changes to `figlet` and `cowsay`; in particular, we no longer consider "executing arbitrary binaries" to be reasonable approach for this kind of situation.

After reading the Contributing Code guide, it seems that I would have quite a high barrier of entry, should I decide to contribute to the project on this feature (upstream; normal process). In regard to listed alternatives, local fork is likely not a good idea for me and developing an application is likely not relevant to this feature, as, if I understand correctly, it should be a part of general/core code (i.e, Remarkup blocks for wiki). Therefore, the only feasible option (for enabling this feature on local install) that I could think of (additional benefit: this would be general, enabling LaTeX for any Phabricator's Web output) is to move the LaTeX-to-HTML on-the-fly conversion outside of Phabricator's code, specifically, as part of Web server request processing. For example, it could be implemented as a Nginx module or directly - via Nginx config - pass the output through KaTeX's server-side processing ("Server side rendering: KaTeX produces the same output regardless of browser or environment, so you can pre-render expressions using Node.js and send them as plain HTML."). Does it make sense? Please let me know what you think about all this.

@chad: Got it, thank you for the reference!

See Planning.

New kid on the Phabricator block here. Firstly, I just wanted to say that I thoroughly impressed by Phabricator and thank all of contributors you for producing such a nice piece of software. After rather comprehensive evaluation of existing tools (mostly open source), I have chosen Phabricator as a platform of choice for my initiatives on improvement of research and software engineering processes a materials science / materials informatics research group, where I currently work (Georgia Tech).

To move forward, we should split this into two tasks:

These cases aren't closely related.

("No time specified" in Phame is a bit odd too, but I think that's been fixed already)

I'm assuming that @terrismotox is just playing around.

Edited the task description to add problem description.

Understood.

I don't plan to support this in the upstream. This configuration is inherently dangerous because the custom application has access to Phabricator's cookies, and not one we recommend.

Sorry, I got it. I have to leave an empty line between youtube url and text.
Thanks.

How exactly are you embedding it?

Hi @joshuaspence I'm unable to embed youtube video in wikis. I've enabled remarkup.enable-embedded-youtube. But adding youtube link in wiki or adding youtube embedding html in wiki is not helping!

This also seems weird to me.

T5378 / D12692 also have some bearing here.

This should probably also wait for (or happen concurrently with / be considered alongside) the repository monogram changes which occur with T4245, although I think it doesn't limit the reasonable syntax available to us very much.

I think there's a reasonable chance we'll build a dedicated "Manual QA Workflow" / "Runbook" / "Preflight Checklist" application some day, but I'd guess not before 2017 unless things change a lot. If we had this application, you could embed workflows into tasks or other documents using {...} syntax and check them off as you worked through things.

@epriestley :correct me if Im wrong, the way of fixing this is searching in the file that describe code block ?
Then i look for code in $this->getEngine()->isHTMLMailMode() blocks and try to get it right ? Seems easy for color, a little bit less for the gap.

There are a couple of minor followups between this original announcement and HEAD which improve some behaviors, but this has been in stable for about a month now.

I think we always get that gap between the header and body in mail, too (even for non-counterexamples).

OK Thanks! Created T9538: HTML Emails which contain figlet and cowsay content should render respective code blocks in fixed-width font

Yeah -- at least in HTML mail, the cows aren't getting properly linebreak'd either. I don't think that's new but it should be pretty easy to fix.

@epriestley - I'm not familiar with how email should work (or how it used to) but I think figlet text (and probably cowsays) are not html-ized for html emails -- they might look better in fixed-width fontstyle but it looks like regular-type. Adding figlet text for test:

Regarding mixed-language environments (like sql appearing in a python script), most editors would simply look at the file extension and highlight the entire file in that language (in our example, python.. and the inline sql might appear in the color of a string).

Wow, that was quick. Thanks!

Also note that remarkup has a parser cache, so older mentions won't automatically be fixed right away (the bad parse is cached).

I think D14186 will fix this. Let me know if you catch anything else wonky after that lands -- I got some indirect test coverage on this, but might need to go beef things up a bit if I missed something.