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

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

T10150 is probably describing the same issue, but this report is much more detailed.

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.

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

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.

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 ., -, (, |, #, @

The second biggest source of storage pressure appears to be test instances that, e.g., imported the Linux Kernel and were then suspended. I've filed T10166 to follow up.

This is now available in the cluster, but the storage engine currently never selects it for new writes because MySQL is still configured to allow 8MB chunks. I'm going to selectively migrate some data, but probably not turn default writes on for a week or so.

Pygments added support a couple of months ago but hasn't released a version with support yet. See:

Oh, that probably didn't get updated for the new IconSet stuff.

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

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

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.

In T10163#154221, @chad wrote:

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

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.

T10161 is a case of another install that selected ElasticSearch without a specific reason, based on a general belief that it is better in some intangible way.

See some general discussion in T9893, although this doesn't seem to be an ElasticSearch 2.0 issue.

(I've made a private note about this elsewhere, if you work with @nipunn.)

Just closing this since it's a huge fishing expedition that we can't help with, see Contributing Bug Reports and Support Resources.

(Also: why are you using ElasticSearch instead of the default search?)

What version of ElasticSearch are you using?

Sure.

Can you explain this problem in more detail? See Describing Root Problems.

Thanks, those reproduction instructions are clear and I expect it will be straightforward for us to reproduce and fix this.

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.

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.

This thing is going to have a decade of bugs.

Yeah, completeness is definitely sufficient motivation if you're up for it.

This report does not include reproduction steps. We can't move forward on bugs we can't reproduce. See Contributing Bug Reports.

Oh, I'll make this editable in the cluster from the instances panel. Change will go out on Saturday morning (about 36 hours from now).

See uri.allowed-protocols in Config.

A sufficient diagnostic test is apparently to complete any connection with ssh -v and observe no "Roaming not allowed by server" message in the output. Cluster hosts with the configuration fix pass this test.

I've applied the configuration fix to all Phacility cluster hosts that initiate SSH connections to untrusted servers, so we should be in the clear.

I'm not really sure what's going on. The limit on the slug column is 128 characters, and that project name is nowhere near that (we should raise a better error message than we do, but I'm not sure how you're hitting the issue in the first place).

Can you show me the output of bin/storage adjust? (For now, decline to apply any changes it suggests.)

Prior to T9551 (circa October 12), projects could generate with invalid hashtags, but I don't think these ever worked (at least, many of them definitely did not work).

The original report in Q272 is almost certainly unrelated.

I think T10116 may have fixed the "actions ignored" issue -- does it still reproduce for you after that?

Resolved by D15019.