I think my analysis of the blur thing wasn't quite right, I'm still getting intermittent success with clicking results. I'll dig into that a bit more.

That appears to be working better, now.

I can't break it with 30 seconds of attempt. Wonder what @joshuaspence will find.

I heard @scp is also good at breaking things.

(This seems to work really well for me, btw)

One thing I've done differently than, e.g., Facebook is that I've made summoning the completer explicit (when you type "@" or "#"), not implicit (when you position your cursor somewhere in something that looks like a username in the text).

For example, in Facebook's implementation, if you type @chad abc def ghi jkl mno pqr and then use the left cursor key to put your cursor back over @chad, you'll get a suggestion. I don't particularly like this behavior in Facebook's implementation because my experience is that it tends to pop up the completer UI when I don't want it while editing text (that said, I think it's a reasonable and probably-correct implementation for Facebook).

Instead, here, "@" or "#" summons the autocompleter explicitly, but if you dismiss it you won't get another prompt until you type "@" or "#" again. (For example, @epr + escape + ies does not put you back in an autocomplete state -- pressing escape dismissed the completer you summoned by typing "@".) This generally feels good to me, so far.

Ok, here's what just happened on my initial test run:

1. Went to try out the feature and typed @epr, but then pressed up instead of down, dismissing the typeahead results without anyway of getting them back. (Luckily I remembered "i before e, except after c" so I was able to finish it myself.)
2. I went to comment about that fact, thinking it wasn't what I would have wanted, and mentioning @chad in my comment, and then realizing that the typeahead just adds text (not links like Facebook), which made the loss of the typeahead less of a deal.
3. Then I went to make this comment and had to dismiss the project typeahead with every line.

(1) is currently intentional -- I'm being pretty aggressive about throwing the prompt away, and dismiss it if you use "up" or "down" to get off the ends of the list, under the assumption those actions mean "throw this away, I hate it". I'm definitely open to changing those to just eat the inputs.

(3) is super silly, I'll fix that.

Seeing as how you don't need to select a result for the mention to work, the inability to get the typeahead results back after dismissing them isn't that big of a deal either way, imo.

Not sure if rP2d495e97014d made it on this install, but typing two # in a row still tries to autocomplete. Should it be dismissed if prior text is # as well (for headings/sections)?

Some nuances I've tested:

1. Typeahead starts when preceded by ., -, (, |, #, @
2. Typeahead does not start when preceded by most other characters including ', ", ?, ,, /, {, }, [, ], ), :, >, < +, _, ;, !

This feels mostly correct though it causes typeahead to not trigger for (probably) uncommon cases:

• >: Naming someone at the beginning of a quote

@chad found a ruler

• /: Wanting to italicize a mention

@chad

• !: Manually putting together the start of a noted-quote >>!, or highlighting

@chad is aloof:

@chad over here!

• :: Forgetting a space for making notes/warnings/importants

These seem inconsistent but are around punctuation which is anyone's game

• .@chad will trigger but ?@chad, :@chad, ;@chad, '@chad, "@chad won't
• (@chad will trigger but )@chad won't

After typeahead appears it seems most characters are fair game for search. I don't know what restrictions are in place for username/real-name/project-tags fields but right now this feels a little off to me

• , ( do not end the typeahead, so when writing something like @chad said the brown dog was smaller or @chad(Chad) the typeahead stays up the entire time unless I hit escape
• @chad(Chad) or @chad (Chad) retains typeahead, however selecting will replace with @chad losing the parenthetical - I could see this being an annoyance in some cases.

Typeahead starts when preceded by ., -, (, |, #, @

Yeah, some of these are intentional. - is intentional to allow for this:

These users still need to turn in their permission slips:

-@chad
-@epriestley

( is intentional to allow for this:

This seems like a good idea to me. (@chad, do you have any thoughts?)

| is intentional to allow for this:

@chad	Chad Little	Designer
@epriestley	Evan Priestley	Engineer

. is intentional to allow for this:

These users still have not turned in their permission slips!!
1.@chad
2.@epriestley

Particularly, here's the complete list of prefix characters we currently accept:

case '<start>':
case ' ':
case '\n':
case '\t':
case '(': // Might be "(@username, what do you think?)".
case '-': // Might be an unnumbered list.
case '.': // Might be a numbered list.
case '|': // Might be a table cell.
  // We'll let these autocomplete.

In all cases, I figured that it was more likely that users were trying to do the above than anything else, since it seems unusual to type, say, .@ in any other context.

## and @@ aren't staring the typeahead, but are failing to disable it when the user almost certainly does not want to use it. I'll add them to the list of characters which disables it (currently, that list is only space).

The >, : and ! cases are reasonable, I'll add them.

I'll add a list of "characters which immediately deactivate the typehaead if they appear anywhere" to try to address the other case. I'll probably fix # and @ under that rule since I think if you type @abc@ we can pretty safely guess you don't want autocomplete.

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

In T10163#154322, @epriestley wrote:

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

Oh, nice.

Do you think that's preferable? I think it's probably much better for experienced users, but I'm a little worried some users will type a #, sit there, then tell us it's broken if we do that.

From a design POV I see typeaheads as "Search", not "Browse". They should have some idea when they did @ or # what they were looking to link to.

But maybe it will feel weird, since I don't think most inline typeaheads work like that. On github as soon as I hit @, it pops a typeahead with you at the top (presumably, you're the commit author?)

Let's try the less-annoying way and see if it actually causes problems, it's definitely the behavior I would prefer personally.

(We could go even further than that and not show it until we have some results, but that seems maybe a little too extreme and probably won't matter on this install, at least, since nearly every prefix is going to match some user.)

Another errata is when the typeahead appears off the page and you have to scroll. In Conpherence it, uh, scrolls the main header off the page.

@epriestley - Sorry, was just noting the different cases while testing -- most of the 'prefix' ones I gather made sense for the exact reasons you described. The only change I would prefer is if space also dismissed the typeahead - if completely ignoring typeahead it feels like it's in the way.

That'll break @evan danger priestley and #differential mobile unbeta. I don't really see a clean way to resolve that based on spaces-typed, since both human and project names may contain an arbitrary number of internal words. We could put some artificial cutoff (three words? maybe four or five for projects?) but I don't immediately see a way to write a rule that always does what you users want.

Maybe we can do this:

• when a user completes a word by typing a space (or other punctuation), force a query for the token so far;
• if there are zero matches, hide the autosuggest.

Then it would stick around as you typed @zqwefoiqnfemfd (some string with no matches) until you hit space, and stick around through @epriestley xvnoinoandsonaf until you hit space.

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

That would change your case of @epriestley xvnoinoandsonaf having autosuggest stick around though.

I haven't come across any mousing issues, though right-clicking an item will select it, and clicking the top header will hide the autosuggest. Neither of those seem like significant details.

Alright, all that stuff is hopefully fixed/improved now:

• D15035: We now activate after >, : or !.
• D15036: We now deactivate immediately if you type #, @, or some other characters which are probably never part of a query.
• D15037: We don't summon the completer until you type at least one character.
• D15038: If the completer would fall off the bottom of the window, put it above the cursor instead.
• D15039: Two effects:
  • If you finish typing a word (e.g., type a space) and there are no results, deactivate since nothing else you could type could possibly cause matches and you're probably not fishing around since you just hit space.
  • If you finish typing a word (e.g., type a space) and the query matches exactly one result and you just typed that result exactly, assume you typed the result from memory and deactivate.

Note that "if you finish..." actually means "if you finish, and we have results from the server", so depending on how fast you type this may take one or more additional words to trigger. This could be refined slightly.

That word stuff still has some weird/buggy results, I'll see if I can improve the behavior.

I sort of expect it to also place a space for me after selecting the correct object.

I didn't do that because I don't think a space is universal -- I've seen ":" and ",", particularly.

I can add that, though.

Yeah I'm finding implementation mixed at various sites.

Okay, all that stuff is live now too.

In T10163#154334, @cspeckmim wrote:

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

In the case of 1 match, we now hide if there's one match and it's exactly what you typed. I don't like space acting as an autocomplete and I don't like dismissing when you only typed a prefix, but if you know a user's full username and just type it the behavior should be fairly reasonable now.

In the case of 1 match, we now hide if there's one match and it's exactly what you typed.

I think that's what I intended to describe - hadn't considered if there was a single match but wasn't exactly what was typed. Thanks.

Is it expected that this doesn't work on mobile?

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

Only in the southern hemisphere.

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

Did you try turning your phone upside down?

ǝɯ ɹoɟ sʞɹoʍ ʎǝlʇsǝᴉɹdǝ@

From D15029:

if (JX.Device.getDevice() != 'desktop') {
  return;
}

Is there any intention to add support for auto-complete when typing like "T1234" or "D1234"? That would help immensely with instances that have a large number of tasks or diffs. I know there's been a few times on this instance where I've wanted to refer to diffs in task comments, but I can't remember the number perfectly so I have to open a Maniphest search to try and guess what number it was. Having it in the typeahead with the task / revision title would mean I don't need to spend time doing that.

are you kidding me, I spent all my @epriestley points on this as is.

wait how do I get @epriestley points

haha no idea, this arose from a product discussion about how project tags will render when there are 16 levels.

The most recent ruleset seems to be working pretty well for me. It hasn't been spazzing out and popping up all over the place, but has been there the couple of times I actually wanted it.

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

This currently triggers autocomplete, but probably shouldn't: ` #f.

I'm not planning to touch all the cases like ` #x, {nav #x, ``` #x, %%% #x, etc. We don't have a client-side Remarkup parser and I'm not planning to build one for this. See T3725#39466 for some earlier discussion.

Feel free to say no... but if you start an @ at the edge of the remarkup box, the text will move to the newline but the box won't.

I think I can fix that. The current assumption is that the wrap is the result of multiple words:

Do you think this is a good idea, @chad
bartholomew caesar little iii

...but obviously that isn't true in the above example.

In T10163#154382, @epriestley wrote:

• D15039: Two effects:
  • If you finish typing a word (e.g., type a space) and there are no results, deactivate since nothing else you could type could possibly cause matches and you're probably not fishing around since you just hit space.

I'm seeing this occasionally fail to happen. My best guess is that it's when you press space whilst earlier autocomplete results are still loading. In that case, you get a floating Find user: @epriestley I'm not really sure this is 100% fixed yet popup over the text field, with the preview displaying correctly (user properly linked).