At least on the iPhone, it's actually possible to "shift + return". Not sure if we can pick that up in JS, but might be good enough if we can.

That probably means there's no way to write newlines on mobile, but oh well?

• Enter with no modifier keys sends messages.
  • Enter with any modifier key adds a newline.
  • We could remove the "Send" buttons, too, I suppose.

Let's try just doing send-on-enter always? I hate preferences a whole lot (even more than send-on-enter), and we're pulling the product in a pretty chat-ey direction. If it's terrible we can add a preference.

I fixed T7514.

Nice, thanks!

I've had a bunch of stuff going on today, but is the "pop in" where the column loads after the page and then the whole layout jumps intentional? It feels a lot worse to me than the behavior I think we had before (empty column which loads content but doesn't reflow the whole page).

We haven't seen this problem with npm before, so I can only offer vague advice -- are your node and npm up to date? Does installing other modules with npm work? You may have better luck filing against npm.

We can cheat and do a:

This should also probably say "Hide Column" or similar, to avoid ambiguity with "Close (the browser) Window".

I've been looking at (2) a bit -- letting instances upload large files. The ideas I came up with are:

Ah, nice. That feels a lot more palatable.

Via IRC, the account.editable option currently locks "Real Name", but it would be more flexible to make this an option on the field itself.

I like (3) on its own, but they all feel too heavy to actually ship to me -- (2) and (3) moreso than (1). Like, the terrible one-time clippy popup seems less bad to me than making the element that much heavier for experienced users. My thinking that we can make headway here by making the "draft" state more obvious may ultimately be misguided, since these are pretty tame but still feel too heavy to me.

I think making the 7th icon a fixed "more" (or maybe eventually a dropdown) makes a ton of sense.

I did consciously think about the behavior, but it's possible I did that after accidentally changing it. However, there wasn't any code to save/restore the focused element so I'm like 95% sure the behavior didn't change.

Pretty sure I didn't change that, although it's possible I did by accident.

This is intended. In particular, if you highlight other inline comments we'll update the reticle to show you the code they cover, if you need a reminder. Code can also be kind of hard to read through the reticle. We could lock it while the editor is active if you haven't moused over anything, but it seems reasonable to me as-is?

This probably still has some bugs, but I don't know what they are yet. The code is now relatively cohesive and meaningfully testable.

Yeah, basically. Presumably at some level of <blink /> tag, no first-time user will get the model wrong, but then every user pays the price for it forever. That mock feels like too high a price to pay, although maybe there's a 1/2 as blinky version that's more obvious than "Not Submitted Yet" + dashed border.

One possible approach is to overkill the draft-ness so hard that no reasonable user being can possibly miss it:

We have at least one piece of feedback from a red/green colorblind user that the current color scheme doesn't cause a problem (see T3127#32078), although it's possible this wouldn't extend to the unified view.

This was fixed by D11970.

For the actual inline, here's the set of elements I'd like to try starting with:

• Value seems very low.
• Behavior is generally consistent with "Find Next" in many programs, including browsers.
• It's a pain to compute "Next (Back to Top)" because inlines can become visible or invisible in response to a bunch of events (e.g., adding and removing comments, showing and hiding files, new files loading).
• There may be only one inline, which would produce something goofy like "Prev (Wrap to Bottom) * Next (Back to Top)" and probably need to be special cased, further raising the complexity of the feature.
• Use case isn't very compelling: there shouldn't ever be a lot of lint comments. If linters are raising nontrivial levels of false positives, delete them. Lint has powerful tools for excluding files, adjusting severities, etc., and particularly after .arclint these are relatively easy to configure.

We're going to explore other approaches. I don't anticipate building this, specifically.

@chad, do you have thoughts on where you want to go with this? I'm definitely WONTFIX on it -- e.g., neither Chrome nor Safari nor TextMate give a specific visual indicator when wrapping under "⌘G", so this feels consistent to me. I can't recall any application giving a specific wrap indication except nano, which just says [Search Wrapped].

I think we're nearly consistent about that, although @joshuaspence caught at least a few other cases where we're missing the disabled style and there are probably a few cases that are arguable or ambiguous (for instance, user creation is no longer necessarily admin-only, it's just admin-only by default and at-most-admin-only in all reasonable setups we're aware of in the wild).

The expected behavior is for the dialog to use a workflow. In general, disabled actions should use a workflow so that dialogs show on the same page when the actions are clicked.

This is the default behavior. Use --everything or specify paths to lint all files.

In a lot of cases, a user will have permission on some objects but not on others. For example, you can often "Edit Project" on some projects, but not on others. In these cases, the intended behavior is to always to show the action, but show it with a disabled style if it isn't available on that particular object. This makes the UI more consistent (the same actions are always available, and the actions are always in the same positions) and more discoverable (you can see that the action is available) and more comprehensible (you can click the action to figure out why you aren't allowed to take it).

I don't have a reasonable way to fix this and the use case doesn't seem very compelling (i.e., we should make Harbormaster builds easier to monitor without reloading the page).

@qgil, I believe the sidebar thing should be fixed at HEAD -- see T7052.

Doesn't repro for me either.

"Leader Board" essentially is that -- by design, tokens are given to objects, not users. For example, there's no clear user to credit with a token when you give a token to a wiki page with several editors.

Modulo that terminal quote, I conclude this is a problem with your client.

PBR American Apparel selvage, banjo actually next level chia gentrify cronut authentic. Shabby chic ennui health goth Banksy Intelligentsia PBR. Wolf irony health goth pug lumbersexual High Life cliche, heirloom Neutra. Narwhal slow-carb retro, organic Brooklyn typewriter Portland. Quinoa kogi literally, cardigan paleo viral vinyl occupy photo booth sartorial Brooklyn semiotics Shoreditch wayfarers drinking vinegar. Pour-over VHS flexitarian paleo pickled. Messenger bag Blue Bottle Kickstarter narwhal, gluten-free kogi banh mi Bushwick Godard fanny pack quinoa synth skateboard occupy chambray.

Sending myself an email.