Hello,
Bastien b...@altern.org writes:
Though, I think I have to withdraw my proposal about using #+DATE: value
as a time format string. Indeed, date value, along with any document
property, is parsed, which defeats the purpose of using it as a format
string.
We can still implement a
Nicolas Goaziou n.goaz...@gmail.com writes:
q
Hello,
Bastien b...@altern.org writes:
Though, I think I have to withdraw my proposal about using #+DATE:
value
as a time format string. Indeed, date value, along with any
document
property, is parsed, which defeats the purpose of using it as
Bastien b...@altern.org writes:
I agree they are general and should be move out of org-export.el.
Note that one of my plan for 8.[01] is to put org.el on diet so that
it loads more quickly and for more basic stuff. So maybe there will
be org-plan.el at some point for org-schedule,
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
The attached patch moves them into org.el, with an org-timestamp-
prefix.
Looks, good, please go ahead.
Though, I think I have to withdraw my proposal about using #+DATE: value
as a time format string. Indeed, date value, along with
Hello,
Bastien b...@altern.org writes:
Though it may be the job of back-ends to provide such a variable
variable, whenever it makes sense.
Yes, I think it's the job of backends.
For example, in the `e-latex' back-end, there is
`org-e-latex-date-format'.
Should the value of the variable be
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
For example, in the `e-latex' back-end, there is
`org-e-latex-date-format'.
Should the value of the variable be used as an argument for
`org-export-format-timestamp' if the #+DATE: keyword only contains
a timestamp object, and for
Bastien b...@altern.org writes:
Should the value of the variable be used as an argument for
`org-export-format-timestamp' if the #+DATE: keyword only contains
a timestamp object, and for `format-time-string' otherwise?
Yes, good idea!
Ok.
Before I start coding it, I wonder if functions
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Before I start coding it, I wonder if functions related to timestamp
objects, that is `org-export-timestamp-has-time-p',
`org-export-format-timestamp', `org-export-split-timestamp-range' and
`org-export-translate-timestamp' shouldn't be
Hello,
Bastien b...@altern.org writes:
Rasmus ras...@gmx.us writes:
Would it be desirable if the new exporter took the variable
org-export-date-timestamp-format into consideration when formatting
dates?
I think so. What do you think, Nicolas?
I'm not convinced by this variable.
Hi Nicolas,
thanks for looking into this.
Nicolas Goaziou n.goaz...@gmail.com writes:
I'm not convinced by this variable. Back-ends are usually so much
different that a global variable aiming at formatting a date timestamp
in any of them doesn't sound very useful.
Though it may be the job
Hi Rasmus,
Rasmus ras...@gmx.us writes:
Would it be desirable if the new exporter took the variable
org-export-date-timestamp-format into consideration when formatting
dates?
I think so. What do you think, Nicolas?
--
Bastien
Hi,
Would it be desirable if the new exporter took the variable
org-export-date-timestamp-format into consideration when formatting
dates? Or is there another way of dealing with the formatting of
dates?
┏━━━┫ org-export-date-timestamp-format ~%Y-%m-%d~ ┃
┃ Type: string
┃ Since: Emacs
12 matches
Mail list logo
