we'll get to it when we feel like it (ok not a totally fair paraphrase, but it's one way to read it)

Unfortunately we have 1,500~ish tasks between 2 developers and we do our best to build things that we think we have the largest impact (which tends to mean small quality of life stuff doesn't happen as often). We'd love to bring more people on board to help improve Phabricator faster, but that means being evil and chasing money first to make that happen.

I guess I was hoping for a timeline. Or an explanation of why it's hard
and not done yet. That page seems to me to say "we'll get to it when we
feel like it" (ok not a totally fair paraphrase, but it's one way to read
it). Waiting a year for a minor feature that would drastically improve one
of my workflows just makes it feel like you guys aren't being very
responsive to feedback about how the UI could be made better. And I have
plenty of other complaints about the ui - just haven't bothered filing most
of them.

Perhaps helpful for context is T6027, which was open for longer than this (about 18 months).

What isn't helpful about it? I believe it has a complete answer to your question, and a great deal of detail explaining why that's the answer. How could it be more helpful? Did I misunderstand what you're asking?

that was not a particularly helpful response

See Planning for information on timelines and progress.

Any updates here? This task has been open for over a year now and it's something I wish for approximately weekly.

We should probably have it to fix T8135 anyway, I was just planning to cheat through that but definitely can't cheat through "Group By: Assignee".

oh. sorry. :(

I've spent about 8 hours on this today and made nearly zero progress.

@chad Thank you for quick clarification.

it's on master today and stable likely on Saturday depending on what branch you track.

@spicyj Good idea, thank you for the advice :-). I just wasn't sure this feature is in production...

@ablekh Have you tried Googling for "how to update phabricator"?

How do I get this feature? System update? If Yes, please point me to documentation, describing the update process. Thank you!

I'm going to call this resolved and move errata to T10163, since I assume most people on this task mostly just wanted to know when the feature landed.

This is now live on this install.

Yeah -- we may be able to cheat a bit on usernames (although "@Evan Priestley" should also work), but can't cheat on project completion with # since #build more pylons and #build more supply depots should retrieve different results despite having a shared, multi-word prefix.

Oh hi @chad! Er, wait, I don't get any autocomplete love over here so I can't judge it one way or the other.

Have typeahead autocomplete @epriestley despite what the user types~

Mostly, users have a huge number of ways to interact with text: cursor keys, mouse, home/end keys, keystrokes like Ctrl+A and Ctrl+E, cut, paste, all the mouse-driven varieties of cut/paste, context menu actions like spelling correct, shift + everything listed so far to select stuff, dragging selected text, and multi-keystroke character input for non-latin languages. Javascript provides only indirect ways to guess how the user has performed mutations of the textarea, so we have to reconstruct and/or guess about a lot of behavior.

What are some of the things you anticipate?

well I do enjoy when @putnam stops by.

This thing is going to have a decade of bugs.

Reading Custom Fields is now supported in new *.search endpoints (paste.search, maniphest.search, owners.search).

Broad update here after T9132:

I have made these changes to the planning document which are hopefully more clear:

Just to confirm, there are no plans to implement this within some timeframe, right?

Your options always are, pay for us to build is soon, or wait for us to naturally prioritize it. We try to "plan" as little as possible so we can be more flexible.

Sorry for the misinterpretation. Just to confirm, there are no plans to implement this within some timeframe, right?

That isn't what the planning document is intended to convey. I'll update it to make it more clear.

In T3725#145540, @epriestley wrote:

@polybuildr, please see Planning.

Interesting. Thanks.

Phurl (T6049) is still a prototype and not yet documented.

@epriestley in above comment you've used double parenthesis syntax ((text)). I can't find reference to it on the Remarkup documentation page.

@polybuildr, please see Planning.

Are there plans to implement this anytime soon?

Fixed by D14527.

@avivey: Moving to a scalable SVG is probably a better long-term solution than the multiple sizes of apple-touch-icon Phabricator already has to support!

It chooses an A for your default icon because pinned tabs are per domain, not per subdomain.

why can't they use a favicon like everybody else?

In T5793#108195, @epriestley wrote:

If anyone does this, I'd be interested in feedback on how it goes.

This probably now also blocks on T9132.

I think T9132 is the most promising approach for reducing the complexity in exposing transaction writes in a general way.