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

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.

Maybe we can do this:

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.

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

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.

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

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?)

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.

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.

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.

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.

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

Some nuances I've tested:

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

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)?

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.

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

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

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

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

I heard @scp is also good at breaking things.

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

That appears to be working better, now.

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.

derp

In T10163#154221, @chad wrote:

If I type @demo and then tab it changes to @abuna

If I type @demo and then tab it changes to @abuna

http://www.gyro-php.org/documentation/contributions/group__Unidecode.html seems relevant.

It may also make sense to fold accents when normalizing strings for ngram indexes.

I think this behavior is reasonable as-is.

I ideally want to resolve T8588 before pursuing this since it's the more fundamental performance issue, even though this isn't particularly entwined with that.

Sorry I had several instances of phabricator up comparing results and must have messed up which one was which. As you pointed out viewerprojects() specifically (which really is the one I was interested in) is not available on this install.

It looks like viewerprojects(), specifically, isn't included in these sources at HEAD.

Are you at HEAD / does this problem still exist on this install?

Excellent point, thanks for clarifying.

In the past, the bulk editor worked like this under a similar theory (and or laziness, I don't remember which contributed more), but we had at least one (and maybe a few? I don't recall offhand) user who failed to guess it and didn't even try the interaction in the bulk editor.

I'd be curious how important it is to the project to maintain UI consistency between Herald and Maniphest. Currently leaving the field blank in Maniphest places the task up for grabs -- wouldn't it be preferable to maintain the same expectations in Herald?

I always use this menu to access the special items as I have no idea what to type to auto-complete them e.g. "not in any project".

This interaction would be less clear in the general case. This problem is better solved through T3670.

chad changed the title from "Support accent folding in typeaheads" to "Support Áçčềñṭ-Ḟøłɖǐṅg in typeaheads".

In T7897#108576, @epriestley wrote:

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

These aren't universally deployed yet, but are substantially complete and are deployed in multiple applications. See T7858 for some followups. These will deploy everywhere over time, although they may not come to some lesser-used applications for a bit.