Skip to content

Editor model world should offer some amenities to protect against data loss / file corruption #117873

@jrieken

Description

@jrieken

Normal file editors, custom editors, and notebooks all implement editors for something on a file system. All implement the relatively rigid structure of editor inputs and editor models. However, they get little to nothing in return for implementing this, there is no service-like infrastructure that makes my live simpler, e.g

  • there is logic for sequentialising saves inside TextFileEditorModel and roughly the same code exists (was copied) for notebook editors. Custom editors tackle the same problem, but uses different code. So, instead of everyone re-inventing the wheel the "framework", which interfaces I must implement, should take care of this for me.
  • there is duplicated logic for when a file is being deleted, e.g text file editors have inOrphanMode and custom editors have _inOrphaned. There is a utility method decorateFileEditorLabel to decorate the editor label to indicate orphaned editors but this should move into a common super type. Notebooks didn't copy this yet. Again, I should be able to express to the framework that I am some kind of file editor and then deletion should be taken care of
  • the logic for general file watching is duplicated, e.g when a file on disk changes we reload it unless the file is dirty (text files, notebooks). The framework should do that automatically because I already tell it how to load and whether my model is dirty or not.
  • [ ] there is a TextFileEditorTracker that takes care of opening dirty models and reloading them when the window gains focus but this code is only used for text file models. Notebooks has NotebookFileTracker for that
  • there is a complex dirty write prevention code in file service validateWriteFile . A simple version was implemented in notebook but it has "false negative" bugs as remote/live-share cases are not covered. Custom editor doesn't handle this yet it seems. Related: Dirty write prevention in notebook content provider #117715
  • text file models register listeners to gracefully finish any pending saves on shutdown, which notebooks and custom editors either do not do or currently fail to do with a high risk of data loss
  • properly restore backups for file working copy providers

I don't think this list is complete but that's my learning from the little exposure I have gotten via the notebook world. The current approach just seems wasteful: we duplicate code, we duplicate bugs, we duplicate work.

Metadata

Metadata

Labels

custom-editorsCustom editor API (webview based editors)debtCode quality issuesimportantIssue identified as high-prioritynotebookworkbench-editorsManaging of editor widgets in workbench window

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions