Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Org mode dates #27

Closed
pprevos opened this issue Jun 30, 2022 · 12 comments
Closed

Org mode dates #27

pprevos opened this issue Jun 30, 2022 · 12 comments

Comments

@pprevos
Copy link
Sponsor Contributor

pprevos commented Jun 30, 2022

The default for org mode headers is now:

#+date: 2022-06-10

The Org mode data format is that the numbers are between square brackets. Formatting dates this way provides entry to other Org functionality.

#+date: [2022-06-10]

Is that possible to implement?

@protesilaos
Copy link
Owner

Hello @pprevos!

You are right. The user option denote-front-matter-date-format
provides the possibility to use an Org timestamp or a custom format.

Perhaps we should review the default value here. It is better if we do
the right thing out-of-the-box.

What do you think?

[I'll keep this open for a little while in case someone else wants to
join the discussion ]

@kaushalmodi
Copy link
Contributor

kaushalmodi commented Jun 30, 2022

Related:

(defcustom denote-front-matter-date-format nil
(9bf1043)

I set that defcustom to org-timestamp as I like to record both date and time (helps sort the notes in chronological order if more than one note is written in a day).

@protesilaos
Copy link
Owner

protesilaos commented Jun 30, 2022

@kaushalmodi What do you think about changing the defaults? Kind of how
the default for Markdown is different. It seems appropriate to use a
file-specific format for each case. We can retain the option of a
custom format.

The option could then be changed to something like denote-date-format.
Sample doc string:

When nil, use a file-type-specific format.

- For Org, an inactive timestamp is used, such as [2022-06-30 Wed 06:19].

- For Markdowmn, the RFC3339 standard is applied: 2022-06-30T15:48:00+03:00

- For plain text, the format is 2022-06-30.

If the value a string, use it as the argument of `format-time-string'.
Read the documentation of that function for valid format specifiers.

EDIT: Remove the quotes from nil.

EDIT2: Clarify that timestamp is inactive.

@kaushalmodi
Copy link
Contributor

What do you think about changing the defaults? Kind of how
the default for Markdown is different. It seems appropriate to use a
file-specific format for each case.

I like that approach. Thanks.

protesilaos added a commit that referenced this issue Jun 30, 2022
The old user option 'denote-front-matter-date-format' is deprecated.  It
is superseded by 'denote-date-format'.

Now we use an inactive timestamp for Org, the RFC3339 standard for
Markdown (YAML or TOML), and the ISO 8601 format for plain text.

The user can specify a string value for 'denote-date-format', which
contains format specifiers as described in the doc string of
'format-time-string'.

Thanks to Peter Prevos and Kaushal Modi for the discussion in issue 27
over at the GitHub mirror: <#27>.
@protesilaos
Copy link
Owner

I like that approach. Thanks.

Great! Pushed the changes:

  commit e59b606e1924a7a3e536597cb309d1c71d67d380
  Author: Protesilaos Stavrou <info@protesilaos.com>
  Date:   Thu Jun 30 16:13:29 2022 +0300

      Use better default for file dates in front matter

      The old user option 'denote-front-matter-date-format' is deprecated.  It
      is superseded by 'denote-date-format'.

      Now we use an inactive timestamp for Org, the RFC3339 standard for
      Markdown (YAML or TOML), and the ISO 8601 format for plain text.

      The user can specify a string value for 'denote-date-format', which
      contains format specifiers as described in the doc string of
      'format-time-string'.

      Thanks to Peter Prevos and Kaushal Modi for the discussion in issue 27
      over at the GitHub mirror: <https://github.com/protesilaos/denote/issues/27>.

   README.org | 48 ++++++++++++++++++++++++------------------------
   denote.el  | 39 +++++++++++++++++++--------------------
   2 files changed, 43 insertions(+), 44 deletions(-)

I think this provides a better experience out-of-the-box.

Please let me know if there is something else that needs to be done.

@kaushalmodi
Copy link
Contributor

Thanks! Now my denote config is down to just one setting 😃

(setq denote-link-use-org-id t)

@protesilaos
Copy link
Owner

Thanks! Now my denote config is down to just one setting 😃

Hehe! I am fine with this. In general, I believe we should strive to
have good defaults so that things "just work" out-of-the-box.

Should we start a new thread about it? Ideally, we can get feedback
from a few users before making any changes. Just to learn how they
approach the issue.

@kaushalmodi
Copy link
Contributor

Should we start a new thread about it?

No, let's see if there's a real need for that; let's see if someone opens an issue for that or emails on the mailing list. Thanks for all your work.

@protesilaos
Copy link
Owner

No, let's see if there's a real need for that [...]

Okay.

Thanks for all your work.

You're welcome!

@pprevos
Copy link
Sponsor Contributor Author

pprevos commented Jun 30, 2022

Nice to see that when I wake up in Australia, all this work has been done.

By the way, I am an Org Roam experimenting with using both systems side-by-side for now. The denote header is fully compatible with Org roam, which will register any file with an ID tag.

@pprevos pprevos closed this as completed Jun 30, 2022
@protesilaos
Copy link
Owner

protesilaos commented Jul 1, 2022

By the way, I am an Org Roam experimenting with using both systems
side-by-side for now. The denote header is fully compatible with Org
roam, which will register any file with an ID tag.

Good to know! This suggests that you might also want to opt in to links
between Denote's notes that use the standard id: hyperlink type
instead of denote:. The variable is denote-link-use-org-id and must
be set to t.

protesilaos added a commit that referenced this issue Jul 1, 2022
This ensures that we provide the best experience for Org users
out-of-the-box.  The 'id:' hyperlink type is standard, making our notes
interoperable.

This change should not have negative implications for existing users.
We have already taken care to ensure that links from Org notes to other
file type notes (e.g. Markdown) use the 'denote:' hyperlink type.  In
other words, we apply the standard when appropriate, else fall back to
our own mechanism.

Thanks to Kaushal Modi and Peter Prevos for the feedback in issue 27
over at the GitHub mirror: <#27>.
@protesilaos
Copy link
Owner

I changed the default value of denote-link-use-org-id to t. I think
compatibility with the wider Org ecosystem is important and is one of
our goals to be a good Emacs citizen.

  commit 2193501cef4e91bb7b8d4d436484ea429ddd2084
  Author: Protesilaos Stavrou <info@protesilaos.com>
  Date:   Fri Jul 1 06:53:01 2022 +0300

      Change default value of denote-link-use-org-id

      This ensures that we provide the best experience for Org users
      out-of-the-box.  The 'id:' hyperlink type is standard, making our notes
      interoperable.

      This change should not have negative implications for existing users.
      We have already taken care to ensure that links from Org notes to other
      file type notes (e.g. Markdown) use the 'denote:' hyperlink type.  In
      other words, we apply the standard when appropriate, else fall back to
      our own mechanism.

      Thanks to Kaushal Modi and Peter Prevos for the feedback in issue 27
      over at the GitHub mirror: <https://github.com/protesilaos/denote/issues/27>.

   README.org     | 7 +++++--
   denote-link.el | 8 ++++----
   2 files changed, 9 insertions(+), 6 deletions(-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants