* Create correct TextDiffType for line => use inline wrapper color instead of default.
* Don't draw the shadowed line, otherwise it mixes with inline diff highlighting (overdraws 1 top pixel of it with a lighter color).
FragmentHighlighterImpl#addBottomLine:
- don't guess about type, pass fragment.getType.
- call twice: for top and for bottom separators (but only once for insertion/deletion).
DiffMarkup:
- remove the last-highlighter logic. Using double call of addLineMarker instead.
- work with TextDiffType colors.
- use a renderer to draw a nice shadowed line.
* Don't highlight the line marker renderer for inline changes - the line fragment wrapping them will be used.
* Therefore remove the code for adjusting text range height from the DiffLineMarkerRenderer.
* Introduce TextDiffType#myInlineWrapper for diff type of a fragment that is a wrapper for inline changes.
- use special background color for such type.
- refactor getTextAttributes: for scheme just return the color from scheme, all adjustments (for applied and for inline changes) are made in getTextAttributes(Editor).
* Create special inline TextDiffType instance where needed: in the LineBlocks (for DividerPolygons) and in the DiffMarkup (for the gutter and code highlighting).
* Make the merge tool settings be common for diff and merge. Rename to DiffMerge... and move to a common place.
* DiffMergeSettings is actual storage of the settings. But to let have different settings for diff and for merge, don't make it a PersistentStateComponent. Instead declare two subclasses, which are PersistentStateComponents themselves.
* DiffPanelImpl, DiffToolbarComponent: move toolbar creation from the constructor to setDiffRequest, since the toolbar now depends on editors.
* Hide the standard popup, invoked on the gutter. For detailed reasons list see 8cfda8e5 (same for merge tool).
The height of the rectangle highlighted by the LineRenderer should be recalculated for any inline fragment: there are inline fragments occupying several lines (starting with the end of the first line, continuing thrown several whole lines, ending with the beginning of the last line).
PROBLEM:
inline fragment can appear on 2 visible soft-wrapped lines (in case of short diff, for example), but we draw them only on one.
SOLUTION:
Make DiffLineMarkerRenderer calculate the real visual height of the modified range and draw the rectangle with correct height.
PROBLEM:
An inline insertion was shown as modification in the polygon, because the polygons are generated based on the type of the total fragment: a LineFragment, which contained children InlineFragments.
SOLUTION:
After inline child fragments are identified, adjust the type of their parent fragment if needed.
That is, if the change is just insertion or just deletion, the parent fragment should be of the same type. However, if the parent fragment contains two child changes of different types (e.g. an insertion and a deletion inside a single line), the summary change is a modification.
For inline changes the range being highlighted is 0 pixels high (it is calculated in EditorGutterComponentImpl#getLineRendererRectangle)
To avoid the problem, identify if the change is inline (InlineFragment occupying one line), and increase the height of the highlighter area to be 1 editor line high.
Extract the DiffLineMarkerRenderer from the mergetool's ChangeHighlighterHolder, and reuse it for rangeMarkers in the DiffMarkup.
Remove LineRenderer since nobody uses it anymore.
anna
Sergey Evdokimov
Eugene Zhuravlev
Kirill Likhodedov
Konstantin Bulenkov
Dmitry Avdeev
irengrig
Eugene Kudelevsky
Alexey Kudravtsev
sweinreuter
nik