Hello Prot,

While I completely understand and support your decision to move Denote
development over to Github, I'd like to say:

Denote was the first project I used after 2008 where I had to push
patches to a mailing list for contributing, and I was so happy about
how easy the process is, as compared to PRs on Github. I know that I
am probably in the minority here, but I'm genuinely sad that the
developer community considers PRs easier.

I read through your post[1] and I can see how the email based workflow
is terrible for maintainers, but I must say that it is a breeze for
contributors :)

Where there are no files matching the input regex,
`denote-sort-get-directory-files` returns nil. Passing this to `dired`
throws an error:
```
(file-missing "Reading directory" "No such file or directory" ".../denote/Testing Dired")
```

This commit handles the empty case by returning an appropriate error
message.
---
 denote-sort.el | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/denote-sort.el b/denote-sort.el
[message trimmed]

Based on the bug found in the previous commit, I looked at all the
call-sites for `denote-sluggify-signature` and
`denote-retrieve-filename-signature` and found two other places:

1. `denote-rename-file`: Add check to ensure signature exists when
   trying to sluggify it.

2. `denote-rename-file-using-front-matter`: Sluggify the signature
   before creating the new file-name.
---
 denote.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/denote.el b/denote.el
[message trimmed]

I hit this bug when I called `M-x
denote-dired-rename-marked-files-with-keywords` on the file at point
in a dired buffer. The stack-trace is as follows:

```
Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  replace-regexp-in-string("[][{}!@#$%^&*()=+'\"?,.|;:~`‘’“”/]*-" "" nil)
  denote--slug-no-punct(nil "-")
  denote-sluggify-signature(nil)
  denote-dired-rename-marked-files-with-keywords()
  ```

`denote-sluggify-signature` gets a `nil` input which it cannot handle.
This happens because the signature is extracted using
[message trimmed]

I hit this bug when I called `M-x
denote-change-file-type-and-front-matter` on an Org file with empty
filetags, to convert it to Markdown-YAML format.

This is the front-matter of the original file:
```
   #+title:      Great Content is the Heart of Audience Building
   #+filetags:
   #+date:       [2023-03-08 Wed 18:51]
   #+identifier: 20230308T185100
```

The stack-trace is as follows:
```
[message trimmed]

I hit this bug when I did the following:

1. Modify the default `denote-rename-buffer-format` from "%t" to
   "%s %t" to display signatures
2. Open a Denote file which did not have a signature.
3. Wonder why the buffer did not show up in buffer-listing functions,
   and why undo wouldn't work on it and so on.

The answer is here:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Names.html#Buffer-Names

    > Buffers that are ephemeral and generally uninteresting to the
    > user have names starting with a space, so that the list-buffers
    > and buffer-menu commands don't mention them (but if such a
[message trimmed]

---
 denote.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/denote.el b/denote.el
index 1debafb..1e4b296 100644
--- a/denote.el
+++ b/denote.el
@@ -3169,8 +3169,8 @@ Optional ID-ONLY has the same meaning as in the command
    command
    (if (eq command 'denote-signature)
        #'denote--link-get-description-with-signature
-     #'denote--link-get-description
-     id-only)))
[message trimmed]

Thank you Prot.

I have updated to the latest version of Denote today and will test the
changes to ensure everything is working properly.

For the rest of the changes in this patch, should I copy them over to
denote-silo-extras and create a new patch? Or will you be adding it
slowly post testing on your end?

Let me know!


On Wed, Sep 20, 2023 at 3:47 PM Protesilaos Stavrou
<info@protesilaos.com> wrote:

Strong +1 to local-time everywhere, exactly for the reasons nobiot outlines.

On Fri, Sep 22, 2023 at 8:44 PM Noboru <me@nobiot.com> wrote:
>
>
> > Perhaps we should default to UTC?
>
> Independent of this issue, personally I prefer
> the way it is now: local time everywhere. It sort
> of captures the moment of the time I
> experience—even if I was jet-lagged by flying
> from Paris to Tokyo, as an example, it “was”
> four in the morning I wrote this piece; not
> 08:00:00 in UTC.

PS: Sorry for top-posting, I missed it and hit send too quickly :(