File modification date

File modification date

[Sébastien Vauban]

Hi,

I've always found the DATE header to be kind of useless, as it only indicates
the creation date of the file.

For me, it would be better if it would be the last edit date as it is the case
with the Emacs time-stamp.

Here a proposition to make this automagic:

--8<---------------cut here---------------start------------->8---
(add-hook 'org-mode-hook
          (lambda ()
            (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) "$")))
--8<---------------cut here---------------end--------------->8---

Of course, `time-stamp-format' may be changed according to your taste.

Shouldn't be such a thing be the default?

Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: File modification date

[Carsten Dominik]

On Aug 20, 2009, at 10:12 AM, Sébastien Vauban wrote:

> Hi,
>
> I've always found the DATE header to be kind of useless, as it only  
> indicates
> the creation date of the file.
>
> For me, it would be better if it would be the last edit date as it  
> is the case
> with the Emacs time-stamp.
>
> Here a proposition to make this automagic:
>
> --8<---------------cut here---------------start------------->8---
> (add-hook 'org-mode-hook
>          (lambda ()
>            (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) "$")))
> --8<---------------cut here---------------end--------------->8---
>
> Of course, `time-stamp-format' may be changed according to your taste.
>
> Shouldn't be such a thing be the default?


DATE was implemented exactly to specify a fixed date.  You can get
the modification date with

     {{{modification-time(%Y-%m-%d)}}}

and the current date with

     {{{date(%Y-%m-%d)}}}

These will be expanded upon export.  So you can, in fact, do

     #+DATE: {{{modification-time(%Y-%m-%d)}}}

HTH

- Carsten

Re: File modification date

[Eric S Fraga, Eric S Fraga]

At Thu, 20 Aug 2009 11:12:54 +0200,
Sébastien Vauban wrote:

> I've always found the DATE header to be kind of useless, as it only indicates
> the creation date of the file.

I agree completely and have typically used emacs's time-stamp as well
although I never thought of putting the settings into a hook (I
typically use emacs's own local variables for individual files)!
Thanks for that.

Re: File modification date

[Sébastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On Aug 20, 2009, at 10:12 AM, Sébastien Vauban wrote:
>>
>> I've always found the DATE header to be kind of useless, as it only
>> indicates the creation date of the file.
>>
>> For me, it would be better if it would be the last edit date as it is the
>> case with the Emacs time-stamp.
>>
>> Here a proposition to make this automagic:
>>
>> --8<---------------cut here---------------start------------->8---
>> (add-hook 'org-mode-hook
>>          (lambda ()
>>            (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) "$")))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Of course, `time-stamp-format' may be changed according to your taste.
>>
>> Shouldn't be such a thing be the default?

Coming back to my old post, and your answer...


> DATE was implemented exactly to specify a fixed date. You can get the
> modification date with
>
>     {{{modification-time(%Y-%m-%d)}}}
>
> and the current date with
>
>     {{{date(%Y-%m-%d)}}}
>
> These will be expanded upon export.  So you can, in fact, do
>
>     #+DATE: {{{modification-time(%Y-%m-%d)}}}

The problem is that the author does not see anymore the "last modification
date", then, except in the PDF output.

And, in fact, if that Org file is put under VC, you can have two people
printing (exporting) the exact same document and it would still have a
different date. That's because, by default, the original modification date is
not kept on the file system when checking out a file from Subversion (my
current VC system).

To do so, one need to set to his =.subversion/config=:

#+BEGIN_SRC sh
# keep the modification time from the repository, for Makefiles, etc.
use-commit-times = yes
#+END_SRC

So, I find it would be good for the author to see the "real" last modification
date (which, moreover, can be different from the "copy" date of the file in
your file system).

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: File modification date

[Francesco Pizzolante]

Hi,

>> DATE was implemented exactly to specify a fixed date. You can get the
>> modification date with
>>
>>     {{{modification-time(%Y-%m-%d)}}}
>>
>> and the current date with
>>
>>     {{{date(%Y-%m-%d)}}}
>>
>> These will be expanded upon export.  So you can, in fact, do
>>
>>     #+DATE: {{{modification-time(%Y-%m-%d)}}}
>
> The problem is that the author does not see anymore the "last modification
> date", then, except in the PDF output.
>
> And, in fact, if that Org file is put under VC, you can have two people
> printing (exporting) the exact same document and it would still have a
> different date. That's because, by default, the original modification date is
> not kept on the file system when checking out a file from Subversion (my
> current VC system).
>
> To do so, one need to set to his =.subversion/config=:
>
> #+BEGIN_SRC sh
> # keep the modification time from the repository, for Makefiles, etc.
> use-commit-times = yes
> #+END_SRC
>
> So, I find it would be good for the author to see the "real" last modification
> date (which, moreover, can be different from the "copy" date of the file in
> your file system).

In the same line of thinking, it would be good to keep trace of the "real"
creation date too and, as you suggest it, by completely separating these dates
from the file system dates.

What matters here are the dates corresponding to the content of the file, not
the file itself. And those dates could be exported to the PDF as well (or
other types of exportations).

In order to clarify my point of view, I see 3 important dates to keep:

1) The creation date:

   It could be defined with

   #+CREATED: 2009-12-01 09:36  or  #+CREATION_DATE: 2009-12-01 09:36

   and, when exporting to LaTeX, it would be exported to

   \pdfinfo{/CreationDate (D:200912010936)}.

   It will then appear in the PDF properties of the exported document as

   Created: 2009/12/01 09:36:00.

   This date is defined once and never updated. It can even be added
   automatically by the C-c C-e t command when creating a new buffer.


2) The modification date:

   It could be defined with

   #+MODIFIED: 2009-12-07 16:45  or  #+MODIFICATION_DATE: 2009-12-07 16:45

   and, when exporting to LaTeX, it could be exported to

   \pdfinfo{/ModDate (D:200912071645)}.

   It will then appear in the PDF properties of the exported document as

   Modified: 2009/12/07 16:45:31.

   This is the date that you will see updated each time that you change and
   save your org buffer. It could be done automatically with org-mode.


3) The last date is the date you want to display in your document (in effect,
   the one that is exported as \date(XXX) in LaTeX).

   This date could be the last modification date (in this case, you would not
   need to specify it) or give it a fixed value (in this case, you specify it
   as it works now: #+DATE: 2009-12-09).


With these dates, a document would contain all the information regarding it's
life cycle independently of the file system. And, in addition, the information
would be propagated in the exported documents.

What do you all think?

Regards
Francesco


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode