Set new action

I think we have it documented somewhere that "we have developers who refuse to learn git" is considered a bad reason to ask for a feature, and you should maybe consider solving this issue with some workflow changes.
Note also that in your link, epriestley says

In projects which do not linearize history with arc land + squash merges, I believe this feature is virtually useless because many commits are merges and visualizing the repository isn't very informative (the history has so many parent/child relationships that none of them convey much of anything).

I'd like the commit graph to come back in some form -- looks like it was removed in rPc5bb69fd7d79. For the reasons @epriestley outlined here: rPf2fcafb40dde#38208, this view is really useful for visualising the relationship between Git branches and sanity-checking recent merge commits. These are tasks that would otherwise require something like gitk.

Thanks @epriestley, that fixed it indeed!

Two questions pick at me:

1. Which editor did the user use to add the ZWS in? Any editor I remember does something to warn you about it.
2. Why are there Unicode characters for "goat" (🐐) and for "cooked rice" (🍚)?

T929 is probably the earliest request for this feature :)

I moved everything except one test instance off in T12817, and we appear to be ready for this host to die.

This has landed for anyone who wants to provide feedback on the v0 version.

I believe this should now be resolved in HEAD of master. Let us know if it doesn't work for you or if you're still seeing issues after upgrading. Thanks for the report!

No one has complained that all their data is gone so I'm going to assume the best here.

This is not a configuration problem, and you can't fix it by changing configuration. D18119 should fix it.

Beautiful. Sorry for not finding that.

Presuming resolved by T12757 (May 25).

Sorry, just pulling that out. 4d2c7e4d3d5d61e34b7e2af3df0e901d89d29433

Version?

In D18112 I've marked 3 items as done (unsubmitted), but the header bar is still white, my expectation is it turns yellow.

These are the cheapest days to go.

Not exactly related, but these cancel buttons used to be grey and are now blue:

Some other general thoughts:

Well let me actually re-read everything then.

Sorry, I guess I'm being unclear: I don't believe that (1) is a reasonable starting point.

The flag color system seems like overkill though, I wonder if we can simplify that.

I'm agreeing that (1) is a reasonable starting point.

I think maybe we're talking about a couple different things? These are both relatively easy:

Have flags as an automatic search filter then like projects?

have a flagged filter automatically everywhere

Maybe also, in general, we could define an "explore by tags" view, that works something like this:

Flags is something I definitely thought about, since it's already everywhere. If it integrated with applicationsearch (have a flagged filter automatically everywhere) I think that's reasonably handy and easy to build UI upon.

Constructively, some adjacent changes which are maybe worth considering instead:

The requests I've seen seem like users want this done automatically/by default, not that they want better tools to do it themselves.

On a purely personal/aesthetic level, the box-drawing character block is total garbage and master ASCII artisans would never use it in serious work. A true connoisseur of the craft should accept nothing more than single-byte ASCII range in their collection.

See some related discussion in T12822. In particular:

me too but not everyone is on our level

FWIW I only code via copy/paste.

• T2495: Improve whitespace expansion of tab literals is somewhat adjacent here.
• T11632: Display invisible characters on erroneous user input is a little related: if we generate canonical lists of "invisible" characters in UTF8, they should probably be shared by all three of: the code that detects when input in forms is invalid because of invisibles; the future UTF8-aware invisible mode; and the UTF8 text linting mode described in T11150.

Per above, these are already detected by the Text linter:

See also T4124 for another Solaris issue.

https://secure.phabricator.com/conpherence/1336/#42940

Let's do both!

Maybe every object should allow a cover image then?

I think that ArcanistTextLinter actually checks for ASCII right now, so it should be easy to enable for this case. See also D6050, which discusses selecting encoding for it.

also, T8407 maybe fits here? I think it's mostly a UI issue now.

well script-and-regex is NOT anything complex... or you can try and add zero-widht-space as a rule to arcanist Text linter or make own linter extension... anything is good ;)

Anything programmatically detectable should be raised through lint. Asking humans to detect it is still likely to not solve the core problem since they'll always be less reliable. .