Although maybe that's talking about REST specifically. Unclear from context.

Some guy who authored HTTP or something here suggests this is legal but non-useful:

I have half a diff for this (D10530) that I cab probably finish off. The main issue I had was with signing the requests and also the difficulty associated with testing.

I haven't been able to make any progress on this.

Presuming resolved by D11115.

Closed by commit rPHU20446fc6b6ac.

Closed by commit rPHU9319f6d50d52.

+1

I'm inclined to maybe do away with it and just use new FutureIterator() explicitly everywhere? We don't really have that many callsites.

Unfortunately nothing comes to mind, and without a repro case, it's a bit of a fishing expedition on our side (and not likely worth the time). Feel free to reopen with more details if you can build something consistent.

I believe the check for TERM should be fine. However, for reference, the Symfony framework uses a slightly simpler check - and will probably behave saner in most of these cases to do go wrong.

In my windows term ("git-bash", term=cygwin), I get the ←[1m when normally invoking arc, but piping through cat (Which I would expect to drop all ansi-ing) makes the colors work:

Here's the code we currently use:

I don't think I am seeing this any more.

Closed by commit rPHU160eeba602bf.

Closed by commit rPHU2de64405cfdf.

just...so awful

• Find phutil_utf8_shorten() callsites in Phabricator and Arcanist.
• Replace them with PhutilUTF8StringTruncator. Use:
  • Byte limits for things like email.
  • Codepoint limits for things like database columns.
  • Glyph limits (current behavior) for display strings.
  • Multiple limits if there are weird special cases?