emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [bug?, ox-odt] Format DATE


From: Christian Moe
Subject: Re: [O] [bug?, ox-odt] Format DATE
Date: Mon, 10 Nov 2014 09:53:20 +0100
User-agent: mu4e 0.9.9.5-dev6; emacs 24.3.1

[Forgot to "reply all", so part of the below discussion happened
off-list. Sorry. Back on track now. CM]

Rasmus writes:

> Hi Christian,
>
> Thanks for the helpful email.  Note that you did not sent it to the
> ML, though.
>
> Christian Moe <address@hidden> writes:
>
>> Going by the documentation of org-odt-use-date-fields, the data styles
>> "OrgDate1" and "OrgDate2" are supposed to be mapped from
>> org-time-stamp-custom-formats, rather than
>> org-export-date-timestamp-format. 
>
> Yeah, I saw that, but the description of
> `org-time-stamp-custom-formats' looks a bit opaque.  I wondered if it
> would affect the recognition of timestamps in buffer (since the
> variable is not an org-export-· variable).  If it's truly *only*
> affecting exports it should be renamed.

No, judging by the manual entry, it was intended for customizing the
appearance of timestamps in the buffer, which it does, see below. To
accommodate people who think ISO time format is just too darned
/sensible/...

But it has the nice (and little-mentioned) side effect that you can use
it to change the appearance of timestamps in exports, where
non-geeky-looking everyday-language dates are often comme il faut. Works
nicely in HTML, for instance, except that you still get geeky-looking
brackets around the dates (may need a filter to remove those).

It's nice, for instance, if you have a document with a lot of dates in a
European format and need to switch to an American format; you can do it
by changing a setting.

And the ODT exporter builds on this to give date fields that can be
further changed in LibreOffice.

>> So this will apply to the output from the DATE keyword too.
>>
>> To make this happen, org-display-custom-times must be non-nil. 
>> This affects not only the date in the heading from the DATE keyword,
>> but also all other timestamps in the document.
>>
>> Having org-display-custom-times turned on all the time also puts
>> overlays on the timestamps in your buffer, but if this annoys you you
>> can bind it to be set during export only.
>
> OK.  I don't know this functionality.  It sounds less bad that what I
> feared, but still the org-export-· variables should probably be
> sufficient.
>
> Is `org-time-stamp-custom-formats' the recommend way of formatting
> regular time stamps for export?

I don't know about "recommended". It doesn't seem to be documented for
export at all. And as for ODT, the code comments say the feature
translating from custom time stamp formats to ODT date styles is
"experimental". Seems to work OK, though.

>> But doing it this way still ignores
>> org-export-date-timestamp-format, and any solution based on copying that
>> variable into org-time-stamp-custom-formats makes unsafe assumptions about
>> user preferences.
>
> Yes.
>
>> It seems to me that the export of the DATE keyword ought to honor a
>> non-nil org-export-date-timestamp-format, whether or not the user is
>> applying custom formatting to other timestamps. 
>> But that would take some
>> changes to several parts of ox-odt.el, I think.
>
> Yeah.  It's can be made even more complicated than that, since the
> *document language* of the output also affects how dates are
> formatted. . .

In Org, or in LibreOffice once you set the language there? If the
#+LANGUAGE keyword is supposed to affect date formatting in Org output,
I must be missing a trick.

> So a two step method would be: (0) make sure that the document
> language is set correctly (similar to how the right babel language is
> selected in LaTeX), and (1) be able to change the format of the date.
>
> Or we could lose the date-stamp-feature and insert the date as
> plaintext.  This is probably simpler, but I don't know if this is the
> "correct" way.

>> Rasmus, will you be pursuing this?
>
> If you are thinking about fixing this, I won't stop you!  I dread
> ·xml.  This weekend sort of disappeared in (other kinds of) wasted
> efforts, so I haven't progressed on this.

Not anytime soon, I'm afraid; pressed for time.

Yours,
Christian




reply via email to

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