The preview section underneath the comment area doesn't mark "editing" inlines in any special way.

For now, I'm just leaving this as-is. It may get a revisit as part of T11401 or T13514.

See PHI1703. The document engine the original comment was made on should be persisted, so email can do something better than dumping unrelated lines of text into the body.

The major outstanding DocumentEngine issues I'd like to clean up are:

• When creating a comment, save which DocumentEngine the viewer is using (for example, line 9 of a Jupyter view is not the same as raw source line 9).
• Fix the behavior of the DocumentEngine selector menu so it saves the current engine and provides only useful options, noted in T13515.
• Fix the email issue described in PHI1703 (nonsensical rendering of inline comments on Jupyter documents in email).
• Fix the rendering of context in document engines as "• • •" instead of actual expansion controls.
• Consider supporting document engine rendering into email. I will almost certainly kick this out of scope.

Probably kicking this, but:

• When you are viewing a document with engine X, and comments originally made with engine Y are present, this should be indicated ("This comment was made while looking at this change as a Q document."). They should probably also be moved to the top/bottom of the file, at least by default, since "Jupyter line number 9 = raw source line number 9" is an exceptionally bad and confusing guess at how to map line numbers.

Inline stuff:

• The menu hover state for non-done inlines is weird (and for done inlines, although it's less visible).
• The selection reticle does not redraw/resize after "Edit Comment".
• Selected inlines should get a header visual treatment similar to selected changesets.

I have a patch which allows you to edit published inlines. It "works", but it causes a ton of weird side effects when you perform an edit.

For example, inlines on the same line (example.c:123) are currently ordered by ID. This naturally puts newer inlines and replies at the bottom. But, when you edit an inline using the shared editing infrastructure, the edited comment object in storage has a different, larger ID. It flies off screen, falling to the bottom of the thread.

For now, I think I'm going to support "View Raw Remarkup" (which is easy, and works correctly) and pursue the other changes. It's possible to implement inline editing on the object itself, and the shared infrastructure might not be usable anyway if inlines get multiple fields ("Suggested Change" + "comment").

• When you create an inline, do nothing, then click "Cancel", inlines briefly count themselves in the paths panel.

• In Firefox, multi-line selections don't generate a context menu properly.
• Clicking the "New Inline Comment" action disables the oncopy behavior onmousedown but doesn't take the action until onclick. This creates a flash of selected content which spans both sides of the change and looks odd.
• Context selection doesn't activate in unified mode, maybe because data-copy stuff is being used to identify content cells.

• In Jupyter notebooks (and, theoretically, other rich content) we find an inner <td /> before finding the content <td />, preventing context menus from working.

• The line-triggered reticle should be updated to use the hover-reticle cell style.

• The inline comment context menu does not apply the correct cursor ("pointer").

• This isn't necessarily terribly useful in practice, but a UI hint about whether or not we've actually saved a draft would make debugging slightly easier.

I still have a lot of inline style attributes to clean up and then I'm sure there will be a long tail of weird edge cases, but this is getting pretty close:

The inline comment context menu does not apply the correct cursor ("pointer").

I can't actually reproduce this, sometimes Safari is weird about USB devices getting connected/disconnected and I think this was just a local issue.

• Inline comments with suggestions don't "know" that they're empty when the suggestion is the same as the context text.
  • Create an inline. Suggest edit. Don't change anything. Save. You get a blank inline with no suggestion and no content, when this inline would normally delete itself.

I made a change to drop unchanged context from suggestion views, but I don't particularly like it. It changed this:

...into this:

But that feels unfaithful to user intent and can be ambiguous.

private function simplifyChange($old, $new) {
  $old = phutil_split_lines($old);
  $new = phutil_split_lines($new);

  $old_count = count($old);
  $new_count = count($new);

  $min = min($old_count, $new_count);

  $head = array();
  for ($ii = 0; $ii < $min; $ii++) {
    if ($old[$ii] === $new[$ii]) {
      $head[] = $old[$ii];
    } else {
      break;
    }
  }

  $tail = array();
  for ($ii = 1; $ii <= $min; $ii++) {
    if ($old[$old_count - $ii] === $new[$new_count - $ii]) {
      $tail[] = $old[$old_count - $ii];
    } else {
      break;
    }
  }

  $head_keep = 0;
  $head = array_reverse($head);
  foreach ($head as $key => $line) {
    if (strlen(trim($line)) > 3) {
      $head_keep = ($key + 1);
      break;
    }
  }

  $tail_keep = 0;
  $tail = array_values(array_reverse($tail));
  foreach ($tail as $key => $line) {
    if (strlen(trim($line)) > 3) {
      $tail_keep = ($key + 1);
      break;
    }
  }

  var_dump(
    array(
      'head_keep' => $head_keep,
      'head' => count($head),
      'tail_keep' => $tail_keep,
      'tail' => count($tail),
    ));

  $keep_adjust = ($head_keep - count($head)) + ($tail_keep - count($tail));

  var_dump($keep_adjust);

  $old_keep = count($old) + $keep_adjust;
  $new_keep = count($new) + $keep_adjust;

  $old = array_slice($old, count($head) - $head_keep, $old_keep);
  $new = array_slice($new, count($head) - $head_keep, $new_keep);

  $old = implode('', $old);
  $new = implode('', $new);

  return array($old, $new);
}

• j, etc., can incorrectly select blocks inside a diff inside a suggestion.

• In previews, suggestions aren't highlighted properly (likely just missing CSS).