Merge editor starts showing merge markers after closing file

[mjbvz]

Testing #150389

1. Open merge editor
2. In another editor group, open the file being merged3.

3. Now close the file being merged (main.ts in my case)

Bug
The bottom part of the merge editor scrolls all the way to the bottom of the editor. When I scroll it back up, I see merge markers:

[mjbvz]

I also don't understand what the filled circles that replace the checkmarks mean

[hediet]

I think the bug is caused by how we integrate the merge editor into the workbench.
Hopefully this gets resolved after @jrieken, @bpasero and me meet next week.

I also don't understand what the filled circles that replace the checkmarks mean

This means that the user has changed the result in this area, but has not accepted either input 1 or input 2.

[bpasero]

I cannot really reproduce the issue:

Anyway: the "Result" of merge editor should be identical to the file on disk, meaning that edits in the one are reflected in the other editor, same as we do for diff editors.

[hediet]

Anyway: the "Result" of merge editor should be identical to the file on disk

Only if the editor is not dirty, right? In that case all editors should use the same text model.

[bpasero]

I agree that opening an editor should not make it dirty right from the beginning, so I suggest to:

• always have the result be the actual file on disk
• never change the file when you open the editor
• find a clever way how to hide the merge markers so that resolving the merge conflict is still nice without having to remove the markers and thus turn the document dirty

I am not sure whether this is possible or not?

[hediet]

I like this! Let's try to collapse merge markers, so they take only a single line.

[bpasero]

One thing I am not entirely sure: even when we remove merge markers, the file would still contain both conflicting changes one above the other. Maybe the merge editor initially should reflect this by showing both checkboxes checked in that case and then as a user, only when I click a checkbox, the editor becomes dirty and changes are removed?

Edit: interesting, so VS also opens the file dirty right from the beginning, maybe they have gone through the thought process and didnt find a better solution?

[jrieken]

One thing I am not entirely sure: even when we remove merge markers, the file would still contain both conflicting changes one above the other.

Yeah, that's the issue. The merge markers and the inlined versions should be understood as a "poor man's" merge editor. IMO keeping that in a "UI-driven" merge editor adds more confusion than help. It's also entirely unclear who tells us what part of a file is "merge marker noise".

I do understand the confusion about the editor opening as dirty. We could not make any changes during open, just be a different display-mode for how the file is on disk (e.g the results pane wouldn't show the file as on disk). Once the user accepts changes make the file dirt, maybe have a user-setting to auto-apply non-conflicting changes (which means dirty on open again)

[bpasero]

Btw I believe in VS case, the file is actually in some temp dir, so you may not be editing the actual file, but some copy.

[jrieken]

Yeah, that's something we have thought about and maybe not discussed enough yet. The downside of a temp/virtual file is that language services likely won't handle them as good as files on disk

[bpasero]

Yeah wasn't suggesting to go down that path, I think all advantages when the real file on disk is edited 👍

[jrieken]

I believe this issue will go away when we implement #151024. The plan for that is to show a modal message when you are closing the merge editor while still having unresolved conflicts

[jrieken]

Closing since we now have the explicit warning about unhandled conflicts on close (#151024)