kevboh / longform

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

Feature Suggestion: Indenting Scences (Sub-Scenes) #11

Closed chrisgrieser closed 2 years ago

chrisgrieser commented 3 years ago

Especially for longer longform ( 😉 ), I would almost certainly create sub-sections and sub-sub-sections to organize the draft. Right now, the longform plugin only allows to order the scenes, but not to "indent" them or change their "level" (scene, sub-scene, etc.).

And further QoL features related to this are then to use the scene view as some sort of outliner by being able to fold the higher-level-scenes.

edit: of course, sub-scenes would also go with a compile option to insert heading levels according to the level/indention of the scene.

kevboh commented 3 years ago

I've definitely thought about this. It's not a short-term goal, but it's on my radar for sure.

kenanmike commented 3 years ago

I think I mentioned this on the discord just before release but this feature is way up there on my wish list for this plugin too. Probably number 1!

jyhelle commented 3 years ago

...and could we start at a "chapter" level, so the first level sub-sections would be scenes, etc (or alternatively have a mean to group several scenes in a chapter) I currently use "fake" scenes to indicate chapter change

akadormouse commented 3 years ago

I use Writemonkey 3 with attached files jointly accessed through Obsidian (other programs too). WM3 has longform, files (aka scenes), with the option of sections and chapters. (Also has compile equivalent). Certainly for me, managing scenes without also having chapters (and maybe sections) would be difficult. For the moment I can do that through WM3, but it would be useful if working in Obsidian to also have that facility there, so I support this request.

kevboh commented 2 years ago

To revisit this after linking here in #39: I've been thinking about this issue for a while now, and I think there are a few options here:

  1. Scenes remain notes, but you can nest scenes in folders. This would mean that parent scenes would not have their own content—they would instead contain child scenes (and perhaps more folders which themselves have child scenes, etc.).
  2. Scene level is tracked as metadata in the Index. This would allow arbitrarily nested scenes, each with its own content. I'm not totally sure what a parent scene with content + child would mean conceptually, though.
  3. Child scenes are not notes at all, but instead headers (#, ##, etc.) correspond to scene index level and appear in the project sidebar, essentially reproducing the outline core plugin. Rearranging them in the sidebar rearranges those sections. This approach has the advantage of making it trivial to see a parent + all its children in one note, something I'm not sure I could reproduce within the constraints of Obsidian in the other two options.

I'm curious what others think of the above, and how they might fit use cases.

chrisgrieser commented 2 years ago

I think 2) would make most sense, since it wouldn't create unnecessarily huge folder structure when one uses sub-sub-scenes. It also has the biggest flexibility, e.g. concerning reading the data from the index via dataview.

I'm not totally sure what a parent scene with content + child would mean conceptually, though.

quite often, I do that for an introductory paragraph that explains what is going to happen in a chapter. (though this mostly concerns non-fiction writing, I guess)


re 3: I don't really see the value of reproducing the outline core plugin, since well, we could simply use the outline plugin. To see parent + children in one note, one could use partial compiles (i.e. compile only a chapter), or small support notes ´which embed other notes.

akadormouse commented 2 years ago

I have already switched to writing each project - article/book/series - in a single markdown file. This includes all the research, resources etc. I think 3 is the nearest equivalent to that.

A Scrivener file is a container which includes other files, and a single markdown file can be used in the same way. It has the advantage of transportability (any markdown editor will recognise and understand the whole project) and simplicity. But it can be substantially improved by adding management features. Organisation is needed whether you start with many small files and stick a manager on top or whether you start with one large file (with many sections and sub-sections) and add a manager to make it easier to work with. Obsidian itself has few features that help though the improvements in the Outline core plugin certainly help. It also has the advantage of not needing any work for printing or publishing since there are already many programs that will do that for a single file.

ReaderGuy42 commented 2 years ago

I agree with @chrisgrieser, personally, I don't like having too much stuff in a single file.

yogeshwersharma commented 2 years ago

@kevboh - I am super interested in this. #2 approach seems the most flexible, and does not seem "too difficult" on the surface. Are there any technical difficulties in implementing this?

I am a programmer myself, and would love to help here if it is not a lot of work. If you have thought about this, and willing to share your thoughts, maybe I can contribute. Let me know your thoughts.

codyburleson commented 2 years ago

I am writing to place a vote for this feature. I'm using little labels in my scene titles to denote the part they belong to. It sounds like Option 2 is a good option. I can see just making an .md file with only a title just to serve as the Scene delimiter.

kevboh commented 2 years ago

@yogeshwersharma unfortunately this feature gets caught up in a general need for refactoring how project organization works within Longform (#35). Project-level index files introduce sync bugs and a lot of boilerplate (e.g. draft folders for short stories), and adding more metadata to an index file I want to move to a different format is dicey.

I'm just now getting over covid (you actually commented on the day I tested positive, ha!), but plan on beginning work on both the project refactor and this feature in the next week or so. Once I have that work begun I am happy to see if there is parallel work to do, and if so, hand it off. Familiarity with typescript and Svelte, especially Svelte stores, is useful.

yogeshwersharma commented 2 years ago

Sorry for missing your comment.

I'm just now getting over covid (you actually commented on the day I tested positive, ha!)

I hope you are feeling better.

I have not checked any updates yet, but I look forward to your refactor and seeing if I can contribute in any way.

LucidToday commented 2 years ago

Hi, I'm late to this thread as I've just started looking seriously at moving from Scrivener to Obsidian. Scrivener's great for organising writing content, not so much for the metadata surrounding it, i.e. world building, character arcs, and so forth. What I would love to see is the equivalent of Scrivener's binder, to support a hierarchy for organising scenes. For me that would be Series-Book-Act-Plot Point-Chapter-Scene, although I realise other authors might structure things quite differently. Essentially I see a novel as being structured as a tree with scenes as the leaves, if that makes sense, so your option 2 of having separate metadata to track the structure would probably keep most people happy I think. Anyway, just some thoughts from an author who writes fiction series. Thanks for your excellent work thus far.

kevboh commented 2 years ago

@LucidToday that's helpful. I'm still thinking through how this would all work technically. As I don't use scene indentation in Scrivener, it's felt less pressing, but it's something I want to do.

alexito4 commented 2 years ago

Hi, I'm late to this thread as I've just started looking seriously at moving from Scrivener to Obsidian. Scrivener's great for organising writing content, not so much for the metadata surrounding it, i.e. world building, character arcs, and so forth. What I would love to see is the equivalent of Scrivener's binder, to support a hierarchy for organising scenes. For me that would be Series-Book-Act-Plot Point-Chapter-Scene, although I realise other authors might structure things quite differently. Essentially I see a novel as being structured as a tree with scenes as the leaves, if that makes sense, so your option 2 of having separate metadata to track the structure would probably keep most people happy I think. Anyway, just some thoughts from an author who writes fiction series. Thanks for your excellent work thus far.

In a similar position right here. I would love to see support for Book/Part/Chapter/Scene sort of hierarchy. One thing I also used a lot on Scrivener is to have a "summary" on the chapters themselves. I know Obsidian doesn't have "notes on folders" directly but maybe if each level is a folder and each one has an "index" that could serve as a place to put summaries. (of course that would only be useful with a view that shows them 😂)

LucidToday commented 2 years ago

@alexito4 I get what you mean. What I've been doing in the meantime is constructing a series bible. I've got to the stage I can't remember who did what when, and the risk of continuity errors is rising by the day! What I've done is built my structure and in the scene notes instead of the actual scene, added metadata for what, when, where and who - i.e. a sentence describing what happened, when it happened, the setting and which characters were involved. Then I use Dataview to query the notes and produce a synopsis of the book. It can also be used to show for each character what they did, where and when, i.e. their arc. I could also slice by date and setting, although I haven't found a use for that yet. The only thing missing is the actual scene text, but hopefully that will come one day.

GamerGirlandCo commented 2 years ago

so, i tried (and failed miserably) to refactor this plugin to have a hierarchy like draft(folder) -> chapter(folder) -> scene(note). @kevboh could you throw me a bone? getting the sortable bits to work nice with a nested hierarchy was a pain, and at best i could get it half-working (i.e., reordering scenes did nothing to the index file). i also really don't understand how to get the index's frontmatter to reflect this new filesystem structure -- i had to do this hacky $projectMetadata.set({...}) thing in folder-observer.ts because i couldn't figure out any other way to get it to do what i wanted. tl;dr: i'm trying to help but i don't know how

akadormouse commented 2 years ago

It would be a different design, but I would point out that the (beta, needs BRAT) Bartender plugin allows notes and folders to be sequenced manually. Better File Links allows all those files to be embedded into a document (much easier to publish a single file that is already in the right sequence). It might be possible to use those two within a longform system.

Just an idea.

GamerGirlandCo commented 2 years ago

so, i tried (and failed miserably) to refactor this plugin to have a hierarchy like draft(folder) -> chapter(folder) -> scene(note). @kevboh could you throw me a bone? getting the sortable bits to work nice with a nested hierarchy was a pain, and at best i could get it half-working (i.e., reordering scenes did nothing to the index file). i also really don't understand how to get the index's frontmatter to reflect this new filesystem structure -- i had to do this hacky $projectMetadata.set({...}) thing in folder-observer.ts because i couldn't figure out any other way to get it to do what i wanted. tl;dr: i'm trying to help but i don't know how

update! i managed to get the new hierarchy working with the explorer pane and index file. check out my fork here ! give it a try, let me know what works/what doesn't, all that good stuff. DO NOTE, the code behind compile workflows still needs to be refactored. i'm working on that.

some notable, potentially breaking changes you might want to be aware of (this is quite long) - there is a new dependency -- `@jhubbardsf/svelte-sortablejs`. this is because i noticed that a wrapper component (`SortableList.svelte`) had been created and svelte would complain when i tried to bind it to the `scene` property of `item`, due to how `item` was declared (`cannot bind to a variable declared with the let directive`). (`Error: cannot bind to a variable declared with the let directive`) it does essentially the same thing - there are 2 new svelte components ([`NewSortableList`](https://github.com/GamerGirlandCo/longform/blob/refactor/src/view/sortable/NewSortableList.svelte) and [`SortableSceneList`](https://github.com/GamerGirlandCo/longform/blob/refactor/src/view/sortable/SortableSceneList.svelte)) for the drag-and-drop bits in the scenes tab, which also now contain chapters - i added/modified some types ([diff](https://github.com/kevboh/longform/compare/main...GamerGirlandCo:longform:refactor#diff-7099163a571a9d25fcc95e49c1de2185cd457e753487079353c674b969bdf46f)) - there is now a "chapter" type, which contains an array of "scenes". - note that the reason why i called the Scene interface `RecursedSceneMetadata` was because i thought i could arbitrarily nest scenes within each other and didn't take into account the underlying filesystem. do excuse that! - the folder observer has been [reworked](https://github.com/kevboh/longform/compare/main...GamerGirlandCo:longform:refactor#diff-ffcc51ceaffea9e9f25aa04d18cf4e863552b3d55e04d1f165f24f7ed6311530) to be compatible with the `draft->chapter->scene` hierarchy. - separate context menus and click listeners for chapters and scenes ([diff](https://github.com/kevboh/longform/compare/main...GamerGirlandCo:longform:refactor#diff-56e8f298fdcf91db78b0de375e07828928c837440ea001fb0b700ff2e1a8010d)) - `manifest.json` has been changed for development purposes on my end. if/when this refactor is given a green light, i will change the plugin id, name, etc back to their original values.

i hope this is a step in the right direction 😅

kevboh commented 2 years ago

I’m totally rewriting how all this code works as part of #35, including adding this feature. You’re welcome to fork and implement your own, but I don’t plan on accepting an external PR for this.

GamerGirlandCo commented 2 years ago

I’m totally rewriting how all this code works as part of #35, including adding this feature.

that's great!! honestly, the less coding i have to do, the better :P could you make something to track how far you've come/how much there is left to do? or are you still in the "thinking" phase?

apologies for the trouble, by the way. if i had known you were actively working on an overhaul, i wouldn't have posted that 😅

kevboh commented 2 years ago

could you make something to track how far you've come

I don't know if I could keep something like that reasonably up-to-date without being a drag; this isn't my full-time job, but is something I actively use and work on when life allows.

or are you still in the "thinking" phase?

No, I have the core of project tracking mostly rewritten, barring a few features, and am in the process of switching the frontend to use the new code.

If it helps, here my planned format for indented scenes in the index file:

  scenes:
    - first
    - second
    - - indented
      - - indentedMore

No folders are involved; each of those lines corresponds to a note and they're all siblings of each other in terms of actual folder hierarchy. I may look into the ability to create a scene called, say, subfolder/scene-name, and in doing so create a folder named subfolder, but at some point with this sort of thing I run up against the huge diversity of working styles people have, and the only real solution is to pick one and stick to it.

Are folders inside the draft a requirement of yours, or just how you chose to implement this?

GamerGirlandCo commented 2 years ago

Are folders inside the draft a requirement of yours, or just how you chose to implement this?

nope, it's simply how i chose to implement it, simply because i really didn't know how else to do so. in other words, it was admittedly a lack of skill (i just graduated from high school, for reference) combined with wanting to be proactive instead of just "waiting around" for someone to do it for me. that, and a severe lack of motivation to do anything else.

kevboh commented 2 years ago

i just graduated from high school, for reference

congrats! super impressive that just after high school you can dive into an unfamiliar codebase and make progress, that's amazing.

GamerGirlandCo commented 2 years ago

thank you! it was definitely a challenging endeavour, but i'm glad i took it on :)

kevboh commented 2 years ago

For those waiting for this feature: you can now beta-test it using BRAT and entering kevboh/longform to install a beta of 2.0.

chrismelbourne commented 2 years ago

Hi, I've enabled kevboh/longform on BRAT, and when I click the Longform tab on the sidebar, I get the message to "Migrate". But the "Migrate" button doesn't allow me to press it (doesn't turn clickable). When I click anyway, it sort of turns a little grey quickly, but nothing else happens. https://www.screencast.com/t/riZlcHzQ

I've restarted Obsidian a few times too, same result. Any ideas?

kevboh commented 2 years ago

@chrismelbourne weird! There's no disabled state for that button in the code...

Do the developer tools (cmd-shift-i) show any errors? Is there a way you can share the contents of your .obsidian/plugins/longform/data.json file with me?

ReaderGuy42 commented 2 years ago

For those waiting for this feature: you can now beta-test it using BRAT and entering kevboh/longform to install a beta of 2.0.

@kevboh I've just tried this, but I can't select a folder as Longform project. I did the migrate thing, and then I see the regular Longform sidebar, with a TODO under Word Count, but when I go to right click a folder, the "Mark as . . . " option isn't there. I've restarted the program and the vault a few times.

kevboh commented 2 years ago

@ReaderGuy42 yes, it's gone and it's intentional. See README.

kevboh commented 2 years ago

To expand a bit: Longform now searches all notes for specific frontmatter, and treats those notes as index files. No more marking/unmarking folders. It has two commands for inserting the correct frontmatter into notes.

ReaderGuy42 commented 2 years ago

Ah, that's cool, thank you!

ReaderGuy42 commented 2 years ago

So this 2.0 looks great! I really like the indenting thing! 2 things that I've noticed that might be worth mentioning here:

if you mess up and delete the frontmatter from a note, you need to restart the whole program for you to get the option to add the front matter again. Would that be possible to change? So like I took a few tries that the Index file needs to be separate and not a superordinate file of your choosing, meaning I put the multi-scene frontmatter into my first scene instead of a file with only that in it. When I deleted that frontmatter from the scene I still only got the option to add in the frontmatter in another scene once I had restarted Obsidian.

And the other thing, which might just be a me thing: Would it be possible to add support for subfolders? So like you have a folder with your index file and in that folder you have subfolders which Longform searches recursively for the frontmatter? While I think the indenting of scenes in Longform is great, that structure only applies to the file explorer in the Longform view, not in the default one, meaning that in the latter view I just have a long list of scenes. I like to have subfolders as I find that easier to navigate. E.g. you have folder A and then in A you have subfolders 1, 2, and 3, which each include a few chapters.

Thanks :)

chrismelbourne commented 2 years ago

Do the developer tools (cmd-shift-i) show any errors?

@kevboh Hi, the dev console gave the following errors:

Uncaught (in promise) Error: Folder already exists. at t. (app.js:1:974056) at app.js:1:235078 at Object.next (app.js:1:235183) at s (app.js:1:233922)

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'frontmatter') at eval (plugin:longform:30706:35) at Generator.next () at eval (plugin:longform:31:71) at new Promise () at __awaiter (plugin:longform:27:12) at migrate (plugin:longform:30686:12) at eval (plugin:longform:31789:17) at HTMLButtonElement.doMigration (plugin:longform:31667:3)

Thanks for looking into this.

kevboh commented 2 years ago

@ReaderGuy42 great catch on the frontmatter thing. I filed a bug for it: https://github.com/kevboh/longform/issues/75. I'll also try to make it more clear in Longform's docs and commands that multi-scene index files are like a table of contents and not the first scene. For folders....it's complicated. It adds a ton of complexity; the regular file explorer will always be less-than-useful for looking at manuscripts, since your scenes will never be in order. One thing I can look at is supporting paths as scene entries (e.g. my-folder/my-scene in the index file) and then showing that folder in the Longform pane, but even that will probably come after a 2.0 release.

@chrismelbourne This is very helpful. I'll see if I can reproduce it. There are also instructions for migrating manually if you're interested in trying that, up to you.

Thank you both for testing!

ReaderGuy42 commented 2 years ago

OK, no worries! I found a solution that I can work with, or actually that I'd been already working with, but 2.0 still makes it easier. I have a regular vault with all my folders and whatever, and then a secondary vault where I have links to the actual scenes. The secondary vault as a whole just acts as one big Longform folder.

Thanks for the info!!

yogeshwersharma commented 2 years ago

I was about to make a comment regarding my "loss of previous index file", but somehow, I am not able to find my comment here, and @kevboh's response.

Anyway, in short.

Thanks @kevboh again, and sorry for taking long in responding. Great work.

kevboh commented 2 years ago

This is fixed in the current 2.0 beta and will reach production in the near future; see https://github.com/kevboh/longform/issues/35 for details. Closing this issue as it’s tracked in the linked one.