Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External Workspaces #1418

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

guestieng
Copy link

The requested changes make it possible to choose between two basic types of workspaces for the notes and templates:

  1. "internal" VSCode workspace: Watch and access the note and template folders within "internal" workspace (exclusive VSCode workspace)
  2. "external" workspace: Watch and access the note and template folders within 'external' workspace ("external" with respect to VSCode workspace; INFO: this may include folders from the "internal" VSCode workspace)

The switch may be done via the config. property foam.files.workspaceType .

This feature allows to decouple the essential foam workspace from the VSCode workspace and provides better flexibility and less workflow complexity, particularly when working with multiple VSCode workspaces and projects.

The "external" and absolute note folder paths that are to be watched can be defined via the config. property
foam.files.externalWatchPaths .
The external and absolute template root directory path may be defined via the config. property foam.files.externalTemplatesRoot .

NOTE: The "external" path definitions may be defined such that either only a respective root directory or, in addition, a glob pattern is provided.

…on flag is only available when targeting 'es2022' or later."
… part of VSCode workspace

- allow defining templates in external workspace folders
- added config. properties: foam.files.workspaceType, foam.files.externalWatchPaths, foam.files.externalTemplatesRoot
@riccardoferretti
Copy link
Collaborator

Thanks for the contribution @guestieng
Can you help me better understand the problem this PR addresses? Specifically, what user set up and/or use case is this meant to help with? Is there something that wouldn't be "reproducible" using workspaces with multiple folders?
In terms of Foam direction, especially in the context of using it as a web extension, I fear that the idea of "external" workspace would not easily work or require special handling. Do you have an idea of how that would work?

@guestieng
Copy link
Author

guestieng commented Jan 7, 2025

Thanks for the contribution @guestieng Can you help me better understand the problem this PR addresses? Specifically, what user set up and/or use case is this meant to help with? Is there something that wouldn't be "reproducible" using workspaces with multiple folders? In terms of Foam direction, especially in the context of using it as a web extension, I fear that the idea of "external" workspace would not easily work or require special handling. Do you have an idea of how that would work?

In slightly more detail, the following problems are addressed:

When working with a couple of already existing workspaces (likely with multiple folders per workspace) in parallel, e.g. for different projects, or, respectively, when working with several generically created workspaces, it costs avoidable (e.g., by this pull request) time and effort to care about a notes folder in every workspace. Moreover, there are extensions like Continue which one might want to feed with an explicit and clean (workspace) codebase. Besides, personally, I would like to be able to always take notes (without loosing availability) in a very efficient manner, that is with a minimal set of user interactions, no matter how the workspace (settings) look like.
Of course, one could always open another VSCode instance for a foam workspace. But that demands additional resources.
What is more, it appears advantageous to me to not couple templates to the note workspaces/folders in a redundant manner as one may wish to use same templates in different (and "independent") VSCode workspaces.
Therefore, the current pull request introduces an option for defining an external template folder (via foam.files.externalTemplatesRoot), so that defining the templates location only needs to be done once, in the user settings, specifically, instead of in workspace settings.

As to your 2nd question, can you specify a little? For example, what do you refer to by "Foam direction" and how would the context of a web extension differ?

@riccardoferretti
Copy link
Collaborator

Thanks for the clarification, have you considered creating multiple.workspace files to handle these situations?
That should solve the first case you are mentioning.
Regarding the shared templates, we did have user level settings before (similar to how in VS Code you have folder -> workspace -> user settings) but got rid of it eventually to simply the process. I believe something similar to user settings can be achieved by having a workspace with multiple folders, the first of which contains your "user templates" (a current Foam limitation is that templates from different workspace folders are not merged together).

The above approach should satisfy your use case while keeping Foam working within the current goal.
No code changes would be required (unless you want to allow for merging of templates).

A good litmus test of whether a change will make it hard for Foam to be a full web extension is whether it requires access to NodeJS modules (as those are not available in the browser). In the case of this PR, we would need to access files and directories outside of vscode.workspace which means we'd need to use the fs module.
You can look at the couple of transitional PRs we worked on last October to get an idea of the effort we went through to achieve this transition.

Let me know if the above makes sense. Your use case is valid and I imagine other people might also benefit from documenting it as a sort of recipe as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants