Strings like @mentions aren't always live in a remarkup block.

What if we allow an autocomplete to work in code blocks? It doesn't seem harmful, since on preview user will see what's actually been detected as mention (or commit, etc.) and what wasn't.

@spicyj, this might also be up your alley. Rough state of the world:

• We need some code to do the purely mechanical front-end bits, like finding the pixel position of the cursor in a text area across browsers.
• We need some code to do the UX state management unique to this input mode (e.g., figure out when to issue a query, when to hide query results, etc.)
• We need some code to guess whether we should activate suggestions given context in a remarkup text block -- for example, ideally we should not pop an autosuggest if you're inside a code block. The simplest version of this is "always activate", but covering at least a few of the most common cases (like code blocks) seems desirable.
• We have code (JX.Typeahead) to draw some of the auto-suggest UI, but it's probably coupled fairly tightly to the existing controls and I'm not sure how reusable it is.
• We have code (JX.TypeaheadDatasource) to issue queries to the backend to get autofill suggestions. This also isn't perfectly abstract, but is probably in better shape for reuse than the rendering code.

Even without connecting to the datasource, building the first two parts of this would be significantly helpful in getting the feature built. For example, the disconnected version of this feature could look like:

• After the user types "@" or "#", a floating thing appears underneath the cursor.
• The widget thing just fills with the text of the query we would otherwise submit for suggestions, e.g. if you type @abcdef it would just say abcdef.
• To the greatest degree possible, activation respects reasonable UI rules (dismiss on escape, dismiss when the cursor moves outside of the range, try to handle copy/paste reasonably, try to handle selections reasonably, react in some plausible way to up/down and left/right, etc., etc.)

That would cover 90% of the complexity/unknowns, and I could hook up the actual datasource stuff from there pretty quickly.

ohhhh @spicyj this would be awesome. like we'll send you a Phabricator T-Shirt awesome.

We already sent him a shirt!

Need a design?

How about using tab completion to trigger the popup so that it doesn't have to be intelligent about when to pop up the list of names.

Are there plans to implement this anytime soon?

@polybuildr, please see Planning.

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

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

Interesting. Thanks.

In T3725#145540, @epriestley wrote:

@polybuildr, please see Planning.

@epriestley, I looked through the FAQs as well as the Roadmap and Starmap. I couldn't find any mention of Remarkup in either, so I'm assuming that implementing this isn't on the timeline as of now?

There seem to be quite a few people interested in this (though I don't really have much of a metric to compare against) and this is a pain point when a lot of new users keep joining and we have to manually type long, unwieldy usernames.

As the Planning FAQ says,

We're heavily driven by user feedback, and often change our plans in response to it

Please please do this? Pretty please?

Also, one of the developers on our team expressed interest in maybe giving this a shot, at least for our install. Would you be open to contributions from a newcomer for this?

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

Would you be open to contributions from a newcomer for this?

No, this task is too complex for a new contributor to implement successfully.

Sorry for the misinterpretation. 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.

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

Specifically, here's the answer to this question, directly from the planning doc:

Q: When will you build (some feature)?
A: We don't know.

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

First, I added this question to the FAQ section:

Q: Are there other ways to get features built sooner?
A: No. The only way to affect the priority of an issue is to pay us.

Second, I rewrote the "user feedback" to emphasize problems and use cases. The new text reads:

We're heavily driven by our understanding of problems and use cases, and often change our plans in response to changes in this understanding, but can not always anticipate how users will receive or interact with a feature before we build it.

This thing is going to have a decade of bugs.

well I do enjoy when @putnam stops by.

What are some of the things you anticipate?

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.

For example, there is currently a bug where you type abc def, then put your cursor before the space before d. You type @eprie, so the string reads abc @eprie def, and you have an autocomplete suggestion for @epriestley. Now, you use your cursor keys plus shift to select pri and press the q key to replace the text, so the string reads abc @eqe def. The typeahead now incorrectly searches for the query eqe d, because I haven't written a bunch of code to try to track when users do this yet.

Have typeahead autocomplete @epriestley despite what the user types~

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.

Autocomplete in textareas is a huge PITA and doesn't work right in any implementation I've ever seen, including FB mentions (although one-word Phabricator usernames will be much easier to resolve than full names).

I know this isn't really helpful but I felt compelled to leave a comment after Chad effectively handed me the talking stick. <3 u boyz

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.

This is now live on this install.

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

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

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

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

@chad Thank you for quick clarification.