kevboh / longform

A plugin for Obsidian that helps you write and edit novels, screenplays, and other long projects.
Other
610 stars 30 forks source link

Feature Request: Move YAML config into data.json for plugin #207

Closed b-camphart closed 7 months ago

b-camphart commented 8 months ago

Describe the solution you'd like Since YAML can be finicky and difficult to parse, what if the plugin provided a GUI interface to select which folders were longform projects, then kept track of that data within its own data.json file? The configuration of each project would then also be done through the plugin GUI. This would allow more flexibility in how the plugin stores information and ease the user experience.

Describe alternatives you've considered If we keep the YAML interface, the more complexity that is introduced to the plugin, the more end-users have to understand the exact format that longform requires, and longform itself has to support loading that configuration. Any new feature that requires additional, persisted data would require the feature being implemented, documentation created for end-users, persistence code to be updated, migration code to be written, and parsing code to be created for the new field.

By storing it in the data.json file, new features can be automatically migrated behind the scenes, and no end-user documentation is required (but in-code documentation would be!).

b-camphart commented 8 months ago

Thinking about how to introduce the concept of "excluded scenes" is what made me think of this. The YAML file would have to either have a whole new list of scenes that are excluded from compile, or each scene in the "includedScenes" list would need to have a flag under it, OR each scene file would need its own longform-specific property. All of which, if the user uninstalls longform, would still be in their vault. It would also require some potentially painful migrations, and a difficult, error-prone workflow for end-users.

If Longform stored this information in the data.json file, users would no longer have to think about it and, when longform was disabled, their vault wouldn't contain any unnecessary metadata.

b-camphart commented 8 months ago

The data.json structure, given the current feature set, could look something like this:

{
  "version": "longform-version",
  "projects": [
    {
      "name": "Name of project",
      "drafts": [
        {
          "folder": "/path/relative/to/vault",
          "format": "scenes",
          "workflow": "Default Workflow",
          "sceneFolder": "/",
          "scenes": ["sceneName"],
          "ignoredFiles": ["ignored scene name"]
        }
      ]
    }
  ]
}
kevboh commented 7 months ago

This was how Longform 1.0 worked and it was a nightmare. Keeping a file on disk in sync with the reality of a vault's metadata turns out to be extremely difficult. You also open yourself up to a bunch of edge cases around sync—e.g., it's impossible to tell from a plugin's perspective if a new note was just created or if it was synced in, and that is an important distinction when trying to keep track of everything in a dedicated json file.