I think ponder is sort of a minimal viable product state currently. It lacks some features like putting questions on workboards and there just aren't many
(or any?) integrations with the rest of phabricator. That wouldn't take much effort to improve it, most likely.

Also apologies for not testing this locally, I was far too confident in my TDD.

man I didn't even consider that you could actually have a valid project named #0dba11 ... maybe the syntax should be something different. #{00ffff} perhaps?

It's kind of a shame that remarkup wasn't named Pharkup.

Actually add the rule to the remarkup engine.

LOL I only ever tested the unit test case. I forgot to add the rule to PhabricatorMarkupEngine:

In T15670#15501, @avivey wrote:

Thinking more, I think we'd like to allow the robots to index latest version of the code - these days the big boys know how to handle that. Stopping them from crawling older versions is still important.

Anyway, I vote to revert the change - commit pages can have discussions in.

If it's that easy, then I'm both impressed and surprised it remained this way for so long. I'm actually not quite sure I understand the reasoning for not using # to begin with.

Address review feedback:

I'll test this locally, I can't see any reason we shouldn't merge it.

This should be ready to merge now, if someone wouldn't mind reviewing it.

Discussed on IRC: it seems that this should have been POST all along.

In D25540#16124, @valerio.bozzolan wrote:

About your Remarkup unit tests, try to rebase. Maybe related to D25559.

• Fixed a logic bug.
• Added passing unit tests.

So I got this mostly working locally, it's actually fairly trivial to reuse the existing token storage and infrastructure. Actually displaying the tokens might not be the most efficient of operations when there are a lot of comments on a given object. I still need to write an optimized query to fetch all of the token given in one query rather than many and then figure out how to display the tokens inline with the comments.

@littleggghost I think you might just need to run celerity to update the icons.

This is really cool!

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

Awesome! I'm glad it finally worked. If you want all of your tasks to have the 'deadline' subtype you can edit your task form to set the subtype (or create a separate form that sets the subtype) that way you don't have to manually change the type of each task after it's created.

Did you manage to get the extension working?

You still need the wikimedia extension at least for now. The screenshots just show how to change the subtype of a task and then shows the due date icon. I just changed the permissions on the attachments, maybe they work now?

@littleggghost: Yes after applying the patch to phorge master branch I can see the icon.

confirmed, that warning makes no sense.

Hahah I guess I could have tested it first.

This looks correct to me:

I agree, badges seems like the right way to go. They are an underutilized feature really, IMO.

@littleggghost So it turns out that in order to enable this feature, there was a patch to Phabricator core. That patch isn't part of the wikimedia extension, and hasn't been merged into phorge.

@littleggghost one thing you might want to try is updating the celerity map. You may be missing the custom css rules to style the deadline appropriately. I’m not familiar enough with the phorge docker image to be able to tell you exactly how that is accomplished. With non-containerized phorge instances you would just run bin/celerity map from within the phorge root directory.

In T15743#15855, @valerio.bozzolan wrote:

• https://github.com/xemlock/php-latex (PHP server side)

Interestingly, I just discovered Wikimedia has a pretty cool project to render math on the server side, by transpiling some js into php:

I went down a rabbit hole while trying to add unit tests for this. Our core remarkup unit tests are pretty thorough but they only seem to cover the "core" remarkup engine and syntax. When I added a new test case for this it would pass but always caused a different test case to fail in weird ways. I haven't yet figured out what part of the unit test or engine is stateful such that my unit test alters the state in a way that breaks a later test. If I change the order that tests run in, it just causes another different test case to fail.

Fix lint again

fix lint.

Added contrasting color calculation

There is also MathJax, a subset of LaTex that only covers the mathematical notation without the page layout functionality.

This is not yet tested.

fix lint error.

This would be useful for discussions about design, specifically I wished for this feature while reviewing D25491: Improve contrast of Links in Dark Mode

In T15719#15304, @Tgr wrote:

Given how it's displayed on the Gmail UI, IMO unsubscribing from all emails or at least all emails of the given type (e.g. all Maniphest emails if it's a Maniphest notification) is the only thing that makes sense. If I mark an email as spam, and then use the unsubscribe option instead, I would not expect to continue getting identical email from all the other tasks.
No idea how (or if) other email clients handle the header, though.

In D25491#15482, @Iniquity wrote:

Hello! Are you sure changing the links color is a good idea? Perhaps we should just make the background darker?

The only progress I've made is to think through the implementation but I haven't actually started coding on it. It is sort of high on my wish list so I may get to it soon.

I agree, disabled users should be hidden in the global search typeahead results.

In T15736#15681, @bekay wrote:

• Get rid of the JX namespace and the the require comments - use import and export like it is done in modern js

In T15673#15587, @valerio.bozzolan wrote:

TRUST ME - YOU DON'T WANT TO LISTEN MY ENGLISH :D :D

Btw now the video is here :D :D AGAIN SORRY PHORGE FOR MY MISTAKES <3 <3

Nice, you touched on most of the advantages of Phorge. It really does have some strong competitive advantages.

From my perspective, on Linux, Phorge already supports configurable fonts - that is, none of the specific typefaces mentioned in the phorge css actually work, so it falls back to whatever I set as the default document font in Gnome.

In T15630#15574, @sirocyl wrote:

CSS is rather flexible now; a larger font scale can be specified for displays above a certain horizontal resolution or display width/effective character width, nowadays.
Atkinson looks poor at the font size specified, you're right about that @bekay.
I feel like it might need to break out into another task item, but perhaps CSS modernization is imo a good step towards making Phorge more compatible and capable, on screens both small and large.

When I was at Wikimedia I remember a lot of issues from search robots endlessly indexing dynamic pages.

Interesting that gnome is considering Inter. Recursive looks really good too. I like that it has both monospace and proportional all in one.