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.

>> 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

Hello!

I would like to add comments on the `reverse-rename` functionality
and other refactors.

About the syncing of the front matter with the filename, I think we
can only have it one way: from the front matter to the filename. This
is because of the sluggification process. There are constraints on the
characters allowed in the filename (and keywords), but they are in
their raw form in the front matter.

As a user, I would also like to be able to get my filename and front
matter in sync. For example, if I change the title or keywords in the
front matter, then run some `denote-update-filename` command, Denote