Still not entirely sure it is. But thanks, roger than and will do!
Genuinely quite upset at the lack of response at all here. I feel like there’s so many threads in this forum which get super large and then get left almost as a status quo complaint. This is such a major issue for a number of users (makes Obsidian genuinely unusable on quite a few existing file structures) that I’m surprised it’s not really being acknowledged. Would love for some serious addressing from the devs/mods.
1 Like
We wrote a post today to address the lack of responses:
1 Like
Thank you for the reply! I do appreciate the significant number of feature requests that must need looking at, but it would be amazing if threads could be tagged with the reasons they’re currently in limbo. From the post you linked, a couple of clear things are mentioned such as “requires more changes than expected”, “unclear implications for other users”, or other things like “untriaged” or if the request is accepted to proceed but not a priority, then something like “in queue”.
What stands out to me is the disparity between the super clear (and helpful) roadmap, to the sudden quagmire of feature requests that aren’t really remotely classified (or if they are, its 100 posts up and not trivial to find). I’d love to see treatment more similar to github issues if that makes any sense.
The roadmap contains major new functionalities that we have committed to implement (and it is vague on the details).
The feature requests on the forum are discussed internally, periodically, but there is no public comment on them.
Sorry, I do get that, I just wish there was a middle ground where there is no clear commitment like being put on the roadmap but a clear labelling of how the FR is being perceived unlike the opaque internal discussions we can’t see.
Is there a conclusion to this feature request?
1 Like
Appreciate your response that customer feedback is considered.
Appreciate as well limited resources on the Obsidian team, and the conflict between fixing/improving broken or missing functionality, and adding new things.
If this code segment is not planned for support any time soon (this issue is approaching two years old), could yall consider open sourcing this code? Between the over 60 replies here, and many more who have not posted there are at least a half dozen FOSS devs who will happily contribute a fix within days.
The pitch for your business colleagues: fixing gitignore will improve performance, and increased interoperability of Obisidan software, which will spin the network effects wheel for yall, bringing in more Obsidian customers.
2 Likes
Use case or problem
I want to be able to easily include/exclude files/folders from my vault without physically moving them out from vault file system.
Proposed solution
I think if you add support to .obsidianignore, similar to .gitignore, it would be a very easy to implement but very powerful feature.
The Exclude files setting is not powerful enough as it still indexes the excluded files, shows them in Files Explorer etc
Current workaround (optional)
NA
Related feature requests (optional)
6 Likes
Same issue. .obsidianignore could be a good option or maybe a new configuration option in menu for no programmers.
3 Likes
I second that request.
The file based backend of Obsidian enables powerful scenarios where you can work right in the middle of your documentation - if only the exclusion feature reliably hid stuff from Obsidian’s view.
It already works for .dot directories. Why can’t this be generalized to configurable folder names/regexes?
6 Likes
I can’t believe this still isn’t a thing. +1
3 Likes
Must be technically difficult? Although seems doubtful
This feature is a must
1 Like
I want to keep my Laravel project inside the vault, and want to avoid node_modules folder from indexing.
As there is no way to exclude folders/files from indexing. I have read that we can use . in the folder name to avoid it getting index.
So can we go other way around?, is there any way around to make changes in Node(npm) to create ‘.node_modules’ folder instead of ‘node_modules’ for that particular project?
Thanks.
1 Like
Oh well, I too, scrolled and scrolled to see it resolved yet it wasn’t.
I personally dont even like the idea of .obsidianignore that much, there’s too many .*ignore files already, I’d be more in favor of something like .obsidian/ignore.json (because actual .gitignore format is a pain, a list of globs/regexes might be better), or even simply do exclude the files hidden via settings from indexing and whatnot.
+1, my usecase is similar to everybody else, got a node_modules folder I’d like the app to not index for no reason 
How about making the following filter work? It’s in the app.json and .obsidian-all configuration files.
"userIgnoreFilters": [
"logseq/",
"data/"
]
1 Like