-
-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add remaining front matter retrieval functions #468
Add remaining front matter retrieval functions #468
Conversation
I have added a commit to simplify Now, the only remaining possibility is if the user calls This is ready to be merged! |
Do you think we should leave this as-is or interpret nil as an empty string in this case? I am fine with what we have. Just asking. |
Merged, thank you! |
I think a nil value for a parameter makes sense when it means "not set", such Since we are at it, in commit 55e923f, about
In this case, I can understand that the title and signature can have this "not You can remove it if you want. It would be safe: we never call it with nil in Also, I am okay if you would decide to revert my last commit (about |
From: Jean-Philippe Gagné Guay ***@***.***>
Date: Sat, 26 Oct 2024 06:40:10 -0700
I think a nil value for a parameter makes sense when it means "not set", such
as with optional parameters. In the case of these commands, the parameter is
mandatory. It seems reasonable to me to expect users to call them with
arguments of the appropriate type.
This is fine, thank you!
Since we are at it, in commit 55e923f, about `denote-format-file-name`, you
made this comment in git:
> We do not want to limit this to empty strings, because there are cases
we will need to arrange for the return value to be that. Whereas we
get nil for free.
In this case, I can understand that the title and signature can have this "not
set" meaning. My preference is still to enforce a string because the
parameters are mandatory. But I am conflicted, because at some point, I may
suggest to make the id optional and nil may be better than an empty string to
mean an absent identifier. It would not really be an issue, but it may be
confusing that nil is permitted for a paramater, but not the others.
Indeed, it is better to have this nuanced treatment of the value.
You can remove it if you want. It would be safe: we never call it with nil in
the code (I just checked.).
-----
Also, I am okay if you would decide to revert my last commit (about
`denote-format-string-for-{org/md}-front-matter`).
No, let's keep it as-is. I just want to ask to be sure I am on the same
page as you.
…--
Protesilaos Stavrou
https://protesilaos.com
|
Perfect! |
In response to #467 and to allow us to handle the front matter in future development, I have added the missing front matter retrieval functions in
denote-file-types
. I assumed the signature would be included eventually.Since we still do not use them, this should not break anything. I created and renamed a note of each type to be sure.
Note that I renamed
:date-format-function
to:date-value-function
to be consistent with the other components.