When renaming binary files via denote-rename-file what is the way to
prompt for signature?
It seems that this isn't currently supported. I'm unfamiliar with the
library, but based on a quick reading of the manual it seems that the
value of denote-prompts should probably be checked to decide whether or
not to prompt for a signature (over and above retrieving the value from
the file front-matter if present).
--
Suhail
Hello Suhail,
> From: Suhail Singh <suhailsingh247@gmail.com>> Date: Mon, 16 Oct 2023 14:36:54 -0400>> When renaming binary files via denote-rename-file what is the way to> prompt for signature?
There currently is no way to do this. I am happy to add it. Signatures
are a fairly new addition and I am expanding support for them over time.
> It seems that this isn't currently supported. I'm unfamiliar with the> library, but based on a quick reading of the manual it seems that the> value of denote-prompts should probably be checked to decide whether or> not to prompt for a signature (over and above retrieving the value from> the file front-matter if present).
Checking the denote-prompts will not work at all times. The template and
subdirectory prompts will not do the right thing. Maybe we need a new
user option, 'denote-rename-prompts' with a default value of '(title
keywords)' that is consulted by 'denote-rename-file' and related.
Though this may need more thought. I am open to ideas.
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> There currently is no way to do this. I am happy to add it.
thank you! that would be helpful. for a collection of research papers
the signature field is a good fit for including author names and the
keywords for encoding categorical labels.
> Checking the denote-prompts will not work at all times. The template and> subdirectory prompts will not do the right thing.
subdirectory and template don't seem to be inputs to denote-rename-file,
so i'm not sure i follow. my proposal was simply to check whether or not
'signature is a member of denote-prompts and if so prompt signature. if
not, keep existing behaviour (where the file front-matter is consulted
for it).
regardless of the specific mechanics, as long as there's a way to get
signature via user input it would work for my situation.
> Maybe we need a new user option, 'denote-rename-prompts' with a> default value of '(title keywords)' that is consulted by> 'denote-rename-file' and related.
that would work as well.
--
Suhail
Hello again Suhail,
> From: Suhail Singh <suhailsingh247@gmail.com>> Date: Tue, 17 Oct 2023 16:08:56 -0400>> Protesilaos Stavrou <info@protesilaos.com> writes:>>> There currently is no way to do this. I am happy to add it.>> thank you! that would be helpful. for a collection of research papers> the signature field is a good fit for including author names and the> keywords for encoding categorical labels.
I made lots of changes to the renaming commands. Among them is the one
which interests you: the 'denote-rename-file' now prompts for a
signature. Leave it empty to not insert one.
The new 'denote-dired-rename-files' has similar functionality to the
aforementioned, only it goes through all the Dired marked files (I think
this is very nice to have).
These are still part of development and I am happy to hear how we can
improve them further.
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> the 'denote-rename-file' now prompts for a signature
thank you!
on a related note, it seems as if denote-excluded-punctuation-regexp may
not be being consulted during signature entry? the current
denote-rename-file interface allows the inclusion of commas, spaces and
hyphens - all of which break the fontification in dired.
--
Suhail
> From: Suhail Singh <suhailsingh247@gmail.com>> Date: Mon, 23 Oct 2023 02:35:55 -0400>> Protesilaos Stavrou <info@protesilaos.com> writes:>>> the 'denote-rename-file' now prompts for a signature>> thank you!
You are welcome!
> on a related note, it seems as if denote-excluded-punctuation-regexp may> not be being consulted during signature entry? the current> denote-rename-file interface allows the inclusion of commas, spaces and> hyphens - all of which break the fontification in dired.
Thank you for pointing this out! I will take a look now.
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Tue, 24 Oct 2023 08:27:58 +0300> [... 12 lines elided]>> on a related note, it seems as if denote-excluded-punctuation-regexp may>> not be being consulted during signature entry? the current>> denote-rename-file interface allows the inclusion of commas, spaces and>> hyphens - all of which break the fontification in dired.>> Thank you for pointing this out! I will take a look now.
I just pushed the changes. Please let me know how they work for you.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>>> the current denote-rename-file interface allows the inclusion of>>> commas, spaces and hyphens - all of which break the fontification in>>> dired.>> I just pushed the changes. Please let me know how they work for you.
for reference, the comments below are from 85d34f0 checkout.
spaces in signature now get converted to "=" as intended and commas in
SIGNATURE get treated in a way that doesn't break fontification (more on
that later). however, hyphens are allowed in SIGNATURE (which is
consistent with TITLE and KEYWORDS), however it breaks fontification in
dired.
additionally, and some of below may be a subjective matter, i believe
the library would benefit from making its default behaviour more
consistent across SIGNATURE, TITLE and KEYWORDS. specifically,
- commas and spaces are presently treated one way in SIGNATURE and
TITLE, and another way in KEYWORDS. for instance, commas in KEYWORDS
get converted to a delimiter. however, commas in TITLE and KEYWORDS
simply get deleted. i haven't done exhaustive testing and so other
"illegal characters" may induce different behaviour as well. if you
agree that these differences are worth "resolving" it would probably
help to add some exhaustive tests. if not, feel free to refer me to
the section in the manual that would help me understand the raison
d'être for these differences.
- similar to denote-faces-time-delimiter it would help for there to also
be denote-faces-signature-delimiter, denote-faces-title-delimiter and
denote-faces-keywords-delimiter that are styled similarly (slightly
more visible than denote-faces-delimiter).
- currently, the interface of SIGNATURE field by the library is more
like TITLE (no autocompletion, free form text) as opposed to
KEYWORDS. when encoding author information for PDFs in SIGNATURE
field, the desired behaviour is to have SIGNATURE be treated more like
KEYWORDS. i believe there would be value in making this be
user-configurable.
cheers
--
Suhail
> From: Suhail Singh <suhailsingh247@gmail.com>> Date: Tue, 24 Oct 2023 13:39:25 -0400>> Protesilaos Stavrou <info@protesilaos.com> writes:>>>>> the current denote-rename-file interface allows the inclusion of>>>> commas, spaces and hyphens - all of which break the fontification in>>>> dired.>>>> I just pushed the changes. Please let me know how they work for you.>> for reference, the comments below are from 85d34f0 checkout.
Thank you!
> spaces in signature now get converted to "=" as intended and commas in> SIGNATURE get treated in a way that doesn't break fontification (more on> that later). however, hyphens are allowed in SIGNATURE (which is> consistent with TITLE and KEYWORDS), however it breaks fontification in> dired.
Hyphens were a bug. I pushed commit e200ff9 to cover that case.
> additionally, and some of below may be a subjective matter, i believe> the library would benefit from making its default behaviour more> consistent across SIGNATURE, TITLE and KEYWORDS. specifically,
I am happy to improve the user experience and thank you for taking the
time to share this!
> - commas and spaces are presently treated one way in SIGNATURE and> TITLE, and another way in KEYWORDS. for instance, commas in KEYWORDS> get converted to a delimiter. however, commas in TITLE and KEYWORDS> simply get deleted. i haven't done exhaustive testing and so other> "illegal characters" may induce different behaviour as well. if you> agree that these differences are worth "resolving" it would probably> help to add some exhaustive tests. if not, feel free to refer me to> the section in the manual that would help me understand the raison> d'être for these differences.
Commas in the keywords prompt represent the 'crm-separator'. Adding a
comma restarts the completion so that you can pick more keywords. I
personally use this to know when 'completing-read-multiple' is involved:
;; Add prompt indicator to `completing-read-multiple'. We display
;; [`completing-read-multiple': <separator>], e.g.,
;; [`completing-read-multiple': ,] if the separator is a comma. This
;; is adapted from the README of the `vertico' package by Daniel
;; Mendler. I made some small tweaks to propertize the segments of
;; the prompt.
(defun crm-indicator (args)
(cons (format "[`completing-read-multiple': %s] %s"
(propertize
(replace-regexp-in-string
"\\`\\[.*?]\\*\\|\\[.*?]\\*\\'" ""
crm-separator)
'face 'error)
(car args))
(cdr args)))
(advice-add #'completing-read-multiple :filter-args #'crm-indicator)
The title and signature prompts do not use 'completing-read-multiple' as
they are singular strings. Do you think there is value to making the
signature prompt use 'completing-read-multiple' as well?
> - similar to denote-faces-time-delimiter it would help for there to also> be denote-faces-signature-delimiter, denote-faces-title-delimiter and> denote-faces-keywords-delimiter that are styled similarly (slightly> more visible than denote-faces-delimiter).
Sure! I don't have time to do this now, though I will add it. Or you can
send the patch if you get to it first.
> - currently, the interface of SIGNATURE field by the library is more> like TITLE (no autocompletion, free form text) as opposed to> KEYWORDS. when encoding author information for PDFs in SIGNATURE> field, the desired behaviour is to have SIGNATURE be treated more like> KEYWORDS. i believe there would be value in making this be> user-configurable.
I updated both the title and signature prompts to perform completion
against their own history (use 'savehist-mode' to persist histories).
This way the user can quickly get a previous value. I did this in commit
0d855bb.
What do you think about it?
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> Hyphens were a bug. I pushed commit e200ff9 to cover that case.
e200ff9 now seems to sluggify hyphens in SIGNATURE in a manner which is
consistent with TITLE. and fontification on the sluggified result
works. however, there are still some issues. i'll note these below for
your reference, but assuming you consider them issues as well, the way
to solve these may be to add some tests which do some exhaustive
checking of invariances that ought to exist.
- commas entered in SIGNATURE and TITLE interactive prompts are retained
in generated filename, however, fontification is broken once again.
- typing SPC when entering TITLE seems to perform completion instead of
entering space. in order to enter space, i have to hit "C-q SPC"
instead. interestingly typing SPC when entering SIGNATURE still works
as expected (expectation is for SPC to be entered in minibuffer prompt
and then for it to get sluggified). i.e., denote-signature-prompt has
correct behaviour, but denote-title-prompt has a bug.
> Commas in the keywords prompt represent the 'crm-separator'. Adding a> comma restarts the completion so that you can pick more keywords.>> ...>> The title and signature prompts do not use 'completing-read-multiple' as> they are singular strings. Do you think there is value to making the> signature prompt use 'completing-read-multiple' as well?
not exclusively, no. but i do see value in making it be somewhat
user-configurable. my previous attempt to explain this wasn't very
effective, so i'll try to rephrase and be a little more explicit below.
denote has the following TYPES:
- DATE (pair of numbers)
- SIGNATURE (string)
- TITLE (string)
- KEYWORDS (collection of strings)
as such, denote has the following "kinds" of types:
- values (string, numbers; e.g., TITLE)
- pair of values (e.g., DATE)
- collection of values (e.g., KEYWORDS)
in some situations (mine included), it's more natural to think of the
information in SIGNATURE as a collection of values (similar to
KEYWORDS). i.e., i desire the below:
- DATE (pair of numbers)
- SIGNATURE (string | collection of strings)
- TITLE (string)
- KEYWORDS (collection of strings)
i cannot think of a situation where it would be natural to think of the
TITLE or DATE as a collection of values. on the other hand, i cannot
think of a situation where it would be more natural to think of KEYWORDS
as not being a collection. concretely, IMO, having the following user
option would be helpful:
- denote-signature-treat-as-collection
- nil: current behaviour
- sorted: similar to KEYWORDS with denote-sort-keywords set to t
- unsorted: similar to KEYWORDS with denote-sort-keywords set to nil
the above concerns how information entered by user is encoded in the
filename, i.e., serialization. related is how information is
deserialized/parsed from the filename.
some invariances that i believe ought to hold (as well as their
transitive closure):
- SPC and "," should be treated identically when sluggifying TITLE
- SPC and "," should be treated identically when sluggifying SIGNATURE
- SPC and "," should be treated identically when sluggifying KEYWORDS
- SPC and "," should be treated identically when entering a value of
kind "collection of values", i.e., both should be treated as
crm-delimiter
- SPC and "," should be treated identically in SIGNATURE, TITLE and
KEYWORDS.
>> - similar to denote-faces-time-delimiter it would help for there to also>> be denote-faces-signature-delimiter, denote-faces-title-delimiter and>> denote-faces-keywords-delimiter that are styled similarly (slightly>> more visible than denote-faces-delimiter).>> Sure! I don't have time to do this now, though I will add it. Or you can> send the patch if you get to it first.
unfortunately my regular expression skills are such that i likely won't
be able to contribute a patch any time soon.
> I updated both the title and signature prompts to perform completion> against their own history (use 'savehist-mode' to persist histories).> This way the user can quickly get a previous value. I did this in commit> 0d855bb.>> What do you think about it?
see above regd. issue when typing SPC in TITLE.
--
Suhail
PLEASE IGNORE PREVIOUS EMAIL/POST. treat this as a
replacement. apologies for the noise.
Protesilaos Stavrou <info@protesilaos.com> writes:
> Hyphens were a bug. I pushed commit e200ff9 to cover that case.
e200ff9 now seems to sluggify hyphens in SIGNATURE in a manner which is
consistent with TITLE. and fontification on the sluggified result
works. however, there are still some issues. i'll note these below for
your reference, but assuming you consider them issues as well, the way
to solve these may be to add some tests which do some exhaustive
checking of invariances that ought to exist.
- commas entered in SIGNATURE and TITLE interactive prompts are retained
in generated filename, however, fontification is broken once again.
- typing SPC when entering TITLE seems to perform completion instead of
entering space. in order to enter space, i have to hit "C-q SPC"
instead. interestingly typing SPC when entering SIGNATURE still works
as expected (expectation is for SPC to be entered in minibuffer prompt
and then for it to get sluggified). i.e., denote-signature-prompt has
correct behaviour, but denote-title-prompt has a bug.
> Commas in the keywords prompt represent the 'crm-separator'. Adding a> comma restarts the completion so that you can pick more keywords.>> ...>> The title and signature prompts do not use 'completing-read-multiple' as> they are singular strings. Do you think there is value to making the> signature prompt use 'completing-read-multiple' as well?
not exclusively, no. but i do see value in making it be somewhat
user-configurable. my previous attempt to explain this wasn't very
effective, so i'll try to rephrase and be a little more explicit below.
denote has the following TYPES:
- DATE (pair of numbers)
- SIGNATURE (string)
- TITLE (string)
- KEYWORDS (collection of strings)
as such, denote has the following "kinds" of types:
- values (string, numbers; e.g., TITLE)
- pair of values (e.g., DATE)
- collection of values (e.g., KEYWORDS)
in some situations (mine included), it's more natural to think of the
information in SIGNATURE as a collection of values (similar to
KEYWORDS). i.e., i desire the below:
- DATE (pair of numbers)
- SIGNATURE (string | collection of strings)
- TITLE (string)
- KEYWORDS (collection of strings)
i cannot think of a situation where it would be natural to think of the
TITLE or DATE as a collection of values. on the other hand, i cannot
think of a situation where it would be more natural to think of KEYWORDS
as not being a collection. concretely, IMO, having the following user
option would be helpful:
- denote-signature-treat-as-collection
- nil: current behaviour
- sorted: similar to KEYWORDS with denote-sort-keywords set to t
- unsorted: similar to KEYWORDS with denote-sort-keywords set to nil
additionally, some invariances that i believe ought to hold are below. i
don't know how easy or not they would be to achieve. entering is the
process of typing things in the minibuffer prompt
interactively. serializing is the process of taking that information and
encoding it into filename (a process which includes
sluggification). deserializing is the process that is (ought to be?)
used when fontifying and when parsing filename for information which is
proposed as default values when performing a rename.
- "-", SPC and "," should be treated identically when {entering,
serializing, deserializing} TITLE
- "=", SPC and "," should be treated identically when {entering,
serializing, deserializing} SIGNATURE
- "_", SPC and "," should be treated identically when {entering,
serializing, deserializing} KEYWORDS
- SPC and "," should be treated identically when entering a value of
kind "collection of values", i.e., both should be treated as
crm-separator.
specifically, with observing above invariances when "foo,bar" is entered
in TITLE prompt it would serialize as "foo-bar" which is the same as the
outcome when "foo bar" is entered in TITLE prompt. similarly for others.
>> - similar to denote-faces-time-delimiter it would help for there to also>> be denote-faces-signature-delimiter, denote-faces-title-delimiter and>> denote-faces-keywords-delimiter that are styled similarly (slightly>> more visible than denote-faces-delimiter).>> Sure! I don't have time to do this now, though I will add it. Or you can> send the patch if you get to it first.
unfortunately my regular expression skills are such that i likely won't
be able to contribute a patch any time soon.
> I updated both the title and signature prompts to perform completion> against their own history (use 'savehist-mode' to persist histories).> This way the user can quickly get a previous value. I did this in commit> 0d855bb.>> What do you think about it?
see above regd. issue when typing SPC in TITLE.
--
Suhail
> From: Suhail Singh <suhailsingh247@gmail.com>> Date: Wed, 25 Oct 2023 11:09:32 -0400>> PLEASE IGNORE PREVIOUS EMAIL/POST. treat this as a> replacement. apologies for the noise.
No worries!
> [... 108 lines elided]>> What do you think about it?>> see above regd. issue when typing SPC in TITLE.
I cannot comment on everything now because my electricity will not last
me much longer. Will do it tomorrow. For now, all I did was to revert
the commit that added completion to the title/signature prompts. The
idea is good, but we have to make sure it works in all cases.
Thank you for the valuable feedback!
More to follow.
--
Protesilaos Stavrou
https://protesilaos.com