Change:
// Replace the overrriden input, with the text based input await this.editorService.replaceEditors([{ <del> editor: input, </del> <ins> editor, </ins> replacement: overridenInput?.editor ?? input, options: { ...overridenInput?.options ?? options,

Discussion:
!
Could be clearer to not show them in the picker here, but what is happening is that the hex editor can't handle diff views and therefore we are doing nothing and you continue to see the text view.
The text view should be able to try to render the binary data, if you open it in a non-diff view it does show text.
I don't think this is an override bug. What's happening is I'm calling with an input with . However, it doesn't seem replaceEditors supports replacing in a diff. Maybe we should always on belonging to diff editors.
To clarify, we want to replace a diff editor with a normal editor right? Or should this action reopen as diff editor?
It has to do with replacing a side of a diff editor input. There's two possible solutions here. replacing sides of a diff editor input (probably over complex) so that the user will see the binary message and then can click open anyways open text diffs as files even if binary.
I think I would expect the diff editor to reopen where both sides pick the editor I selected from the quick pick.
The quickpick only knows about one side of the editor at a time. We explicitly disable reopen with in diffs for this reason. Just the binary case is a special case as the user can trigger the quickpick from the link
I see, I probably then would expect that it opens the editor where I selected the link from. If that is too complex, maybe we open the editor as a new editor, and not as diff?
What I don't understand is why we have this idea of a binary diff editor? It's of no use and both sides just show that they're binary and request to be opened as something else. Wouldn't it make more sense to just show the text representation of the file if opened in the diff view. Any useful binary representations will get delegated to an extension anyways which is supported.
for consistency reasons and for performance reasons.

consistency: if you get the binary editor by clicking on the binary file, I would expect the same when diffing performance: binary files can easily be gigabytes in data, just opening them as text for the diff case would potentially bring down the window
This is really tricky to fix, the issue is here: We try to replace the editor, but the editor is actually not opened as a single editor, it is opened as a diff editor on the one side. I would also argue that this line is fishy: Because that only makes sense if the editor that is picked is a text editor, not when it is a custom editor. I think we need to revisit that code entirely, since it originates from a time where we did not have overrides either.
Maybe this could work: since this can only be triggered by the user from the active editor, check if is a side by side editor and then tweak the call to accordingly only call if the picked editor is a text editor
Diffing two random exe's from the vscode repo, it looks like nothing is shown in the diff view. We should at least have some message here https://user- I don't see any relevant errors in the devtools
This now seems to be opening a monaco text diff editor and not a binary diff editor anymore which seems like a regression from our work in the editor service (most likely): !
this is a regression from comparing untyped based in for typed editor inputs: The unfortunately will be even for . I will open a PR to make our various functions that check for untyped editors more robust.