~protesilaos/denote

8 4

Re: Intended use-cases for renaming denote-files

Details
Message ID
<87fsiljv1s.fsf@hu.mail-host-address-is-not-set>
DKIM signature
missing
Download raw message
@Jean-Philippe Gagné Guay

>>> In fact, we could simplify all the rename functions to these two:
>>>
>>> - `denote-add-front-matter` which adds a front-matter to a file
>>>   without changing the filename, and
>>> - `denote-update-filename` which takes care of getting a valid
>>>   Denote filename, from the front matter (and current filename).
>
>> What would be the use-case of the former without the latter?  Do you
>> mean it in the sense I explained in my last message to this thread?
>> Namely, where it would have a smart mechanism of (i) add the whole block
>> if all is absent, (ii) complement existing entries with the missing
>> ones, (iii) rewrite existing entries.
>
>I don't have a use-case for the former without the latter, just for
>the latter without the former! (The `denote-update-filename` would be
>useful on its own.) I was thinking more about providing simple and
>general tools to handle different use-cases. But maybe they should be
>internal functions instead of user commands.
>
>I am thinking that adding reverse-rename functions will lead to more
>complexity, but I actually prefer them to the non-reverse functions. I
>am trying to see Denote in another angle hoping to get something simpler
>than just adding additional commands.
>
>I am going to try to list the different use-cases and how a user could
>handle them. We can expand this list to get a clearer picture.
>
>(1) Modify title/keywords through the front matter and get the
>    filename updated.
>    Proposition: Run `denote-update-filename`.
>
>(2) Get a file "my_note.org" to a valid Denote note.
>    Prop.: Run `denote-convert-to-denote` which would add a front
>           matter first, then derive the filename.
>
>(3) Rename an existing (and valid) Denote note.
>    Prop.: Modify the front matter and run `denote-update-filename`.
>           This is different from `denote-dired-rename-file`, but it
>           is in a sense simpler because we don't have to handle all
>           the prompts of `denote-dired-rename-file` and we don't have
>           to confirm the changes with the user because he is already
>           modifying the file. One issue with this is that the user
>           will not see all the possible keywords to choose from, but
>           it might not be a big issue.
>
>(4) Maybe given a valid Denote filename but no front matter,
>    add a front matter, but I am not sure...
>    Prop.: Run `denote-convert-to-denote` which would handle this case
>           as well.
>
>(5) Have a Denote filename for a PDF.
>    Prop.: Run `denote-convert-to-denote`.
>
>(6) Batch operations...
>
>The more general idea would be to see the front matter as THE source of
>truth from which to derive the filename.

I believe, the filename should remain the source of truth because:

- solely its identifier is used for incomming links
- all filetypes not having any frontmatter (e.g. PDF, epub, etc.)
  have only the filename as 'source of truth' available.

I believe it simplifies matters (at least in 'my' head) that the source
of truth is always the same, i.e. the filename.

Regarding your previous remark, that the title has less information in
the filename compared to the frontmatter (because of its
sluggification): I understand that in this light the source of truth may
seem better in the frontmatter.

However, it is also possible, that we have a (text) file - with title in
its filename, but not yet any frontmatter inside the file, i.e. the
source of truth again is the filenname only.

For me, the current solution for renaming files solves the problem of
sluggification quite nicely:
1. Enter the new filename via prompt (e.g. with casing, etc.)
2. (if requested) add as frontmatter
3. sluggify and use as filename title

if the user changes the filenames title outside of Denotes oecosystem -
for whatever reasons - then of course filename title and frontmatter
title are out of sync; here the user may proceed as follows

Either:
- rename (again) the filename - but this time with Denote's rename fcn.
  which again syncs the frontmatter's title (see above)

or:
- reverse-rename, i.e. change the filename based on the available frontmatter.


>
>> I think Hanspeter had a use for the #+identifier, such as for grep
>> operations.  This was also my idea for its original inclusion.  Maybe
>> there are other workflows as well that could use it?  Perhaps external
>> tools?
>
>Do you mean that the line `#+identifier:    some_id` can be grep'ed to
>retrieve a note? Maybe this workflow can be replaced by using `find` and
>looking for a file starting with "some_id" instead.

Yes, Prot is right: grep is my use-case here.

grep / find are not interchangeable here because grep allows me to find the
identifier (in the frontmatter) OR any other arbitrary text inside the
file.

find will only regard the filename / identifier there.

>
>Jean-Philippe

Best Regards
Hanspeter

Re: Intended use-cases for renaming denote-files

Details
Message ID
<1cce800eea23f73673a01bcc751e83f5@prevos.net>
In-Reply-To
<87fsiljv1s.fsf@hu.mail-host-address-is-not-set> (view parent)
DKIM signature
pass
Download raw message
Hi Fellas,

Interesting discussion about the essence of note-taking software.

I thought a bit more about it last night and changed perspective a 
little.

The strength of Denote is that it uses filenames to store meta data in a 
convenient way. I simulated 20,000 random notes with links between them 
and Denote operated seamlessly, so that is a testament to its simplicity 
and adherence to the Unix philosophy of minimalist modular software 
development.

Linking meta-data inside files to the meta-data in the files is, as Prot 
suggested, a convenience.

Perhaps Denote it needs extension packages, for example denote-org and 
denote-md to leverage the functionalities that these file formats offer 
for in-text metadata. Somebody might perhaps develop a denote-tex 
package for LaTeX, denote-rstats for R scripts, denote-el, denote-images 
and so on. See also this discussion on file types: 
https://github.com/protesilaos/denote/issues/37




Regards

P:)


---
Dr Peter Prevos
  ---------------
peterprevos.com

On 28-07-2022 22:11, Hanspeter Gisler wrote:
> @Jean-Philippe Gagné Guay
> 
>>>> In fact, we could simplify all the rename functions to these two:
>>>> 
>>>> - `denote-add-front-matter` which adds a front-matter to a file
>>>>   without changing the filename, and
>>>> - `denote-update-filename` which takes care of getting a valid
>>>>   Denote filename, from the front matter (and current filename).
>> 
>>> What would be the use-case of the former without the latter?  Do you
>>> mean it in the sense I explained in my last message to this thread?
>>> Namely, where it would have a smart mechanism of (i) add the whole 
>>> block
>>> if all is absent, (ii) complement existing entries with the missing
>>> ones, (iii) rewrite existing entries.
>> 
>> I don't have a use-case for the former without the latter, just for
>> the latter without the former! (The `denote-update-filename` would be
>> useful on its own.) I was thinking more about providing simple and
>> general tools to handle different use-cases. But maybe they should be
>> internal functions instead of user commands.
>> 
>> I am thinking that adding reverse-rename functions will lead to more
>> complexity, but I actually prefer them to the non-reverse functions. I
>> am trying to see Denote in another angle hoping to get something 
>> simpler
>> than just adding additional commands.
>> 
>> I am going to try to list the different use-cases and how a user could
>> handle them. We can expand this list to get a clearer picture.
>> 
>> (1) Modify title/keywords through the front matter and get the
>>    filename updated.
>>    Proposition: Run `denote-update-filename`.
>> 
>> (2) Get a file "my_note.org" to a valid Denote note.
>>    Prop.: Run `denote-convert-to-denote` which would add a front
>>           matter first, then derive the filename.
>> 
>> (3) Rename an existing (and valid) Denote note.
>>    Prop.: Modify the front matter and run `denote-update-filename`.
>>           This is different from `denote-dired-rename-file`, but it
>>           is in a sense simpler because we don't have to handle all
>>           the prompts of `denote-dired-rename-file` and we don't have
>>           to confirm the changes with the user because he is already
>>           modifying the file. One issue with this is that the user
>>           will not see all the possible keywords to choose from, but
>>           it might not be a big issue.
>> 
>> (4) Maybe given a valid Denote filename but no front matter,
>>    add a front matter, but I am not sure...
>>    Prop.: Run `denote-convert-to-denote` which would handle this case
>>           as well.
>> 
>> (5) Have a Denote filename for a PDF.
>>    Prop.: Run `denote-convert-to-denote`.
>> 
>> (6) Batch operations...
>> 
>> The more general idea would be to see the front matter as THE source 
>> of
>> truth from which to derive the filename.
> 
> I believe, the filename should remain the source of truth because:
> 
> - solely its identifier is used for incomming links
> - all filetypes not having any frontmatter (e.g. PDF, epub, etc.)
>   have only the filename as 'source of truth' available.
> 
> I believe it simplifies matters (at least in 'my' head) that the source
> of truth is always the same, i.e. the filename.
> 
> Regarding your previous remark, that the title has less information in
> the filename compared to the frontmatter (because of its
> sluggification): I understand that in this light the source of truth 
> may
> seem better in the frontmatter.
> 
> However, it is also possible, that we have a (text) file - with title 
> in
> its filename, but not yet any frontmatter inside the file, i.e. the
> source of truth again is the filenname only.
> 
> For me, the current solution for renaming files solves the problem of
> sluggification quite nicely:
> 1. Enter the new filename via prompt (e.g. with casing, etc.)
> 2. (if requested) add as frontmatter
> 3. sluggify and use as filename title
> 
> if the user changes the filenames title outside of Denotes oecosystem -
> for whatever reasons - then of course filename title and frontmatter
> title are out of sync; here the user may proceed as follows
> 
> Either:
> - rename (again) the filename - but this time with Denote's rename fcn.
>   which again syncs the frontmatter's title (see above)
> 
> or:
> - reverse-rename, i.e. change the filename based on the available 
> frontmatter.
> 
> 
>> 
>>> I think Hanspeter had a use for the #+identifier, such as for grep
>>> operations.  This was also my idea for its original inclusion.  Maybe
>>> there are other workflows as well that could use it?  Perhaps 
>>> external
>>> tools?
>> 
>> Do you mean that the line `#+identifier:    some_id` can be grep'ed to
>> retrieve a note? Maybe this workflow can be replaced by using `find` 
>> and
>> looking for a file starting with "some_id" instead.
> 
> Yes, Prot is right: grep is my use-case here.
> 
> grep / find are not interchangeable here because grep allows me to find 
> the
> identifier (in the frontmatter) OR any other arbitrary text inside the
> file.
> 
> find will only regard the filename / identifier there.
> 
>> 
>> Jean-Philippe
> 
> Best Regards
> Hanspeter

Re: Intended use-cases for renaming denote-files

Details
Message ID
<877d3w5xao.fsf@protesilaos.com>
In-Reply-To
<1cce800eea23f73673a01bcc751e83f5@prevos.net> (view parent)
DKIM signature
pass
Download raw message
> From: Peter Prevos <peter@prevos.net>
> Date: Fri, 29 Jul 2022 09:58:09 +1000
>
> Hi Fellas,

Hello Peter, Hello folks,

> Interesting discussion about the essence of note-taking software.
>
> I thought a bit more about it last night and changed perspective a 
> little.

Do you still think we need the syncing we have been discussing?

> The strength of Denote is that it uses filenames to store meta data in a 
> convenient way. I simulated 20,000 random notes with links between them 
> and Denote operated seamlessly, so that is a testament to its simplicity 
> and adherence to the Unix philosophy of minimalist modular software 
> development.

This is nice to read!  If you ever publish such information, we can link
to it from Denote's manual.

> Linking meta-data inside files to the meta-data in the files is, as Prot 
> suggested, a convenience.

I still feel this way.  Though I also am in favour of keeping the
information in sync: it helps the user and makes Denote easier to
incorporate in a wider workflow that includes other tools (e.g. for a
static site generator, Org export, ...).

[ By the way, if anyone is doing something fancy along those lines,
  please write about it (in a new thread).  I am interested to learn how
  it works and, perhaps, what we can do on the Denote side of things to
  facilitate it. ]

> Perhaps Denote it needs extension packages, for example denote-org and 
> denote-md to leverage the functionalities that these file formats offer 
> for in-text metadata. Somebody might perhaps develop a denote-tex 
> package for LaTeX, denote-rstats for R scripts, denote-el, denote-images 
> and so on. See also this discussion on file types: 
> https://github.com/protesilaos/denote/issues/37

I am fine with all of this, so long as the core package retains its
feature set and does not introduce a new dependency.  By this, I mean it
is easier to keep the renaming functionality in core Denote than to
outsource it and then tell users to install that other package.

For extended functionality, I am all for integration with other tools
and am happy to help anyone who is interested to develop such a package.

About the arbitrary file types.  I have code that does this (excerpt
from my dotfiles):

    (defun prot-simple-scratch-buffer (&optional arg)
      "Produce a scratch buffer matching the current major mode.

    With optional ARG as a prefix argument (\\[universal-argument]),
    use `prot-simple-scratch-buffer-default-mode'.

    With ARG as a double prefix argument, prompt for a major mode
    with completion.  Candidates are derivatives of `text-mode' or
    `prog-mode'.

    If region is active, copy its contents to the new scratch
    buffer.

    Buffers are named as *MAJOR-MODE scratch*.  If one already exists
    for the given MAJOR-MODE, any text is appended to it."
      (interactive "P")

It could serve as an idea if anyone wants to write notes in a
programming language:

    (defun prot-simple--scratch-list-modes ()
      "List known major modes."
      (cl-loop for sym the symbols of obarray
               when (and (functionp sym)
                         (or (provided-mode-derived-p sym 'text-mode)
                             (provided-mode-derived-p sym 'prog-mode)))
               collect sym))

This could be done like the 'denote-type' command.  I did not want to
add it to Denote though, as it would complicate things with how we
determine what a note is, the preparation of the front matter, etc.  I
still think it is an interesting idea though.

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: Intended use-cases for renaming denote-files

Details
Message ID
<874jz05vyr.fsf@protesilaos.com>
In-Reply-To
<87fsiljv1s.fsf@hu.mail-host-address-is-not-set> (view parent)
DKIM signature
pass
Download raw message
Hello Hanspeter, Jean-Philippe,

> From: Hanspeter Gisler <hpgisleropen@bluewin.ch>
> Date: Thu, 28 Jul 2022 14:11:59 +0200
>
> [... 60 lines elided]
>
> I believe, the filename should remain the source of truth because:
>
> - solely its identifier is used for incomming links
> - all filetypes not having any frontmatter (e.g. PDF, epub, etc.)
>   have only the filename as 'source of truth' available.
>
> I believe it simplifies matters (at least in 'my' head) that the source
> of truth is always the same, i.e. the filename.

I think Jean-Philippe's point is that we could read the front matter and
use its data instead of using those prompts.  That would indeed remove
the step where we ask what to do with the front matter.  It is a fecund
idea and we need to consider it.

Though yes, there are scenaria where there is no front matter, so we
need the current approach or something along those lines.

About the filename being the source of truth, we could ultimately make
this a user option.  What should never be touched is the identifier.
The rest can be changed.  But I don't want to introduce options
prematurely.  Let's figure out the technicalities and the need for an
option will reveal itself.

> Regarding your previous remark, that the title has less information in
> the filename compared to the frontmatter (because of its
> sluggification): I understand that in this light the source of truth may
> seem better in the frontmatter.
>
> However, it is also possible, that we have a (text) file - with title in
> its filename, but not yet any frontmatter inside the file, i.e. the
> source of truth again is the filenname only.

In this case, and following Jean-Philippe's flow of input, we would have
a command that inserts the front matter and then asks to rename the file
accordingly.

> For me, the current solution for renaming files solves the problem of
> sluggification quite nicely:
> 1. Enter the new filename via prompt (e.g. with casing, etc.)
> 2. (if requested) add as frontmatter
> 3. sluggify and use as filename title
>
> if the user changes the filenames title outside of Denotes oecosystem -
> for whatever reasons - then of course filename title and frontmatter
> title are out of sync; here the user may proceed as follows
>
> Either:
> - rename (again) the filename - but this time with Denote's rename fcn.
>   which again syncs the frontmatter's title (see above)
>
> or:
> - reverse-rename, i.e. change the filename based on the available frontmatter.

I am fine with either workflow.

>>> I think Hanspeter had a use for the #+identifier, such as for grep
>>> operations.  This was also my idea for its original inclusion.  Maybe
>>> there are other workflows as well that could use it?  Perhaps external
>>> tools?
>>
>>Do you mean that the line `#+identifier:    some_id` can be grep'ed to
>>retrieve a note? Maybe this workflow can be replaced by using `find` and
>>looking for a file starting with "some_id" instead.
>
> Yes, Prot is right: grep is my use-case here.
>
> grep / find are not interchangeable here because grep allows me to find the
> identifier (in the frontmatter) OR any other arbitrary text inside the
> file.
>
> find will only regard the filename / identifier there.

Indeed.

Though have you tried the '-exec' flag of 'find'?  You basically combine
'find' with another command.  The earlier versions of our backlinking
facility used this approach directly.  I can retrieve it from the Git
history if you are interested.

For example (notice the '-n' flag is for 'grep'):

    find * -type f -exec grep -n "20220614T130812" {} +

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com

Take a random walk through your notes

Details
Message ID
<010e087a73d9dec2ad09a1b323f7f8dd@prevos.net>
In-Reply-To
<874jz05vyr.fsf@protesilaos.com> (view parent)
DKIM signature
pass
Download raw message
I love to take a random walks through my digital notes. Making random 
connections is a useful pathway to creativity.

So I wrote this function to help me walk through my Denote folder:

   (defun denote-open-random-note ()
     "Open a random Denote file to start a random walk."
     (interactive)
     (let ((denotes (directory-files denote-directory nil 
denote--id-regexp)))
       (find-file (nth (random (length denotes)) denotes))))

Happy walking!

Regards

---
Dr Peter Prevos
  ---------------
peterprevos.com

Re: Take a random walk through your notes

Details
Message ID
<87edy4m9r3.fsf@protesilaos.com>
In-Reply-To
<010e087a73d9dec2ad09a1b323f7f8dd@prevos.net> (view parent)
DKIM signature
pass
Download raw message
> From: Peter Prevos <peter@prevos.net>
> Date: Fri, 29 Jul 2022 20:18:29 +1000

Hello Peter,

> I love to take a random walks through my digital notes. Making random 
> connections is a useful pathway to creativity.

Interesting workflow!

> So I wrote this function to help me walk through my Denote folder:
>
> [... 6 lines elided]

For the "denotes" part, note that we also provide the function
'denote--directory-files'.  It (i) only matches "notes", meaning no
PDFs, videos, etc., (ii) it is recursive for the 'denote-directory', and
(iii) can return absolute file paths.

About the workings of 'random' function, you may also want to omit the
current entry from the list?  For large sets this would be unnecessary,
but otherwise it can be useful.

Compare this:

    (let ((denotes '("one" "two" "three")))
      (nth (random (length denotes)) denotes))

To this:

    (let* ((denotes (copy-sequence '("one" "two" "three")))
           (current "one")
           (denote-no-current (delete current denotes)))
      (nth (random (length denote-no-current)) denote-no-current))

The 'current' could be 'buffer-file-name', but you get the idea.

I guess this concept can be expanded further to take you to a random
note in, say, your "_journal" entries (e.g. prompt and then randomise).

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: Intended use-cases for renaming denote-files

Details
Message ID
<CAEo8kH6yiBbW7Dtfm7jPpxm5=55z=NNLeB2g+K4bHbfc_sqaMw@mail.gmail.com>
In-Reply-To
<874jz05vyr.fsf@protesilaos.com> (view parent)
DKIM signature
pass
Download raw message
Hello Hanspeter, Protesilaos

I suggest we keep the concern of converting non-Denote notes to Denote
separate from that of modifying an existing note. Quoting myself from
issue #48 on Github:

> Since `denote-dired-rename-file` already does a lot, I think I would
  create a distinct function for conversion purpose. The purpose of a
  function like `denote-dired-rename-file` is really just to change
  the title and add/remove keywords. Overloading it with code that
  does file conversion might make it hard to maintain and its
  docstring would have to explain its dual purpose, which could be
  confusing to users.

I have noticed this in a previous message:

> We also have a question of ergonomics. Two commands are overkill.
  They can confuse the user and are harder to explain. Can we
  consolidate all three of the "rewrite", "complement", "add"
  operations? If yes, then this is the right thing to do. Too many
  options end up being to our detriment.

At one point, we had two distinct functions `denote-dired-rename-file`
and `denote-dired-convert-file-to-denote`, but the latter got renamed
to `denote-dired-rename-file-and-add-front-matter` (by me in fact). I
think we are slowly going back to one big function with two distinct
purposes.

I propose the following functions to handle the task of modifying
existing Denote notes:

denote-rename-file (current note, using prompts)
denote-rename-file-using-front-matter (curr note, using front matter)
denote-rename-marked-files (using prompts)
denote-rename-marked-files-using-front-matter (using front matter)
denote-rename-files-dwim (Calls the previous functions depending
        on the context (marked files or current file). I prefer the
        "front matter" route, but we can make it use the "prompts"
        route.)

For the task of converting a non-Denote file to Denote, I think we
could have:

denote-convert-file-to-denote
denote-convert-marked-files-to-denote

A typical user would probably just use `denote-rename-files-dwim` and
`denote-convert-file-to-denote` (for the two distinct use-cases
specified above), but the other commands would be available for more
control. All commands would be implemented using common building
blocks, so none of them would be that big.

----

In the original message of this thread, Hanspeter asked:

> Perhaps, I do not understand the intended use-cases of the current
> solution?

I hope this message is helping you understand the history behind
the current commands.

In the original message, Hanspeter also asked how a given file with
possibly missing information (such as a missing #'identifier) in the
front matter can be fixed. My solution to this would be that we will
have to be smarter when implementing `denote-convert-file-to-denote`
and not simply "add a front matter unconditionally", but instead use
the existing data, when available.

Re: Intended use-cases for renaming denote-files

Details
Message ID
<87ilnerf16.fsf@hu.mail-host-address-is-not-set>
In-Reply-To
<874jz05vyr.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Protesilaos Stavrou <info@protesilaos.com> writes:

Hello Prot & Hello Jean-Philippe,

[...]

>> I believe, the filename should remain the source of truth because:
>>
>> - solely its identifier is used for incomming links
>> - all filetypes not having any frontmatter (e.g. PDF, epub, etc.)
>>   have only the filename as 'source of truth' available.
>>
>> I believe it simplifies matters (at least in 'my' head) that the source
>> of truth is always the same, i.e. the filename.
>
> I think Jean-Philippe's point is that we could read the front matter and
> use its data instead of using those prompts.  That would indeed remove
> the step where we ask what to do with the front matter.  It is a fecund
> idea and we need to consider it.

So, if I understand you two correctly, this would mean:

1. the user calls the function the 'reverse-rename' function
   (sorry, for always comming back my own naming, this is just to prevent
   mish-mash in my head, I am not expecting the final function to be
   named like this)

2. the new filename's title and keyword parts are either:
   a) taken directly from existing values,
      defined by #+title and/or #+filetags of the file's content, or
   b) prompted from the user, if one of them / they are missing in the
      file's content 
   c) the identifier of the filename is
      - retained, if it already existed
      - newly created, based on existing mechanism (i.e. file creation)

3. possibly missing frontmatter key/values
   (title, filetags, date, identifier)
   are complemented.

Correct?

The other renaming function - let's call it 'forward-rename' -
does more or less the reverse:

1. the user calls the 'forward-rename' function and

2. gets prompted for title and filetags
   (prefilled by existing title and filetags)

3. and the user is also asked whether to apply them also to the frontmatter
   (if the filetype is suitable)
   - and if this is the case, the frontmatter is added / complemented

4. the file is renamed accordingly.

Correct?

This makes sense to me as well.


[...]

>> However, it is also possible, that we have a (text) file - with title in
>> its filename, but not yet any frontmatter inside the file, i.e. the
>> source of truth again is the filenname only.
>
> In this case, and following Jean-Philippe's flow of input, we would have
> a command that inserts the front matter and then asks to rename the file
> accordingly.

Does this behavior really make sense for all users?

I mean, if a user just wants to use Denote's file naming scheme
(and of course it's linking capability)
but not necesssarily in the frontmatter insertion into the file contents,
he has no opt-out, yes? 


[...]

>> grep / find are not interchangeable here because grep allows me to find the
>> identifier (in the frontmatter) OR any other arbitrary text inside the
>> file.
>>
>> find will only regard the filename / identifier there.
>
> Indeed.
>
> Though have you tried the '-exec' flag of 'find'?  You basically combine
> 'find' with another command.  The earlier versions of our backlinking
> facility used this approach directly.  I can retrieve it from the Git
> history if you are interested.
>
> For example (notice the '-n' flag is for 'grep'):
>
>     find * -type f -exec grep -n "20220614T130812" {} +

I'm no expert in all the possibilities of find ... -exec grep ...

I understand it like this:

- I have to feed 'find-part' parts of the filename to look for
  (e.g. words from the title or filetags)

- Then, I have to feed the 'grep-part' the keywords of the
  file's content to look for

i.e.
I have to know in advance, which words I am interested in are
part of the filename and which are part of the file's content.

What I am looking for, however, is the possibility to just
enter the words for searching, be they part of the filename
or the file's content.

The frontmatter (and the use of grep) solve this problem nicely.

>
> All the best,
> Prot
>
> -- 
> Protesilaos Stavrou
> https://protesilaos.com

Same to you.

Re: Intended use-cases for renaming denote-files

Details
Message ID
<87fsiirdsk.fsf@hu.mail-host-address-is-not-set>
In-Reply-To
<1cce800eea23f73673a01bcc751e83f5@prevos.net> (view parent)
DKIM signature
missing
Download raw message
Peter Prevos <peter@prevos.net> writes:

> Hi Fellas,

Hello Peter, et al.

>
> Interesting discussion about the essence of note-taking software.
>
> I thought a bit more about it last night and changed perspective a 
> little.
>
> The strength of Denote is that it uses filenames to store meta data in a 
> convenient way. I simulated 20,000 random notes with links between them 
> and Denote operated seamlessly, so that is a testament to its simplicity 
> and adherence to the Unix philosophy of minimalist modular software 
> development.

I've read your article on this.
This is great!

>
> Linking meta-data inside files to the meta-data in the files is, as Prot 
> suggested, a convenience.
>
> Perhaps Denote it needs extension packages, for example denote-org and 
> denote-md to leverage the functionalities that these file formats offer 
> for in-text metadata. Somebody might perhaps develop a denote-tex 
> package for LaTeX, denote-rstats for R scripts, denote-el, denote-images 
> and so on. See also this discussion on file types: 
> https://github.com/protesilaos/denote/issues/37

I also believe it to be a good approach,
keeping Denote's core minimal - regarding functionality and complexity.

This should always be guiding principle in developing software.
Most of the time it is, however, not so easy to define:
What is core- and what is non-core-functionality.

Denote supports core functionality for a couple of text formats (org,
md, etc.), e.g. linking is supported for all of them.

One way to decide, perhaps, whether some new functionality
belongs to core-Denote may be to ask:

"Can this new functionality be implemented for all supported text formats?"

- if yes: it belongs into core
- of no:  it perhaps better belongs into some 3rd party package,
  depending itself on Denote

As renaming Denote files as well as frontmatter format is supported
for all supported text formats (org, md, ...), it would make to me 
keeping related new functionality also in core.


>
>
>
>
> Regards
>
> P:)
>
>
> ---
> Dr Peter Prevos
>   ---------------
> peterprevos.com
>
> On 28-07-2022 22:11, Hanspeter Gisler wrote:
>> @Jean-Philippe Gagné Guay
>> 
>>>>> In fact, we could simplify all the rename functions to these two:
>>>>> 
>>>>> - `denote-add-front-matter` which adds a front-matter to a file
>>>>>   without changing the filename, and
>>>>> - `denote-update-filename` which takes care of getting a valid
>>>>>   Denote filename, from the front matter (and current filename).
>>> 
>>>> What would be the use-case of the former without the latter?  Do you
>>>> mean it in the sense I explained in my last message to this thread?
>>>> Namely, where it would have a smart mechanism of (i) add the whole 
>>>> block
>>>> if all is absent, (ii) complement existing entries with the missing
>>>> ones, (iii) rewrite existing entries.
>>> 
>>> I don't have a use-case for the former without the latter, just for
>>> the latter without the former! (The `denote-update-filename` would be
>>> useful on its own.) I was thinking more about providing simple and
>>> general tools to handle different use-cases. But maybe they should be
>>> internal functions instead of user commands.
>>> 
>>> I am thinking that adding reverse-rename functions will lead to more
>>> complexity, but I actually prefer them to the non-reverse functions. I
>>> am trying to see Denote in another angle hoping to get something 
>>> simpler
>>> than just adding additional commands.
>>> 
>>> I am going to try to list the different use-cases and how a user could
>>> handle them. We can expand this list to get a clearer picture.
>>> 
>>> (1) Modify title/keywords through the front matter and get the
>>>    filename updated.
>>>    Proposition: Run `denote-update-filename`.
>>> 
>>> (2) Get a file "my_note.org" to a valid Denote note.
>>>    Prop.: Run `denote-convert-to-denote` which would add a front
>>>           matter first, then derive the filename.
>>> 
>>> (3) Rename an existing (and valid) Denote note.
>>>    Prop.: Modify the front matter and run `denote-update-filename`.
>>>           This is different from `denote-dired-rename-file`, but it
>>>           is in a sense simpler because we don't have to handle all
>>>           the prompts of `denote-dired-rename-file` and we don't have
>>>           to confirm the changes with the user because he is already
>>>           modifying the file. One issue with this is that the user
>>>           will not see all the possible keywords to choose from, but
>>>           it might not be a big issue.
>>> 
>>> (4) Maybe given a valid Denote filename but no front matter,
>>>    add a front matter, but I am not sure...
>>>    Prop.: Run `denote-convert-to-denote` which would handle this case
>>>           as well.
>>> 
>>> (5) Have a Denote filename for a PDF.
>>>    Prop.: Run `denote-convert-to-denote`.
>>> 
>>> (6) Batch operations...
>>> 
>>> The more general idea would be to see the front matter as THE source 
>>> of
>>> truth from which to derive the filename.
>> 
>> I believe, the filename should remain the source of truth because:
>> 
>> - solely its identifier is used for incomming links
>> - all filetypes not having any frontmatter (e.g. PDF, epub, etc.)
>>   have only the filename as 'source of truth' available.
>> 
>> I believe it simplifies matters (at least in 'my' head) that the source
>> of truth is always the same, i.e. the filename.
>> 
>> Regarding your previous remark, that the title has less information in
>> the filename compared to the frontmatter (because of its
>> sluggification): I understand that in this light the source of truth 
>> may
>> seem better in the frontmatter.
>> 
>> However, it is also possible, that we have a (text) file - with title 
>> in
>> its filename, but not yet any frontmatter inside the file, i.e. the
>> source of truth again is the filenname only.
>> 
>> For me, the current solution for renaming files solves the problem of
>> sluggification quite nicely:
>> 1. Enter the new filename via prompt (e.g. with casing, etc.)
>> 2. (if requested) add as frontmatter
>> 3. sluggify and use as filename title
>> 
>> if the user changes the filenames title outside of Denotes oecosystem -
>> for whatever reasons - then of course filename title and frontmatter
>> title are out of sync; here the user may proceed as follows
>> 
>> Either:
>> - rename (again) the filename - but this time with Denote's rename fcn.
>>   which again syncs the frontmatter's title (see above)
>> 
>> or:
>> - reverse-rename, i.e. change the filename based on the available 
>> frontmatter.
>> 
>> 
>>> 
>>>> I think Hanspeter had a use for the #+identifier, such as for grep
>>>> operations.  This was also my idea for its original inclusion.  Maybe
>>>> there are other workflows as well that could use it?  Perhaps 
>>>> external
>>>> tools?
>>> 
>>> Do you mean that the line `#+identifier:    some_id` can be grep'ed to
>>> retrieve a note? Maybe this workflow can be replaced by using `find` 
>>> and
>>> looking for a file starting with "some_id" instead.
>> 
>> Yes, Prot is right: grep is my use-case here.
>> 
>> grep / find are not interchangeable here because grep allows me to find 
>> the
>> identifier (in the frontmatter) OR any other arbitrary text inside the
>> file.
>> 
>> find will only regard the filename / identifier there.
>> 
>>> 
>>> Jean-Philippe
>> 
>> Best Regards
>> Hanspeter
Reply to thread Export thread (mbox)