emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Document date and last updated date


From: Sebastien Vauban
Subject: Re: [O] Document date and last updated date
Date: Tue, 07 Feb 2012 23:29:36 +0100
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.92 (windows-nt)

Hi all,

Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>
>> Speaking of hyperref and its _document properties_, it makes me think of a
>> generic point for which I don't have yet a really satisfactory solution, that
>> is about handling dates.
>>
>> In a PDF document, regarding dates, we have (see output of `pdfinfo'):
>>
>> - creation date
>> - modification date
>>
>> In Org, we have the `#+DATE:' info keyword, with the date that's supposed to
>> be exported onto the final document format (HTML, PDF, OOo, etc.).
>>
>> But we don't see when the document has been updated for the last time --
>> neither when it has been created.
>>
>> For the former point (date of last update), I've customized Org so that the
>> `time-stamp' package updates time stamps every time you save the Org buffer:
>>
>> #+begin_src emacs-lisp
>>   (add-hook 'before-save-hook 'time-stamp)
>>
>>   (add-hook 'org-mode-hook
>>             (lambda ()
>>               ;; file modification date
>>               (set (make-local-variable 'time-stamp-format) "%:y-%02m-%02d")
>>               (set (make-local-variable 'time-stamp-start) "^#\\+DATE: +")
>>               (set (make-local-variable 'time-stamp-end) "$")))
>> #+end_src
>>
>> That makes my `#+DATE:' info keyword always *up-to-date*.
>>
>> Though, in some cases:
>>
>> - I must print a document with a future date (for example, I'm preparing
>>   slides which I will present on next Monday) -- hence, the above breaks 
>> this,
>>   because I'd like to have next Monday's date already printed on my slides 
>> (at
>>   least on the title page).
>>
>> - it would be nice to get keep track of the creation date of the Org 
>> document,
>>   though this is not really necessary.
>>
>> Clearly, I should not make the `#+DATE:' info keyword updated, to keep it for
>> its export function (as the official date to be printed on the title page),
>> but then it'd be good to have at least a last modification date
>> somewhere.
>>
>> What do you think of all this?  How do you do to keep more info on
>> dates?
>
> Export systems already provide a {{{modification-time(format-string)}}}
> macro by default.

Thanks for suggesting this solution which escaped me, but that's only for
export purpose.

As suggested by the above "hack", I find it nice (in fact, even useful) to
have a least 2 dates in the Org buffer itself:

- a date for export purpose (an official one, to be printed on the document
  title page, and so on);

- a "last modified date" in the Org buffer is always useful, knowing that you
  can have the desire to update the file without touching the "official
  date" : it can be before or after the official date (for example, correcting
  a typo you found in slides you've presented yesterday)[1];

- optionally, a "creation date" -- once again in the Org source.

>> Some global `draft' or `final' info could make some sense too.
>
> Isn't it too much back-end specific?

It could be, you're right. Just drop this one.

Best regards,
  Seb

Footnotes:

[1] That does not mean that you shouldn't see, in that case, the 2 dates
somewhere -- or the official date plus some sort of revision number.

-- 
Sebastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]