First, the ▾ points down when the source is expanded, but that line appears
below the expanded source. Pointing up with ▴ would make more sense. Second, the
e key should use the same consistent key indicator as the rest of the app. If
it's not a reusable component yet, maybe turning it into one would be a good
first change. Third, change the wording to 1 abridged line · e expand and
Expanded 1 abridged line · e collapse.
> ◇ ▸ 1 exact line hidden · e expand
◇ ▾ Exact source expanded (1 line) · e collapse
Hmmm and maybe we actually use something like
> ◇ ▸ 1 abridged line · e expand
[user presses e]
> ◇ ▾ Expanded 1 abridged line · e collapse
[code]
◇ ▴ Expanded 1 abridged line · e collapse
So they can press e at either bound to collapse it.
Those indicator rows should also span the full diff width in unified mode, but only span the half they actually apply to in split mode. Right now, the indicator spans the full width all the time even when the only abridgment is on e.g. the right.
I would say we should use comment-style [ lines in the gutter to denote abridged regions, but we could only distinguish between commented region and abridged region through colour and that's not acceptable. That also wouldn't work to indicate the bounds of abridged regions inline. Maybe we use a blue background? Though we use red/green backgrounds, we also have -/+ in the gutter and the whole split mode to indicate added/removed when colour's unavailable. Putting symbols in someone's diff to indicate abridged regions could make them think those symbols are in the actual code, so that's also not acceptable. Maybe we turn to formatting and do some consistent underline or italicisation (not both) for abridged regions and maybe not do anything with the blue background idea? We'd need to keep any highlighting and formatting from the syntax highlighter, and also tack on whatever italics/underline we decide on.