Option to create a new note in the current directory

Feature archive
#1

[Plugin or integral feature?]

Currently if you create a link [[foo]] and foo doesn’t exist, cmd-clicking on it creates a new note in the vault root, even if the referencing note is in a subdir. Such an option will create the new file in the same dir. as the referencing note.

The file explorer allows creating a new note in a subdir if you right click on the subdir name, so I suppose instead of cmd-clicking on the link, you can first create a new file in the same dir, rename it, switch back to the referencing node but it should be possible to combine this in one keystroke!

13 Likes
Not sure I understand the vault/folders relationship. Please, help!
Not sure I understand the vault/folders relationship. Please, help!
#2

At first I thought the same and was annoyed that all new notes go to root. The root starts to look clutterd. But then I realised that I would probably create a great number of notes in the wrong folders and lose track of them if this setting was active. In my workflow it would add more chaos than order. But I guess a user setting would provide the choice for different work flows.

3 Likes
#3

There will be no chaos at all. There should be a simple rule: notes, created by [[internal links]] should be created in the same folder, where the referencing (parent) note resides, until user explicitly specify other location ([[…/internal link]], or [[./subfolder/internal ling]]).

@goodsignal, with such a rule you will never accidentally create a note in the wrong folder, right?

#4

Personally, lack of such an obvious rule is a show stopper for me… ;(

2 Likes
#5

Actually, I would create notes in the wrong folder all the time based on that rule! I may be interpreting what you want incorrectly, but it seems like you are making an assumption that the user will always be creating notes of the same type from any given note. But that’s a pretty constrained workflow limitation and I don’t think people work that way except for some specific situations that call for it.

Consider this example:

1388×854 122 KB

Under your rules, every one of these links would be created in my Daily Page folder. Whereas only 3 of the roughly 17 pages generated should go in the Daily Page folder. Then I would have to remember that there were a bunch of pages generated in the wrong place for every directory I had been working in, then traverse through my folder structure to hunt for misplaced notes rather than know that all of them are in once place and I just have to organize from one directory of new notes.

But again, if it’s a user setting that can be on or off, like you’ve requested, I wouldn’t have to turn it on.

1 Like
#6

I would consider a setting that you have to go change whenever you want to switch back and forth as pretty inconvenient considering my workflow.

However, if I know that 3 of the 17 files I’m creating should go into my current directory It would be nice to have an easy way to do that on a case-by-case basis. I could see using a key combination that tells Obsidian to save this new note in the current directory. Something like this:

Instead of this
[[New Note that gets saved in root]]

We could do this
[[…/New Note that should get saved in current working directory]]

Prefacing the title with the linux standard for current directory could be what tells Obsidian to to save in the current directory so we don’t have to reorganize it later.

I would love that!

#7

Yes, you are right.
But I don’t like the ‘global’ user setting as well, because it will not solve the issue.
Looks like this should be a folder-level setting: for a folder Daily Page the option Create [[internal link]] notes in the vault root should be On (by default). But you can disable it for other folders when needed.
Is it better?

#8

I could see a plugin helping to manage this with folder by folder preference. Something that watches all new notes and automatically moves them to where you are depending on what you’ve set for that folder.

I definitely feel similar pain points as you. Yesterday I requested this

It deals with a related issue. I don’t want my notes that obviously have a specific home to not go where they belong.

#9

Sorry, I was answering your previous message.

I like the ‘folder prefix’ idea, but I don’t like that the prefix will be visually added to links: instead of just names list

[[Mark Twain]]
[[Charles Dickens]]
[[Jerome David Salinger]]

I’ll get something like this:

[[./Mark Twain]]
[[./Charles Dickens]]
[[./Jerome David Salinger]]

But you recent automatic notes sorting idea is very powerful, close to ideal solution! Highly support this!

Looks like vault/folder relationship is an interesting and difficult issue. For example, in Scrapbox there is no ‘folder’ concept at all. All notes are in the root of a project. And project is something like Obsidian’s vault. But there is a list of available projects, so you can quickly switch between them.

There is a vault and folder entity in Obsidian, but I still do not understand how the devs are planning to handle it…

Is there a way to ask the devs to chime here and bring the lite to the issue?

#10

I actually really like @goodsignal’s line of thought with specifying file paths in the links to achieve the desired result. I’m doing that anyway because I’m hoping to use vimwiki and Obsidian concurrently, and vimwiki’s not quite as clever about finding things if you don’t specify folder paths. (I just experimented: it does work in Obsidian, though not if I start using relative paths, which will be an issue for me eventually.) Increased support for that would be a great plugin that I would definitely use! One could perhaps offer a setting or markup to conceal the extra information, if one was worried about visual clutter.

#11

Is there a way to ask the devs to chime here and bring the lite to the issue?

Yeah, they are pretty active on the Obsidian Discord. And they seem to chime in on the forum here as they get to each issue. You’ll probably get a reply here eventually.

I like the ‘folder prefix’ idea, but I don’t like that the prefix will be visually added to links

I completely agree. I would hope that the prefix combination would automatically disappear as soon as the file was generated in the right place, leaving just the intended title.

Looks like vault/folder relationship is an interesting and difficult issue. For example, in Scrapbox there is no ‘folder’ concept at all. All notes are in the root of a project.

I really like having some control over folder organization. My OCD side has a really hard time being okay with throwing everything in one place. I understand that there are other ways to manage and find what we need and I kind of wish that I could embrace that mindset. But whenever I try, I find that my work doesn’t go very far. I end up not doing work simply because I feel like every new file I create is creating a bigger mess.

#12

Asked them on Discord to answer here or on Discord. Let’s see…

#13

I asked earlier for a feature to be set in preferences where new pages land, existing folder for the currently focused page, vault root folder, or a defined folder defined by the user (like incoming). There could then be possible key bindings to override this behavior.

#14

@Licat, @Silver: please, find several minutes to tell us your developers vision of this vault/folder relation issue. Thank you!

#15

We will add an option for “Root”, “Same folder”, or “Specified folder ____”.

6 Likes
#16

Few notes.

The vaults are there because some users have expressed the desire to have separate silos for disjoint/separate/independent set of notes. You don’t have to use them, if they don’t fit your workflow.

The folders are a convenience within a vault. They can be used for keeping all the daily notes together or to define a namespace.
Again, you don’t have to use folders if they don’t fit your workflow or you feel axious about putting files in them.
Personally, I don’t think it is a good idea to use folders to express (and enforce) a hierarchical organization (especially a deep hierarchy).

An alternative way for expressing structure in your notes is creating index notes (or structure note in the zettelkasten approach). That is, a note that contains a structured list of links to other notes.

@goodsignal you may want to try to completely disable the file explor view, if it helps your focus.

1 Like
#17

If there’s any better ideas please discuss! I don’t think I can cover all cases so there’s definitely some good ideas I miss.

#18

@Licat Choosing to create a Note to the current directory on a per instance basis sounds pretty useful for those of us who do directory organization. It means there’s less to drag’n’drop later. @Valery_Kondakoff made a really good point against my earlier suggestion to add some prefix to the filename. That it would cause naming issues, which is probably true. But what if something like
[-[New Note]]
was recognized by Obsidain to save in the current directory instead of the default directory. Seems like key combinations like that are pretty easy to program, as there are already quite a few of those. Also, I’m pretty okay with how Notes are currently saved. It would just be a nice bonus to have an easy per-instance option.

@WhiteNoise Whew! That would be interesting to experiment with, specifically because it’s out of my comfort zone. But I really don’t see how it’s a benefit. It seems to me that the overhead of having to do extra backlinking and creating additional index notes or table-of-content notes is more work than dragging notes into a basic file structure. And it seems so easy for too many Notes to get lost in the rubble without any attention given to keeping a simple, clean file structure. But I remain curious. @WhiteNoise, do you have any links to literature that elaborates on the philosophy of ignoring order on that level? I like to at least try being open to different paradigms.

#19

You can use the “Root” option if you don’t want to use any folders!

#20

While all the files in the same folder and using labels is one way to do knowledge management, you could easily get file clashes, and to avoid this you need to name the files with a prefix or some other name space which makes the names not directly usable as links without using a second display name for the links.