Make foam respect the .gitignore file

[dvalde0]

Is your feature request related to a problem? Please describe.

The graph view plots all the files in the repository. This is a problem if the user has a virtual env installed in the repository, becuase it will plot all the .md files in the env. This also applies to wikilink autocompletion, where the pop-up will include all the files in the venv.

Describe the solution you'd like

Make foam respect the .gitignore file, meaning that the folders and files defined in .gitignore should be ignored by foam entirely.

Describe alternatives you've considered

The user could filter the filetypes in Foam > Files: Notes Extensions and use a custom filetype, but this is really not an alternative.

Screenshots or Videos

No response

[riccardoferretti]

Thanks for reporting this @dvalde0
I am not against adding support for this feature, if someone wants to take a stab at this I can provide support.

[TieWay59]

Hi there @riccardoferretti,

I've been a Foam user for over three years and love it. However, I'm primarily a junior JS developer and don't have much experience with VSCode extensions. If I wanted to get started contributing to Foam, I'd love to know more about how to build and test Foam. Any links to resources or documentation would be greatly appreciated.

[riccardoferretti]

Hi @TieWay59 - the best place to get started is reading the contribution-guide.md file (here).

For this specific feature a starting point would be the extension.ts file (here), which is basically the entry point for the extension, and handles the file exclusions.

Let me know if you have any question, thanks for wanting to help!

[TieWay59]

Hi @TieWay59 - the best place to get started is reading the contribution-guide.md file (here).

For this specific feature a starting point would be the extension.ts file (here), which is basically the entry point for the extension, and handles the file exclusions.

Let me know if you have any question, thanks for wanting to help!

I apologize for my slow progress during my spare time. I have tried the process outlined in contribution-guide.md and have managed to start a test host using the debugger. Here, I have a question: how can I determine whether the running instance of Foam is the one I've built locally? Is there any method for this?

I've tried running the command code --list-extensions --show-versions | rg foam-vscode and got the following output:

[email protected]

However, this output doesn't seem to indicate anything. Perhaps I could temporarily modify the project's version number somewhere? @riccardoferretti

[TieWay59]

I am currently conducting some experiments on my own branch and feel that it is not yet ready to be merged. Before I propose a PR, I would like to share my thoughts:

1. Introduction of Gitignore Rules: I plan to incorporate the rules from .gitignore into the global exclude rules during the program's startup phase. This change is located at the commit position mentioned. Through testing and logging, I have confirmed the effectiveness of this approach. TieWay59@74dc6c1 @riccardoferretti

2. Questions for Discussion:

   • Q1: Do you agree with this approach?
   • Q2: What is the specific effect of the exclude pattern here? Is it simply to prevent parsing of files?
   • Q3: If I have a rule that excludes bad_note.md, but I use a link like [[bad_note]] in another file, what behavior should the excluded bad_note.md exhibit? (My naive understanding is that it should prompt that the link cannot be established because it has been excluded.)
   • Q4: Is the reading of .gitignore at the start of the program a one-time execution? What actions should I take to ensure dynamic updates, or to trigger updates with certain actions? For example, is it a good idea to update when the Update command is issued?

[riccardoferretti]

Hi @TieWay59 , sorry for the late response, here we go:

• the best way to work on the extension "in dev mode" is to run the task "Run VS Code Extension" within VS Code directly (Go to "Run and Debug" - cmd + D). This will allow you to also use breakpoints within the extension, will make your life easier.

To your questions:

1. generally speaking, avoid using paths (strings) directly, use Uri instead. Also avoid using Uri.file (because of the changes coming with Error creating file in .dev version: No file system handle registered #1404) and instead try using a "base uri" as reference to compute relative paths.
2. correct, they will be invisible to Foam
3. good point, this might create a bit of a paradox, in the sense that, because of the previous point, bad_note.md is invisible to Foam, so [[bad_note]] is treated as a placeholder. Clicking on the placeholder will create a note from it, which depending on the pattern would also be ignored, going back to square 1
4. I can see 2 approaches: first, ignore the issue and let the user deal with it (it's a rare enough case that I would be comfortable with it). second, monitor changes in the file, and on change notify the user that the workspace needs to be reloaded (you will see in extension.ts we do this for a few settings)

The other thing that is worth mentioning is making sure that the semantics of the gitignore file are properly represented in the glob ignore pattern. TBH I am not sure 100% as I have never had to dig deep into it, so it might be a non-problem - but what I would want to avoid is that unexpected behavior there