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

Support for multiple file extensions and default extension #1235

Merged
merged 11 commits into from
Jun 30, 2023

Conversation

riccardoferretti
Copy link
Collaborator

Fixes #924 and #1129

Introducing the foam.files.noteExtensions property, which tells Foam what extensions to treat as (markdown) text notes.

The first extension from the list will be treated as the default extension.

The default extension is the one assumed when a [[wikilink]] doesn't include an extension, and is also the one used when creating notes from a [[placeholder]]

Still debating whether the default extension should be an explicit property or the first one from the list of extensions. Leaving for the first in terms of clarity, but I like the second as it enforces consistency (i.e. you can't have a default extension that is not part of the allowed extensions) and avoids extra configuration

@redactedscribe
Copy link

redactedscribe commented May 25, 2023

Still debating whether the default extension should be an explicit property or the first one from the list of extensions.

Unless you read some docs, it may not be apparent that the value for the new setting acts in this way. A separate setting for the default makes it self-explanatory, but so do unambiguous tooltips. I generally prefer a label or variable to express its intent or function clearly as to not need any further explanation.

Leaving for the first in terms of clarity, but I like the second as it enforces consistency (i.e. you can't have a default extension that is not part of the allowed extensions) and avoids extra configuration

If I've understood your sentence correctly, I'd say avoiding extra configuration isn't an weighty argument because the majority of users will likely not change either of these settings (especially if given sane defaults), but for those who do, I wouldn't consider it cumbersome to configure two separately.

If the hypothetical "noteDefaultExtension" were to be leveraged in the future for some additional purpose, a discrete settings could be more user-friendly, if not, then the first extension defined in noteExtensions is sufficient (given a good tooltip).

The problem I see if two settings are used is that reading noteExtensions doesn't imply that there exists a second setting, or main setting, "noteDefaultExtension" to define. Maybe "noteOtherExtensions" over noteExtensions in this case?

@riccardoferretti
Copy link
Collaborator Author

Thanks for the feedback @redactedscribe, some interesting points. I will take it into account

@redactedscribe
Copy link

Not a problem @riccardoferretti. Always happy to add a second opinion. My criticisms mainly come from a usability standpoint since I am more of a designer than a coder, yet I hope they do hold relevance. Thanks for the continued development.

@riccardoferretti riccardoferretti merged commit a504054 into master Jun 30, 2023
@riccardoferretti riccardoferretti deleted the feature/default-file-extension branch June 30, 2023 12:09
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.

Support for Quarto
2 participants