novelWriter 2 Ideas Thread

[vkbo]

Background

I initially developed novelWriter for myself and a colleague (@Number042). There was no concrete development plan and we just came up with nice-to-have features as we discussed them over lunch or coffee. Since then, a lot has changed based on user feedback, and it's become a bit more of a serious project. Due to this backstory, there are a lot of redundant features in novelWriter that are partially legacy features. Some of them make things a bit more complicated than strictly necessary.

For instance, due to the plain text and markdown-like properties of the editor, a lot of the requested features cannot be implemented in a simple and user-friendly way. Every feature would require some clunky and esoteric notation. There are better ways to accomplish these things and Qt is plenty flexible enough to do it properly. But it would require some fundamental changes to novelWriter that would, among other things, require a different project file structure.

I want to start looking ahead a bit to what would be a suitable set of features for a novelWriter 2.0. Both based on my own list of nice-to-have features, and user feedback and requests.

Ideas for Main Changes

New Editor

The core of the changes I propose is a new editor. It will remain simple, but it will allow a limited amount of rich text. The file heading and the keyword tags will be moved into a header with pre-defined editable areas. I want something similar to what Scrite does.

The document body will allow for the current features, but will use proper bold/italic/underline/strikeout/etc instead of markdown-like syntax. Each paragraph of the text can also have style properties, like left/right/centre alignment, and other block formats.

I will allow one type of heading within the document as it is still useful to serve as a split location for splitting a chapter document into scenes, but in general, the new editor will expect that the project is split up into either scenes of chapter files. This reduces the complicated nature of all the various current layouts. I will still allow for partition dividers and unnumbered sections, but all of this will be controlled by a document setting rather than defined by the level of the header within it. This reduces the duality that currently exists.

Note files will have a similar layout where the main title and the note's tag will be in the header. The text will allow the same four levels of headers it currently does.

File Format

The file format will still be plain text, but the paragraphs (lines) in the text will have a block format tag and potential in-line tags for emphasised text fragments. The files will thus no longer be practical for the user to edit externally, but can still be diffed and version controlled. The files were never meant to be edited externally anyway.

I've already come up with a suitable file format based on a square bracket region ahead of the text defining the block format, and curly bracket tags within the text wrapping text fragments. The latter is especially convenient because that is also exactly how Open Document files are written, so the ODT conversion becomes trivial. It also simplifies HTML conversion.

Consequences

The main consequences here are that many requested features can be implemented. The downside is a bit slower loading and saving time for documents, but for reasonably sized scene-size files it is a non-issue.

Existing Feature Requests

Here's a list of some feature requests that can be accommodated in novelWriter 2.0 with a new, minimal rich-text editor:

• Multi-document editing and rendering (Add support for editing and rendering multiple documents at once #102): While editing multiple files in the same editor window may be difficult, allowing more than one open editor window would be possible. For instance, making the right panel able to hold either a second editor or the current viewer, would be possible. Rendering multiple documents in the viewer is certainly doable.
• Footnotes (Footnotes #342): The footnotes of a file can be encoded in meta tags and saved at the bottom of the file, since each block is anyway encoded. They can also be multiple paragraphs, and can easily be referenced within the text with a formatting tag.
• Expand/collapse (Show and Hide Text Feature #399, Headings collapse / expand #513): These are potentially doable since it will be possible to save the visible state of paragraphs and sections in the file. Hiding fragments of the text isn't really practical still.
• Block quotes (Block Quotes #595): With a way to encode block formats, this is trivial.
• Text highlighting (Add Support for <mark> #352, Highlighting a fragment #705): Highlighting now becomes trivial to implement as well.
• Text notes (Highlighting a fragment #705): It now also becomes quite doable to allow adding notes to highlighted text. the notes can be saved as meta tags at the bottom of the file, and associated with regions of text with the fragment encoding.

Lost Features

• The plain text nature will be lost, but all the current syntax highlighting features can still be retained. Especially the useful highlighting of quotes. Overall, the editor will look fairly similar aside from the missing bold/italic markdown markers.
• The meta data will be extracted into an editable header, so it will lose the current plain text feel as the meta data will need to be set in a more traditional point-and-click manner. However, I think some smart keyboard shortcuts can be added to populate this meta data as you type. Scrite, as I mentioned earlier has a feature to auto-detect characters in a scene. Due to the Fountain notation of screenwriting, this is simpler, but it can also be achieved by adding a keyboard shortcut that will try to look up a meta data tag when the cursor is on it by say for instance pressing Ctrl + or something similar.
• Notes will no longer allow multiple tags to specific regions of the document. Only one tag will be associated with each note.

Additional Benefits

• Rendering the documents will be significantly easier since they are practically rich text anyway. All that needs to be done is add the header and meta data to the viewed document.
• The current Tokenizer class can be almost entirely dropped and the HTML and ODT converters simplified a great deal. Especially the ODT converter as the new text format is very compatible with ODT paragraph layout. It is also close to how HTML works, and can in fact be done in the exact same way if I want to be lazy.
• The project overview can be simplified quite a bit since the file "layouts" can be reduced to "Title", "Partition", "Chapter", "Section", "Scene" and "Page", with each having a well defined structural meaning and the importance of header level within them dropped. That also means the "Novel" tree will be the main tree for the story content, and the notes tree will be separate as it will retain its folder/file structure.
• Additionally, we get a clean and clear distinction between a novel file and a note. They will live in separate trees and behave differently and look different in the editor.
• The complexity of the index can be significantly reduced since there is a many to one relationship between scenes and notes, and the tags are stored as meta data instead of in-text. The index is thus largely redundant.

novelWriter 1 to 2

I will probably keep novelWriter 1 alive and in an LTS state even if 2 is released. That means it will remain long term and get patches when needed, but no additional features. Users who prefer the current plain text style can keep using it.

A project converter will be added to convert nW 1 projects to nW 2 projects.

It is also possible I will do this in an entirely new application. I'm playing around with a lot of Qt6 features in C++ in another repository named Collett.

[vkbo]

This is also an invitation for feedback from users, and the usual suspects like @Number042, @jyhelle, @johnblommers, and others whose feature requests I've linked.

There is no definite timeline on this. I will likely take the opportunity to restructure large parts of the code as I've learned a lot about Qt over the last years, and there are numerous improvements to be made in the way I use the Qt library in the code.

I still have features to implement in the current iteration of novelWriter, and I want to get the main ones done before I start working on this. This is likely on a 1-2 year time frame.

[Uebby]

Hi,
That are good news !
I would really love a way to export all of my novel and notes in a plain text format at once. Durability is better in the long run.
I would appreciate to keep the whole themable interface, my eyes thanks you a lot!
I like having the Books from the same serie on the same project but actual structure does not allow it, would it be possible ?
I would like the possibility to add more than one kind of @Custom metadata as well.
I would like to chose what informations to show UP under thé tree like pov instead of paragraphes for exemple or to hide it also.
Thanks you very much for your software !

[vkbo]

I would really love a way to export all of my novel and notes in a plain text format at once. Durability is better in the long run.

It used to have plain text export, but I removed it. You can export to markdown though, which is pretty close.

I would appreciate to keep the whole themable interface, my eyes thanks you a lot!

I will definitely keep it themable. My eyes do a lot better with dark themes, so I depend on it myself.

I like having the Books from the same serie on the same project but actual structure does not allow it, would it be possible ?

It is not designed for this, but you can in principle put books in folders under the novel tab. You can either export them all and split the document, or switch off the export tags on the files you want excluded. I've been meaning to add a feature to toggle the flag on many files in bulk, like for instance all files in a folder. I should probably add it to my list of features.

I would like the possibility to add more than one kind of @Custom metadata as well.

You can add multiple custom folders, but they all use the @custom reference tag that's all.

I would like to chose what informations to show UP under thé tree like pov instead of paragraphes for exemple or to hide it also.

That is what the "Novel" tree tab is for. It currently shows the POV character, but I plan to make it selectable. Hiding the panel could be an option to add for sure. Please make a new feature request about it and I'll add it to my queue of things to do.

Thanks you very much for your software !

You're welcome!

[jyhelle]

(I apologize for the delay in answering, I have been real busy over the last week.)

A lot of your proposed features are on the programming/file structure side, and these I won´t discuss so much as I think the programmer should use the tools and structures she prefers to get the result she wants.

I have been a champion of Wordstar's diamond combinations, then moved to Wordperfect, now using Markdown but also capable with WISIWIG tools, so the exact way of inputting the text and getting it the way I want after exportation is something I'll adapt to.

Basically, I think your proposed way of evolution doesn't have much impact on what is for me the core of nW, i.e. the multi referencing scheme provided by the tags references and note files. This was important with my first tries of nW, now that I embark on a much much larger project, it becomes of uttermost importance.
Anyway, if I remember only one phrase from your text it will be : "A project converter will be added to convert 1.0 projects to 2.0 projects."

So, please make nW evolve for the best: faster, better, safer, I'll gladly keep testing and reporting any problem I encounter.

[vkbo]

I admit that I do like the plain text nature of novelWriter. But as a programmer I'm used to working with coded syntax instead of depending on elaborate GUIs to do the things I want. Often, GUIs tend to be more restrictive in that they lock you into a specific way of working. I've written a lot of academic papers and two theses in LaTeX, and I greatly enjoy the flexibility such tools provide and I don't at all mind having to use commands to lay out my text.

Add to that the idea that writing the novel and applying formatting and layout should be treated as two separate things, then the current approach to dealing with as plain text as possible is a reasonable philosophy. Especially since the project now can be exported to a proper word processor document which can be formatted in all sorts of presentable ways.

My main concern is really all the feature requests that cannot be easily implemented since the editor is not rich text. It is partially why I started on a second editor. I am beginning to lean towards keeping novelWriter plain text and instead build a separate rich text editor in the Collett project. To be fair, I quite enjoy working on it and working in C++ again. It may be a better option than start changing direction of novelWriter.

I'm going back in the thinking box on this!

[TechGnome]

As long as you're taking ideas for 2.0 ... being able to set up templates - in addition to the 3 samples that come out of the box.
Use case: I just spent 20 minutes setting up my current project to use a layout format based on the Save the Cat beat ... which involved a lot of copying & pasting. It would be nice to 1) Save this off as a template so that if I wanted to use it as a base for additional projects, I could, and 2) it could be shared with others wanting to do the same.

[vkbo]

That is a very good idea. @jyhelle has suggested something similar in the past. I too have a sort of template I use.

The functionality that generates the sample project can easily be modified to load a template from a zip file. I am planning to add a project export feature anyway, and I can easily add an option to write a template zip from a project as well.

There's no reason to wait for a 2.0 for this addition. I can add it in a minor release too. Would you mind making a feature request issue on this? You can pretty much just copy/paste what you wrote already.

[TechGnome]

Submitted - #841

[tmarplatt]

Something I wish text editors did is treat selected text the same way IDEs do when it comes to markup wrapping.

For example, I select a whole line and hit the double quote key ", and nW simply wraps the selected line with opening and closing double quotes. Same goes for bold, italics, etc. wrapper markup. You just select text and hit a key (*, _, etc). No need for hotkeys either. Treat inputting an opening character as if the user was signalling the intention to wrap.

That, to me, is a killer feature right there :) Compare it with the tedious (and stream-of-thought breaking) cursor navigation to enter markup.

[vkbo]

Well, there are hotkeys for all of those. Ctrl+" and Ctrl+' should work too. Bold and italic work with Ctrl+B and Ctrl+I as is standard.

I considered doing what you suggest, but most people who write don't code, so I thought it might be an unexpected functionality, but I have considered making it an option.

[D4gma]

I'm still exploring nW but I'm loving it.

Some suggestions:

• Under project details, the table of contents could include some writing stats per chapter (or sections, or pages). How many hours I spent on chapter 3/ how much idle time and such. Not necessary at all, but those are some nice to know details when you - finally - finish a project.
• Images into notes. Why? I personally take quick hand-drawn notes on the go with my phone, or take a screenshot for an idea on a character look. It would be nice to link characters note with a sort of "avatar", or locations with a beautiful place captured on wikipedia.
• Included flag: I'd prefer it turned off. Before start writing a new project (or importing an old one into nW) I spend a lot of time organizing characters, timeline, locations, notes etc. All those items should not count towards the novel word count. When I'm writing the novel itself, instead, it's hard to forget to switch the toggle on, so it would be nice to have an option to set the default toggle on or off.
• Project overview: custom sort order for columns (words, toggle, status). I noticed every time I open nW they revert back to the original order. I use the app mostly as a 'small' window on desktop (rarely full-screen and focus mode, it's hard to live with a lot of folks walking around you...) and I prefer to have the colored status at a glance instead of the word count.
  Regarding the status/importance colored flag: a dropdown menu to quickly set the status would be great!
• Italian translation, maybe? Hey, look at me. I'll gladly give you all the help I can!

I don't know if these are silly ideas (I'm not into coding) and I'm really sorry if one or more of those features are already there, I'm still new to the app. Anyway this app can only improve so I'm impatient to try the new versions.

[vkbo]

I'm still exploring nW but I'm loving it.

Glad to hear it! :)

Some suggestions:

• Under project details, the table of contents could include some writing stats per chapter (or sections, or pages). How many hours I spent on chapter 3/ how much idle time and such. Not necessary at all, but those are some nice to know details when you - finally - finish a project.

That is potentially a lot of data to collect. Aggregating time spent editing each file is not so difficult, neither is revision count. Perhaps those are sufficient. Logging activity per file would require a log file for each document, and a lot of logic to start/stop the timing.

• Images into notes. Why? I personally take quick hand-drawn notes on the go with my phone, or take a screenshot for an idea on a character look. It would be nice to link characters note with a sort of "avatar", or locations with a beautiful place captured on wikipedia.

novelWriter is not meant to be used for research. Creating a full note taking app within novelWriter is not something I really want to do because it is a lot of work. Especially since it is a plain text editor. The notes are intended for character profiles and plot outlines, etc. See sticky issue #815 for more details.

• Included flag: I'd prefer it turned off. Before start writing a new project (or importing an old one into nW) I spend a lot of time organizing characters, timeline, locations, notes etc. All those items should not count towards the novel word count. When I'm writing the novel itself, instead, it's hard to forget to switch the toggle on, so it would be nice to have an option to set the default toggle on or off.

The included flag only affects what documents are by default included in the export build. You can filter notes and novel content independently in the build tool, and also override the include flag if you wish. You can play around with the preview option in the Build Tool to see how the various filters affect the result.

The include flag has no effect on word count or anything else in the main window. If you want the total word count on the status bar to only show words in the novel part of the project, there is a setting in Preferences on the Editor tab to enable/disable including word counts from notes. You can also see the total word count and chapter counts of the included novel files on the Project Details panel. This is the best tool for checking the progress of the content intended for the final novel.

• Project overview: custom sort order for columns (words, toggle, status). I noticed every time I open nW they revert back to the original order. I use the app mostly as a 'small' window on desktop (rarely full-screen and focus mode, it's hard to live with a lot of folks walking around you...) and I prefer to have the colored status at a glance instead of the word count.

Actually, you're not supposed to be able to reorder those columns. That's a bug, although a trivial one. That's why the order is not saved. I could look into adding more options to customise it. Please make a new feature request for this, otherwise I will forget.

Regarding the status/importance colored flag: a dropdown menu to quickly set the status would be great!

I've considered this before. Please include it in the feature request for the point above, if you make one. It's a good idea.

• Italian translation, maybe? Hey, look at me. I'll gladly give you all the help I can!

Sure, an Italian translation would be great! The instructions are here: https://github.com/vkbo/novelWriter/tree/main/i18n

I don't know if these are silly ideas (I'm not into coding) and I'm really sorry if one or more of those features are already there, I'm still new to the app. Anyway this app can only improve so I'm impatient to try the new versions.

[mvdkleijn]

Just to clarify here... Is Crowdin the way forward for translators? I already use it for a couple of other apps I contribute to, so this would tie in nicely.

edit - meant for #93 , I'll post it there too and leave it here as it's kinda on topic.

[nyex]

After using novelWriter intensely for a few days, here are a few ideas:

• some kind of quick export feature: I always export to the same markdown and overwrite the previous markdown file, since I'm publishing my novel as an 'open book' on a git repo as I write. It would be awesome if there was some kind of quick 're-export' function, to maybe re-do the previous export action. Maybe, to avoid mistakes, it could still have a dialog warning that something will be overwritten? Or, even: a user-defined quick export to be re-used etc? Does that make sense?

• any chance for scripting abilities? I mean: command line options to export or open a specific project directly?

• I quite like writing in markdown (mostly hitting ctrl-something for italics makes my brain stop in its tracks mid-sentence); not sure I would love 'proper' formatting. Any chance that could be made optional, somehow?

• the only one thing I quite like from other writing programs is the ability to see chapters/documents as cards. Definitely not something I absolutely must have, but I do wonder what you think about it.

Again: this program is great <3 I've been writing like mad lately and I think you're partially to blame ;)

[vkbo]

After using novelWriter intensely for a few days, here are a few ideas:

• some kind of quick export feature: I always export to the same markdown and overwrite the previous markdown file, since I'm publishing my novel as an 'open book' on a git repo as I write. It would be awesome if there was some kind of quick 're-export' function, to maybe re-do the previous export action. Maybe, to avoid mistakes, it could still have a dialog warning that something will be overwritten? Or, even: a user-defined quick export to be re-used etc? Does that make sense?

I plan to make a bunch of improvements to the build tool. They will likely be included in the next release after the upcoming 1.7 release, so in a few months I would guess. One of my ideas is to let the user save build configs so that you can define your own presets for builds and add an import/export feature so you can keep a repository of them yourself to use between projects. This may serve your purpose.

I plan to expand the amount of build options quite a bit to better serve common cases like manuscript submission standards. Writing my own ODT file writer was the first step of that process, which I did a while ago.

• any chance for scripting abilities? I mean: command line options to export or open a specific project directly?

Sure, I'm a command line user myself, and so are a lot of other users I've noticed. You can already open a project directly from command line. Just provide the path to the project folder as the last argument, and you're good to go. There are a few other command line arguments available as well, but mostly for debugging purposes.

I don't think it should be too much work to add a build command to the command line, similar to what OpenOffice and LibreOffice can do. The source code is split into a core package that handles all of your project's data, and a set of GUI packages. This separation isn't 100%, but close enough that I should be able to make a command line only, or Python scripting-friendly importable API for doing builds. I will definitely consider the first, which is still quite scriptable.

The only issue here is that at present, the build tool is a GUI tool, not a core tool. It cannot run independently of the GUI. But I will keep this in mind when I refactor the code. It makes sense to separate the build engine out into a separate class. That will make this easier to implement as well.

• I quite like writing in markdown (mostly hitting ctrl-something for italics makes my brain stop in its tracks mid-sentence); not sure I would love 'proper' formatting. Any chance that could be made optional, somehow?

Proper formatting as in a WYSIWYG / rich editor? I've spent a lot of time thinking about it as a novelWriter 2.0 thing. As long as we're talking basic formatting, it can definitely be done. I am also working on a second application for writing using C++ that is such an editor from scratch, so I may end up keeping them separate and leave it to the user to pick their preference.

• the only one thing I quite like from other writing programs is the ability to see chapters/documents as cards. Definitely not something I absolutely must have, but I do wonder what you think about it.

It's a request that comes up from time to time. There are a few threads about visualisation of the project structure (see #76 and #854 for instance). Currently, this is done in the Outline tab, which is a very basic table view. I haven't yet decided where to go on this, and I'm definitely open to ideas.

Again: this program is great <3 I've been writing like mad lately and I think you're partially to blame ;)

😁

[nyex]

Oh, nice, this is all awesome to hear! Having build presets would definitely fit my needs.

I hadn't tried running it with the project path; will definitely create a shortcut for my novel with it now to save a click.

Thanks for the heads up :)

Proper formatting as in a WYSIWYG / rich editor? I've spent a lot of time thinking about it as a novelWriter 2.0 thing. As long as we're talking basic formatting, it can definitely be done. I am also working on a second application for writing using C++ that is such an editor from scratch, so I may end up keeping them separate and leave it to the user to pick their preference.

Oh, I meant the other way around: I read that you planned on having it on the 2.0 release and wondered if it would be possible to also keep formatting as it is, because I really like writing in markdown syntax <3

It's a request that comes up from time to time. There are a few threads about visualisation of the project structure (see #76 and #854 for instance). Currently, this is done in the Outline tab, which is a very basic table view. I haven't yet decided where to go on this, and I'm definitely open to ideas.

A friend recently showed me how this works in Scrivener, and it has the card view with both a summary of what's in the file and/or notes you can write on top of it which probably show up somewhere else when you have the file itself open. I think Scrivener is a bit too much overall, and in general for me it would be interesting just to have a card view that allows cards/files to be rearranged, like in the project tree view. Mostly because for me (and I imagine other people as well) I can visualize how chapters are related with a card view, rather than a list. Cards could have a bit of info about the file, like word count and status (and I suppose we could have them separated by root folder, so you would view the cards/files for one root folder at a time); having a way to see tags and synopsis could also be quite useful, because then you wouldn't need to create a whole new system for 'file notes', for instance, and we could use the synopsis to have an overall view of each chapter at a quick glance.

I read the ideas about timeline visualization; I recently had the need to do a timeline and ended up doing it on paper :-p I guess adding a proper timeline function would be definitely nice, but also a whole new feature. Maybe just starting with a card view would already add some cool possibilities?

I don't know anything about the technical difficulties of adding all this, since my programming skills stop at 'lazy bash scripts for automation', so I just throw these ideas there so see how they seem to you.

Also thanks for the detailed reply. I can't help with much other than translating (and I see Portuguese is already at 100%) and throwing ideas around, but definitely count on me for those.

[vkbo]

Oh, I meant the other way around: I read that you planned on having it on the 2.0 release and wondered if it would be possible to also keep formatting as it is, because I really like writing in markdown syntax <3

Ah, I see. I think if I did do this, I would do a hybrid solution, like convert the syntax on the fly to the correct emphasis or text alignment, but not much more. I would still keep the title and keyword syntax for instance, and probably also comments.

The idea was to not go full fixed with Markdown, but something that looks as close as possible to the intended look without requiring all the bulk and trimmings of a full rich text editor. Which I think mostly is a distraction anyway. My other project goes down that path, but still with a limited set of text features to keep it light. There are already plenty of multi-purpose word processors out there! This is what I dislike the most about Scrivener in fact.

A friend recently showed me how this works in Scrivener, and it has the card view with both a summary of what's in the file and/or notes you can write on top of it which probably show up somewhere else when you have the file itself open. I think Scrivener is a bit too much overall, and in general for me it would be interesting just to have a card view that allows cards/files to be rearranged, like in the project tree view. Mostly because for me (and I imagine other people as well) I can visualize how chapters are related with a card view, rather than a list. Cards could have a bit of info about the file, like word count and status (and I suppose we could have them separated by root folder, so you would view the cards/files for one root folder at a time); having a way to see tags and synopsis could also be quite useful, because then you wouldn't need to create a whole new system for 'file notes', for instance, and we could use the synopsis to have an overall view of each chapter at a quick glance.

That is essentially the functionality of the Outline tree view, just with cards instead. The main issue with drag and drop on the content level (i.e. chapter/scene) is that I don't require that the files are split in that manner. Drag and drop would then imply the ability to split and reorganise the content of files, which is something I'm a bit reluctant to do. I also don't want to force people to use one file per scene if they prefer one file per chapter, etc. Some writing styles mean you may not want to rearrange scenes in a chapter. While other people, like myself, write without much thought for chapter division at all. I work on acts and scenes.

I read the ideas about timeline visualization; I recently had the need to do a timeline and ended up doing it on paper :-p I guess adding a proper timeline function would be definitely nice, but also a whole new feature. Maybe just starting with a card view would already add some cool possibilities?

The problem is really to pick a visualisation that works, That has proven to be quite difficult. The two threads I linked are the best discussions so far. The oldest one is really just a summary of a chat over lunch with a colleague who then made the issue ticket 😄

Also thanks for the detailed reply. I can't help with much other than translating (and I see Portuguese is already at 100%) and throwing ideas around, but definitely count on me for those.

This is open source. Ideas are important because there isn't a team of designers discussing this in meetings. There is no way I could have come up with all the ideas that have gone into novelWriter on my own!

[nyex]

Ah, I see. I think if I did do this, I would do a hybrid solution, like convert the syntax on the fly to the correct emphasis or text alignment, but not much more. I would still keep the title and keyword syntax for instance, and probably also comments.

The idea was to not go full fixed with Markdown, but something that looks as close as possible to the intended look without requiring all the bulk and trimmings of a full rich text editor. Which I think mostly is a distraction anyway. My other project goes down that path, but still with a limited set of text features to keep it light. There are already plenty of multi-purpose word processors out there! This is what I dislike the most about Scrivener in fact.

Oh, this sounds good, actually :)

That is essentially the functionality of the Outline tree view, just with cards instead. The main issue with drag and drop on the content level (i.e. chapter/scene) is that I don't require that the files are split in that manner. Drag and drop would then imply the ability to split and reorganise the content of files, which is something I'm a bit reluctant to do. I also don't want to force people to use one file per scene if they prefer one file per chapter, etc. Some writing styles mean you may not want to rearrange scenes in a chapter. While other people, like myself, write without much thought for chapter division at all. I work on acts and scenes.

I see what you mean. I did mean the ability to reorganize and split content of files, yes, though I didn't mean in the sense that it would matter if they're organized in folders for chapters or scenes and whatnot. It would just be a card view for the files, whichever way the person chose to use the files for. In my head it would basically be what you said you are reluctant to do, yeah - reorganizing content in a card view.

But then I also usually just either have one big file for the whole book or divide it only in chapters (as in different files), so I guess if someone likes to organize things a bit more in folders and stuff things could get complicated.

I do see how this could be useful and maybe less complicated in the notes files, maybe?

The problem is really to pick a visualisation that works, That has proven to be quite difficult. The two threads I linked are the best discussions so far. The oldest one is really just a summary of a chat over lunch with a colleague who then made the issue ticket smile

Thinking about how novelwriter gives the tools but don't force you to write in a specific way - which I think it's the best thing about it - maybe there could be some kind of card-type root folder. I'll re-read the threads you linked and see if I can come up with a good enough explanation of this idea in a way that could make sense for the project.

(Also: just finished writing my book!)

[vkbo]

Congrats on finishing your book!

In the next version (1.7) it will be possible to add documents as child items of other documents, so you can use a chapter document with scene documents below it. This is yet another way to organise content. I will streamline the split and merge feature to fit this new format as well, which means it should be possible to plan the project at whatever level (act, chapter, scene) you want and then use the tool to change how they're organised.

Maybe a card view that represents this would be a solution. Like, each row represents a document or folder at a level you can select, and the sub-items run along the line after it.

[tmarplatt]

A quick re-build shortcut that uses the last used preset/options without prompts (yes, use at your own risk) sounds like such a good idea right now.

[vkbo]

You mean for the build? Sure, I can add that. It sounds quite useful. Please make a new feature request, and I'll throw it into the mix of features for 2.1.

[tmarplatt]

What do you think of semi-seamless document traversing from the Editor? Like this:

1. In the Editor, text cursor reaches the end of the document.
2. Users inputs Down, Page Down, and/or Ctrl + End.
3. Editor opens the next document in the document tree hiearchy, text cursor placed at the beggining of the document.

If the cursor is at the top and you hit the opposite keys/combos, the Editor traverses backwards instead. Text cursor will be placed at the end of the document.

This should possibly be limited to the same root folder, since you would normally only want to traverse a single tree like this.

[tmarplatt]

Dumping more ideas for cursor navigation in the Document Editor.

Amplify Home/End keys:

• Home currently only brings the cursor to the left margin (assuming ltr) in the current line. Another Home tap should bring the cursor to the beggining of the paragraph, in multiline paragraphs. A third Home tap could bring the cursor to the beggining of the section (last heading). A final fourth Home tap could also bring the cursor to the beggining of the file.
• Complement of the above with End key.
• In combination with Shift, allow this feature to expand text selection towards those anchors.

Implement paragraph traversal:

• Implement a hotkey to traverse paragraphs quickly. E.g. Something + Up Arrow or Something + Page Up takes you to the beggining of the previous paragraph; also the complement hotkey to traverse to the following paragraph. Combine this with the suggestion of my previous comment.

Motivation/Rationale: Right now, wanting precision with cursor traversal is an endless tapping of the arrow keys, and it is not so precise if you also want speed.

[vkbo]

Closing this old discussion issue. Many features have been implemented, and there will not be a novelWriter 2 (not 2.0) anyway. If I do move ahead with a rich text editor, it will be a new app entirely.