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. .

nice!

The move completed without errors.

Instances are moving now.

Deploying, then picking this up again.

FWIW we have seen several users attempting to distribute l33t w4r3z via Wikimedia's instance of Phabricator. I had to set file upload limits to < 8MB in order to prevent chunked file storage.

This sounds REALLY useful. Relatedly, it would be useful if I could auto-generate a task for each recurrence of an event.

I suspect some of those features have no actual use case outside very marginal nonsense like T12799, but they're "things computers should be able to do".

I want to get clear of T12798 first, but there are some other features I'd like to add to our search anyway, including:

@20after4's ears were burning

:(

(Specifically, if you update this bug should be resolved.)

I'm going to call this "resolved" since I migrated instances in T12817 successfully. There's followup work, but T12798 is probably a better point of consolidation for future work now than this task is.