Could libexec/arcanist/src/.phutil_module_cache just be a symlink to somewhere else?

Nix

Just for my curiosity, what lovely package are you crafting? APT? snap? Thanks :)

I accept but please wait at least one day before landing :) Thanks for your code contribution!

I'm inclined to accept this, premising that usually we adopt PlatformSymbols::getPlatformServerPath() but in this case that will not work since this error is very low-level about the load of Arcanist itself.

Thanks but I don't know where that typo is, so, feel free to fix

See e.g. https://www.law.cornell.edu/wex/release why to "license under" instead of "release in"

Triaging to "Unbreak Now!" so to be kindly shown in the homepage :)

I don't remember but that was an attempt to do not release Passphrase credentials as CC BY-SA 4.0 :D :D

Public contents are released in Creative Commons Attribution-ShareAlike 4.0.

Updated to reflect some tips from comments. Also added some "Pro / Cons"

+1 for CC BY-SA 4.0 International for content (text, images, etc) and Apache 2.0 for code.

git rebase master

There is a thing, to be honest. We are trimming the $above just in the test, but then we are not using the trimmed string in the rendering. So, the $v = coalesce($v, '') thing, and always trim() later, may still be better.

Maybe other people would like to propose a coalesce() and always trim() that and just have the if(phutil_nonempty...($)), but to be honest this is just correct and somehow minimal.

I tried browsing that page without being able to trigger the issue

Abandoning per last comment; guess we should debug a bit more first in downstream to understand the root cause better

This issue has been a pain for years. Never investigated it before...

Fix unit test

Lint & fix xml unit test

Not sure how to proceed here, this abandoning for now

Yeah feel free to review D2530

I still like this. Why is this not going forward? 😄

(I have not tried this patch but I checked with ls -la the mess in my .cache to understand best practices from other software)

• we have an approval from a core contributor
• we tested by at lest 2 persons in real-world
• we tested also in my production for 7 months, using this intensively, without any nuclear implosion
• nobody cares, really, nobody uses Milestones, nobody knows what a Milestone is, people also don't like Workboards, Workboards are evil persons for much core contributors, so we will never receive more feedback here automagically, if we have not received these in 7 months
• since this change is online since the 11st of February (!) :D and since I waited 2 weeks to be kind after approval, ...

Should I go ahead and submit a different patch? Or could I somehow contribute the edit to this patch?

So would the latter option mean doing $html_details = array($head, $more, implode(' ', $exceptions)); here? I kind of find this approach cleaner than appending a space to each item in the $exceptions array.

In D25419#12602, @avivey wrote:

The value of moreInfo here is a list (array) of 3 things, (https://we.phorge.it/source/phorge/browse/master/src/applications/policy/filter/PhabricatorPolicyFilter.php;4f845d8f8c77$702) - $head, $more and $exceptions, and I'm guessing from context that the appendList() creates one <ul> for the list and one <li> for each item in the list - so $exceptions at this point is a single thing.

I don't think we have a specific task for "general UI text improvements" - there's the UX project, but "improve UX" is an ongoing process, so I don't think a single parent task is a good match.

Interestingly: https://secure.phabricator.com/T10574 argues for removal of the additional data from edges.

... whereas the $html_details is constructed as merely array($head, $more, $exceptions); ...

For others reading this thread: there's some discussion going on in the thread of the patch linked above, D25419.

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.

It's also misleading that the text box is multiline (at least in desktop) which suggests that line breaks are expected, but pressing Enter instead sends the message. I was caught off-guard by this at least once. So perhaps the text entry box should be made single-line by default (as already happens if the screen is narrow enough) and expand as needed if line breaks are added.