Hi,
I have some small video files which I treat as notes. I have
renamed them with the Denoted, but the 'denote-link' function does
not see them as it is prevented to do so by the
'denote-only-note-p' function, which only allow Denote filenames
with txt, md or org extensions.
Should Denote not be able to also link PDF files, video files or
whatever else is stored in its directories?
I have jerry-rigged the relevant Denote functions to allow this,
but not sure if this will break something else.
First I modified 'denote--only-note-p' to be less exclusive and
allow any file extension with valid Denote file name. I assume
doing this breaks other things, but that is a later problem.
(defun denote--only-note-p (file)
"Make sure FILE is a file with Denote file name that can be
linked."
(let ((file-name (file-name-nondirectory file)))
(and (not (file-directory-p file))
(file-regular-p file)
(string-match-p denote--id-regexp
file-name)
(not (string-match-p "[#~]\\'" file)))))
This now kindoff works, but the link name will be 'nil', so next I
tried to write a function that creates a link name from the file
name with some clumsy regex:
(defun denote--retrieve-filename-title (file)
"Extract name from FILE name and convert to title case."
(if (file-exists-p file)
(let* ((title
(progn
(string-match denote--title-regexp file)
(match-string 0 file)) )
;; There must be a more efficient method
(link-title (replace-regexp-in-string "^\\(--\\)"
"" title))
(link-title (replace-regexp-in-string "-" " "
link-title))
(link-title (citeproc-s-title-case link-title)))
;; body
link-title)))
You can test this with:
(denote--retrieve-filename-title
(denote--retrieve-read-file-prompt))
Works for image files, but there is a problem with video files
because Denote visits any file it links to extract the link title.
The 'denote--retrieve-value-title' seems to return the title from
file, so lets try to 'improve' it:
(defun denote--retrieve-value-title (file &optional key)
"Return title value from FILE.
Use filename if not md, txt or org file.
If optional KEY is non-nil, return the key instead."
(if (string-match-p (concat denote--id-regexp
".*" denote--extension-regexp
"\\(.gpg\\)?")
file)
(denote--retrieve-search
file
denote--retrieve-title-front-matter-key-regexp
key)
(denote--retrieve-filename-title file)))
This hack seems to work, but I am not sure that it is the best way
to implement linking non md/org/txt files or whether I have broken
other functions.
Suggestions?
P:)
--
Dr Peter Prevos
---------------
peterprevos.com
> From: Peter Prevos <peter@prevos.net>> Date: Sat, 13 Aug 2022 07:55:04 +1000>> Hi,
Hello Peter,
> I have some small video files which I treat as notes. I have > renamed them with the Denoted, but the 'denote-link' function does > not see them as it is prevented to do so by the > 'denote-only-note-p' function, which only allow Denote filenames > with txt, md or org extensions.>> Should Denote not be able to also link PDF files, video files or > whatever else is stored in its directories?
Yes, it should. I think we can now remove this restriction. If a file
has our identifier and is stored in the 'denote-directory', then it is
"ours" for the purposes of the linking mechanism.
I had placed this restriction as a precaution. I was not sure how we
should treat such links, so I thought it was better to prevent their
creation. This decision was made prior to version 0.1.0. I think now
we have a better understanding of where we are and what we are supposed
to do.
> I have jerry-rigged the relevant Denote functions to allow this, > but not sure if this will break something else.
I have some other tasks pertaining to Denote, but will implement the
aforementioned change right afterwards. Expect an update in a few
hours.
n
> [... 39 lines elided]> Works for image files, but there is a problem with video files > because Denote visits any file it links to extract the link title.
Yes, this is the kind of problem I had in mind. I believe there are
some recent changes to our data retrieval functions, or those ancillary
to them, which only check writable+regular files.
> [... 17 lines elided]> This hack seems to work, but I am not sure that it is the best way > to implement linking non md/org/txt files or whether I have broken > other functions.>> Suggestions?
It will be supported directly in denote.el. Then we can test it ahead
of the new version and be sure we have something reliable.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Sat, 13 Aug 2022 06:29:48 +0300>> I have some other tasks pertaining to Denote, but will implement the> aforementioned change right afterwards. Expect an update in a few> hours.
I just pushed commit 8a8be90 which relaxes the relevant conditionality.
Now any file that (i) has an identifier and (ii) is in the
'denote-directory' is a candidate for linking.
Now I need to polish it and make sure everything works. Will keep you
posted.
--
Protesilaos Stavrou
https://protesilaos.com
> From: Protesilaos Stavrou <info@protesilaos.com>> Date: Sat, 13 Aug 2022 10:11:15 +0300>> I just pushed commit 8a8be90 which relaxes the relevant conditionality.> Now any file that (i) has an identifier and (ii) is in the> 'denote-directory' is a candidate for linking.>> Now I need to polish it and make sure everything works. Will keep you> posted.
Hello again!
My initial tests suggest that everything is in order. The linking
facility should now support any file that:
1. Has an identifier (per our file-naming scheme).
2. Is stored in the 'denote-directory'.
I also made Denote infer keywords from all files in the
'denote-directory'. Before, it would only target "notes", meaning files
ending in {txt,md,org}.
If you give it a try, please let me know if it works for you or if there
are any bugs we need to address.
--
Protesilaos Stavrou
https://protesilaos.com
Hi Prot,
Thanks for the changes.
Some observed behaviours:
1. When renaming a attachment (i.e. any file not Org, txt or md),
the minibuffer shows the identifier as being part of the name of
the file (using denote-rename). This means that every time one
renames such a file, the identifier is prepended as part of the
title.
2. When linking an attachment in a Denote file, it does not parse
the title as a filename. I have a modified version of
denote--retrieve-value-title that does just that in my version.
Keep up the great work.
P:)
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Protesilaos Stavrou <info@protesilaos.com>>> Date: Sat, 13 Aug 2022 10:11:15 +0300>>>> I just pushed commit 8a8be90 which relaxes the relevant >> conditionality.>> Now any file that (i) has an identifier and (ii) is in the>> 'denote-directory' is a candidate for linking.>>>> Now I need to polish it and make sure everything works. Will >> keep you>> posted.>> Hello again!>> My initial tests suggest that everything is in order. The > linking> facility should now support any file that:>> 1. Has an identifier (per our file-naming scheme).> 2. Is stored in the 'denote-directory'.>> I also made Denote infer keywords from all files in the> 'denote-directory'. Before, it would only target "notes", > meaning files> ending in {txt,md,org}.>> If you give it a try, please let me know if it works for you or > if there> are any bugs we need to address.
--
Dr Peter Prevos
---------------
peterprevos.com
> From: Peter Prevos <peter@prevos.net>> Date: Mon, 15 Aug 2022 15:19:07 +1000>>> Hi Prot,
Hello Peter,
> Thanks for the changes.
You are welcome!
> Some observed behaviours:> 1. When renaming a attachment (i.e. any file not Org, txt or md), > the minibuffer shows the identifier as being part of the name of > the file (using denote-rename). This means that every time one > renames such a file, the identifier is prepended as part of the > title.
I believe this is a regression. Will see to it.
> 2. When linking an attachment in a Denote file, it does not parse > the title as a filename. I have a modified version of > denote--retrieve-value-title that does just that in my version.
This requires some further changes. The constraint with
denote--retrieve-value-title is that it checks the file's contents. We
do not want to do that for, e.g., an mp3 file. For such files, we could
just use the TITLE component of their file name, if it exists.
Currently I have simpler approach which inserts the link as an
identifier when the linked file is not a "note".
> Keep up the great work.
Thank you for the kind words and the feedback!
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Hi Prot,
Further to my previous email, this function extract the link title
for attachments from the file name.
(defun denote--retrieve-filename-title2 (file)
"Extract name from FILE name and convert to title case."
(if (file-exists-p file)
(let* ((title
(progn
(string-match denote--title-regexp file)
(match-string 1 file)))
(link-title (capitalize (replace-regexp-in-string
"-" " " title))))
link-title)))
I tested this with: (denote--retrieve-filename-title
(denote--retrieve-read-file-prompt)).
If this function can be integrated with denote-link--format-link
or another function, then attachments also get a named link.
regards
P:)
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Peter Prevos <peter@prevos.net>>> Date: Mon, 15 Aug 2022 15:19:07 +1000>>>>>> Hi Prot,>> Hello Peter,>>> Thanks for the changes.>> You are welcome!>>> Some observed behaviours:>> 1. When renaming a attachment (i.e. any file not Org, txt or >> md), >> the minibuffer shows the identifier as being part of the name >> of >> the file (using denote-rename). This means that every time one >> renames such a file, the identifier is prepended as part of the >> title.>> I believe this is a regression. Will see to it.>>> 2. When linking an attachment in a Denote file, it does not >> parse >> the title as a filename. I have a modified version of >> denote--retrieve-value-title that does just that in my version.>> This requires some further changes. The constraint with> denote--retrieve-value-title is that it checks the file's > contents. We> do not want to do that for, e.g., an mp3 file. For such files, > we could> just use the TITLE component of their file name, if it exists.> Currently I have simpler approach which inserts the link as an> identifier when the linked file is not a "note".>>> Keep up the great work.>> Thank you for the kind words and the feedback!>> All the best,> Prot
--
Dr Peter Prevos
---------------
peterprevos.com
> From: Peter Prevos <peter@prevos.net>> Date: Mon, 15 Aug 2022 18:41:52 +1000>>> Hi Prot,
Hello Peter,
> Further to my previous email, this function extract the link title > for attachments from the file name.>> [... 14 lines elided]>> If this function can be integrated with denote-link--format-link > or another function, then attachments also get a named link.
I was already working on this as it is also related to the renaming
operations and the internal work we are doing with Jean-Philippe Gagné
Guay to make supported file type more flexible (and the code cleaner
overall).
I just pushed a change which relies on some functions I wrote this
morning. It should always return a meaningful title now.
- If the file has, say, "#+title" it will get its value.
- If front matter cannot be retrieved, it will isolate the TITLE
component of the file name.
- If the TITLE in the file name does not exist, it will return nil. I
think this is the correct behaviour as it reminds the user that the
link has no title anywhere. We do not prevent the user from creating
such a link, as the identifier does exist, but we tell them that it is
not optimal to do things this way.
Put differently, the link will always have a title instead of the
previous behaviour. The user inserts plain ID links only when they
explicitly want to.
I believe everything does the right thing now, though please note that
we are still making some refinements: working with private functions
(those with double hyphens in their name) is risky, in this regard.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Thanks Prot,
The version I wrote replaces dashes with spaces and converts it
title case.
I have submitted a pull request.
P:)
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Peter Prevos <peter@prevos.net>>> Date: Mon, 15 Aug 2022 18:41:52 +1000>>>>>> Hi Prot,>> Hello Peter,>>> Further to my previous email, this function extract the link >> title >> for attachments from the file name.>>>> [... 14 lines elided]>>>> If this function can be integrated with >> denote-link--format-link >> or another function, then attachments also get a named link.>> I was already working on this as it is also related to the > renaming> operations and the internal work we are doing with Jean-Philippe > Gagné> Guay to make supported file type more flexible (and the code > cleaner> overall).>> I just pushed a change which relies on some functions I wrote > this> morning. It should always return a meaningful title now.>> - If the file has, say, "#+title" it will get its value.>> - If front matter cannot be retrieved, it will isolate the TITLE> component of the file name.>> - If the TITLE in the file name does not exist, it will return > nil. I> think this is the correct behaviour as it reminds the user > that the> link has no title anywhere. We do not prevent the user from > creating> such a link, as the identifier does exist, but we tell them > that it is> not optimal to do things this way.>> Put differently, the link will always have a title instead of > the> previous behaviour. The user inserts plain ID links only when > they> explicitly want to.>> I believe everything does the right thing now, though please > note that> we are still making some refinements: working with private > functions> (those with double hyphens in their name) is risky, in this > regard.>> All the best,> Prot
--
Dr Peter Prevos
---------------
peterprevos.com
> From: Peter Prevos <peter@prevos.net>> Date: Mon, 15 Aug 2022 20:13:03 +1000>>> Thanks Prot,>> The version I wrote replaces dashes with spaces and converts it > title case.>> I have submitted a pull request.
Merged. Thank you! Wrote some comments there.
As this was done on the GitHub mirror, here is the link in case anyone
needs it: <https://github.com/protesilaos/denote/pull/93>.
--
Protesilaos Stavrou
https://protesilaos.com