Closed chrisgrieser closed 2 years ago
I've definitely thought about this. It's not a short-term goal, but it's on my radar for sure.
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!
...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
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.
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:
#
, ##
, 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.
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.
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.
I agree with @chrisgrieser, personally, I don't like having too much stuff in a single file.
@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.
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.
@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.
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.
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.
@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.
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 😂)
@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.
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
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.
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 infolder-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.
i hope this is a step in the right direction 😅
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.
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 😅
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?
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.
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.
thank you! it was definitely a challenging endeavour, but i'm glad i took it on :)
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.
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?
@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?
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.
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.
Ah, that's cool, thank you!
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 :)
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.
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'frontmatter')
at eval (plugin:longform:30706:35)
at Generator.next (
Thanks for looking into this.
@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!
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!!
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.
The scenes there were earlier present disappeared from index file after migrating. But upon restarting, there was an option to add them back in.
For the vim support, it seems to working again now. Not sure what happened. But earlier, I was not able to enter the "insert mode". Pressing "i" was going to insert mode momentarily and then back to normal mode immediately.
Thanks @kevboh again, and sorry for taking long in responding. Great work.
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.
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.