Just wondering if there was a way to create new subnotebooks in the terminal app? Was looking through the terminal docs and was not able to find that feature.
You can use the set command to set the notebook parent_id to another notebook.
I thought the set command was only used for notes? the documentation doesn't say anything about using set with notebooks, only notes? Do you have an example of how to do that?
You're right, I forgot it was only for notes. So at the moment it seems it's just not possible to create sub-notebook on the CLI, and you'd have to use the desktop app and sync. I guess the set command could be improved to deal with notebooks too.
If this feature were to be added is there a general time frame in which this functionality would be added?
Can we flesh out the specifics?
Shall we use the set command? If yes, what should the sub-command be? Or how would an example command look like?
What is the parent_id of the root folder? e.g. when we want to move a sub-notebook to the top level?
@tessus, I feel set is not very user friendly for this particular task. How about extending mv for this?
Currently it's like this:
mv <note> [notebook]
Moves the notes matching <note> to [notebook].
We could upgrade it to this:
mv <item> [notebook]
Moves the notes or notebooks matching <item> to [notebook].
How about it?
Edit:
And maybe with a special case:
mv <item> [notebook]
Moves the notes or notebooks matching <item> to [notebook].
When moving notebooks, use "/" as a destination to move it to the root.
@laurent22 This sounds like a great idea. I like it.
I hereby give others the chance to grab it. If nobody takes it for a week, I'll assign it to myself.
@laurent22 if you don't mind, I'd also like to change the mkbook command to allow an optional parent id. what do you think?
@laurent22 while looking into this, I came across a few problems. maybe you can help me understand them.
It is possible to have several notebooks with the same name. For my tests I use book1, book2, and book2. However, it seems that it is currently not possible to move a note from book1 to the second book2 (or from book2 to the other book2). Or am I missing something?
Furthermore, meta data is only displayed for notes, but not for folders, so using the id to move the notes doesn't work either. When using the metadata parent_id from an existing note, the mv command still does not accept a valid id as the destination.
I'm a bit puzzled how to solve this.
Maybe we have to come up with a way to handle folders with the same name first. Please advise.
@laurent22 if you don't mind, I'd also like to change the
mkbookcommand to allow an optional parent id. what do you think?
Yes that would work. Maybe an option -p, --parent <notebook>
It is possible to have several notebooks with the same name. For my tests I use book1, book2, and book2. However, it seems that it is currently not possible to move a note from book1 to the second book2 (or from book2 to the other book2). Or am I missing something?
You can using for example Note.moveToFolder but why do you want to move notes?
To move a notebook you can use Folder.moveToFolder
Furthermore, meta data is only displayed for notes, but not for folders, so using the id to move the notes doesn't work either. When using the metadata parent_id from an existing note, the mv command still does not accept a valid id as the destination.
You don't need to use the ID. It can be done by title too. But maybe we can also extend the cat command to display info about notebooks in order to get the ID.
You can using for example Note.moveToFolder but why do you want to move notes?
I'm looking at the current mv command, which I should change to allow to move folders. However, if I can't move a note to a folder (the problem I described with 2 folders with the same name), I won't be able to move a folder to a folder with the same name either.
The problem is that I currently cannot use an ID to move the note. But this has to be implemented, otherwise moving a folder would only work, if the target folder name is unique.
You don't need to use the ID. It can be done by title too.
Not when there are 2 or more folders with the same name. Ok, please create 3 folders:
book1
book2
book2
Now create a note in folder book1. Please try to move the note to the second book2 folder. As you can see, it doesn't work. So moving a folder won't work either.
All I am saying is that we should make it possible to also specify the folder id instead of the folder name to move a note/folder. Otherwise we have the problem above. But we can only do this, if there's a way to actually see the folder id somehow.
Ok, I am going to take it, but before starting on this we have to find a solution to the issues I described above.
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.
Still waiting for architectural input.
I'm interested in helping out with this issue in whatever way I can - feature parity is a linchpin that's kind of holding back Joplin from being a daily-use application for me. This issue specifically is a pain point for me as a heavy terminal user.
I have some broader questions about the architecture / responsibility split between the various clients though, that I think could provide a good baseline discussion for how to move forward in keeping feature parity between the clients. Is there somewhere better than individual git issues to get in touch/have a chat?
In the meantime, I will keep reading through the code and past issues/discussions to get some more context.
It's not the coding I need help with, although you are more than welcome to take it .
As mentioned a few times in this issue, we need architectural input from Laurent. But I think he's rather busy, so I'm not sure when we can expect this info.
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.
@laurent22 as soon as I have your input on
I can start working on it.
This would be a very useful feature, so I'm adding my comment here to bring this issue to the top. Hope that @laurent22 will be able to study your proposal!
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.
Still waiting for Laurent's input on the architectural questions.
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.
Still waiting for Laurent's input on the architectural questions.
If we change this:
mv <note> [notebook]
Moves the notes matching <note> to [notebook].
to this:
mv <source-item> <dest-item>
Moves the given child item to the given parent item.
And "item" can be an ID, a title, etc. Wouldn't that cover all cases? (including tags, if we ever merge the hierarchical tag feature)
As for getting the ID of an item, I'm open to suggestions. Maybe some key shortcut which, when pressed, display the IDs in the sidebar next to the titles?
It would temporarily turn this:
Project 1
Project 2
Holidays
Spain
France
Italy
Into this
f8a3f5 Work
277dac Project 1
5512fa Project 2
f6a0c4 Holidays
87f366 Spain
902afe France
ab981b Italy
(the CLI app supports entering only the first 6 characters of the ID)
Something like this for the IDs?
https://github.com/DominicLavery/joplin/commit/6428e669b294c6225d8ec487bc00bd0597765a23
Most helpful comment
If we change this:
to this:
And "item" can be an ID, a title, etc. Wouldn't that cover all cases? (including tags, if we ever merge the hierarchical tag feature)
As for getting the ID of an item, I'm open to suggestions. Maybe some key shortcut which, when pressed, display the IDs in the sidebar next to the titles?
It would temporarily turn this:
Into this
(the CLI app supports entering only the first 6 characters of the ID)