* bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
@ 2012-03-19 0:58 Michael Heerdegen
2012-03-21 14:00 ` Bastien
2012-03-21 14:00 ` Bastien
0 siblings, 2 replies; 9+ messages in thread
From: Michael Heerdegen @ 2012-03-19 0:58 UTC (permalink / raw)
To: 11042
Hi,
The org-mode manual under the node "The date/time prompt" tells:
"[...] The function understands English month and weekday abbreviations. If
you want to use unabbreviated names and/or other languages, configure
the variables `parse-time-months' and `parse-time-weekdays'."
It doesn't tell how the user can do that. Even worse,
`parse-time-months' and `parse-time-weekdays' are not defined as user
options and undocumented!
After reading the above section in the org manual, users may replace
the English names with e.g. German ones in their config. Seems this
is not a good idea, as this user question in gnu.emacs.gnus shows:
http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9
BTW1: maybe a better solution would be to define own variables for
this purpose in org, instead of letting users change variables in
parse-time.el.
BTW2: In my version of parse-time.el, the unabbreviated month and
weekdays are already available.
Michael
In GNU Emacs 24.0.94.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)
of 2012-03-12 on zelenka, modified by Debian
(emacs-snapshot package, version 2:20120312-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11104000
Configured using:
`configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu'
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.0.94/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.0.94/site-lisp:/usr/share/emacs/site-lisp'
'--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/'
'--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes'
'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'
'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-19 0:58 bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays Michael Heerdegen
@ 2012-03-21 14:00 ` Bastien
2012-03-21 20:24 ` Michael Heerdegen
2012-03-21 20:24 ` Michael Heerdegen
2012-03-21 14:00 ` Bastien
1 sibling, 2 replies; 9+ messages in thread
From: Bastien @ 2012-03-21 14:00 UTC (permalink / raw)
To: michael_heerdegen; +Cc: 11042
Hi Michael,
Michael Heerdegen <michael_heerdegen@web.de> writes:
> The org-mode manual under the node "The date/time prompt" tells:
>
> "[...] The function understands English month and weekday abbreviations. If
> you want to use unabbreviated names and/or other languages, configure
> the variables `parse-time-months' and `parse-time-weekdays'."
>
> It doesn't tell how the user can do that. Even worse,
> `parse-time-months' and `parse-time-weekdays' are not defined as user
> options and undocumented!
>
> After reading the above section in the org manual, users may replace
> the English names with e.g. German ones in their config. Seems this
> is not a good idea, as this user question in gnu.emacs.gnus shows:
>
> http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9
The thread doesn't tell what is wrong with setting `parse-time-months'
and `parse-time-weekdays'. Can you expand a bit more on this?
> BTW1: maybe a better solution would be to define own variables for
> this purpose in org, instead of letting users change variables in
> parse-time.el.
Org heavily depends on parse-time.el. Providing a defcustom in Org
that is tied to parse-time.el at the same time is not trivial.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-19 0:58 bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays Michael Heerdegen
2012-03-21 14:00 ` Bastien
@ 2012-03-21 14:00 ` Bastien
1 sibling, 0 replies; 9+ messages in thread
From: Bastien @ 2012-03-21 14:00 UTC (permalink / raw)
To: michael_heerdegen; +Cc: 11042
Hi Michael,
Michael Heerdegen <michael_heerdegen@web.de> writes:
> The org-mode manual under the node "The date/time prompt" tells:
>
> "[...] The function understands English month and weekday abbreviations. If
> you want to use unabbreviated names and/or other languages, configure
> the variables `parse-time-months' and `parse-time-weekdays'."
>
> It doesn't tell how the user can do that. Even worse,
> `parse-time-months' and `parse-time-weekdays' are not defined as user
> options and undocumented!
>
> After reading the above section in the org manual, users may replace
> the English names with e.g. German ones in their config. Seems this
> is not a good idea, as this user question in gnu.emacs.gnus shows:
>
> http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9
The thread doesn't tell what is wrong with setting `parse-time-months'
and `parse-time-weekdays'. Can you expand a bit more on this?
> BTW1: maybe a better solution would be to define own variables for
> this purpose in org, instead of letting users change variables in
> parse-time.el.
Org heavily depends on parse-time.el. Providing a defcustom in Org
that is tied to parse-time.el at the same time is not trivial.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 14:00 ` Bastien
2012-03-21 20:24 ` Michael Heerdegen
@ 2012-03-21 20:24 ` Michael Heerdegen
2012-03-23 21:46 ` bug#11042: " Bastien
` (3 more replies)
1 sibling, 4 replies; 9+ messages in thread
From: Michael Heerdegen @ 2012-03-21 20:24 UTC (permalink / raw)
To: 11042
Bastien <bzg@altern.org> writes:
> Hi Michael,
>
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > The org-mode manual under the node "The date/time prompt" tells:
> >
> > "[...] The function understands English month and weekday
> > abbreviations. If
> > you want to use unabbreviated names and/or other languages, configure
> > the variables `parse-time-months' and `parse-time-weekdays'."
> >
> > It doesn't tell how the user can do that. Even worse,
> > `parse-time-months' and `parse-time-weekdays' are not defined as user
> > options and undocumented!
> >
> > After reading the above section in the org manual, users may replace
> > the English names with e.g. German ones in their config. Seems this
> > is not a good idea, as this user question in gnu.emacs.gnus shows:
> >
> > http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9
>
> The thread doesn't tell what is wrong with setting `parse-time-months'
> and `parse-time-weekdays'. Can you expand a bit more on this?
The thread is not completely visible in google groups, dunno why.
Please read at gnu.emacs.gnus with a newsreader.
The problem was that the user replaced the English names with German
names - instead of adding them to the lists. This broke Gnus.
Currently, `parse-time-months' and `parse-time-weekdays' are internal
variables with no docstring. Seems they are not intended to be changed
by the user. Other packages may rely on the fact that the default
values aren't changed.
If they are supposed to be configured by the user, they should get a
documented defcustom.
At least, the documentation in the org manual _must_ be improved, so
that the user is enabled to do the right thing without breaking anything
else.
> > BTW1: maybe a better solution would be to define own variables for
> > this purpose in org, instead of letting users change variables in
> > parse-time.el.
>
> Org heavily depends on parse-time.el. Providing a defcustom in Org
> that is tied to parse-time.el at the same time is not trivial.
Why not? You could just write a function `org-parse-time-string' that
binds `parse-time-months' and `parse-time-weekdays' accordingly and
calls `parse-time-string'. Then you would just need to call this new
function from org code.
Regards,
Michael.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 14:00 ` Bastien
@ 2012-03-21 20:24 ` Michael Heerdegen
2012-03-21 20:24 ` Michael Heerdegen
1 sibling, 0 replies; 9+ messages in thread
From: Michael Heerdegen @ 2012-03-21 20:24 UTC (permalink / raw)
To: 11042
Bastien <bzg@altern.org> writes:
> Hi Michael,
>
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > The org-mode manual under the node "The date/time prompt" tells:
> >
> > "[...] The function understands English month and weekday
> > abbreviations. If
> > you want to use unabbreviated names and/or other languages, configure
> > the variables `parse-time-months' and `parse-time-weekdays'."
> >
> > It doesn't tell how the user can do that. Even worse,
> > `parse-time-months' and `parse-time-weekdays' are not defined as user
> > options and undocumented!
> >
> > After reading the above section in the org manual, users may replace
> > the English names with e.g. German ones in their config. Seems this
> > is not a good idea, as this user question in gnu.emacs.gnus shows:
> >
> > http://groups.google.com/group/gnu.emacs.gnus/browse_thread/thread/8dde85b5ff3ab454/a02ddb878bfa1eb9
>
> The thread doesn't tell what is wrong with setting `parse-time-months'
> and `parse-time-weekdays'. Can you expand a bit more on this?
The thread is not completely visible in google groups, dunno why.
Please read at gnu.emacs.gnus with a newsreader.
The problem was that the user replaced the English names with German
names - instead of adding them to the lists. This broke Gnus.
Currently, `parse-time-months' and `parse-time-weekdays' are internal
variables with no docstring. Seems they are not intended to be changed
by the user. Other packages may rely on the fact that the default
values aren't changed.
If they are supposed to be configured by the user, they should get a
documented defcustom.
At least, the documentation in the org manual _must_ be improved, so
that the user is enabled to do the right thing without breaking anything
else.
> > BTW1: maybe a better solution would be to define own variables for
> > this purpose in org, instead of letting users change variables in
> > parse-time.el.
>
> Org heavily depends on parse-time.el. Providing a defcustom in Org
> that is tied to parse-time.el at the same time is not trivial.
Why not? You could just write a function `org-parse-time-string' that
binds `parse-time-months' and `parse-time-weekdays' accordingly and
calls `parse-time-string'. Then you would just need to call this new
function from org code.
Regards,
Michael.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: [O] bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 20:24 ` Michael Heerdegen
2012-03-23 21:46 ` bug#11042: " Bastien
@ 2012-03-23 21:46 ` Bastien
2012-03-23 22:27 ` bug#11042: " Bastien
2012-03-23 22:27 ` bug#11042: [O] " Bastien
3 siblings, 0 replies; 9+ messages in thread
From: Bastien @ 2012-03-23 21:46 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 11042
Hi Michael,
I removed the part of `org-read-date' docstring about
`parse-time-weekdays' and `parse-time-months'. You're right
that this can lead too errors.
Michael Heerdegen <michael_heerdegen@web.de> writes:
> The thread is not completely visible in google groups, dunno why.
> Please read at gnu.emacs.gnus with a newsreader.
Done.
> The problem was that the user replaced the English names with German
> names - instead of adding them to the lists. This broke Gnus.
Chances are that this will break Org too.
> At least, the documentation in the org manual _must_ be improved, so
> that the user is enabled to do the right thing without breaking anything
> else.
Done.
>> Org heavily depends on parse-time.el. Providing a defcustom in Org
>> that is tied to parse-time.el at the same time is not trivial.
>
> Why not? You could just write a function `org-parse-time-string' that
> binds `parse-time-months' and `parse-time-weekdays' accordingly and
> calls `parse-time-string'. Then you would just need to call this new
> function from org code.
Actually, there is already `org-parse-time-string', which does not rely
on `parse-time-string' at all. Org relies on `parse-time-string'
through `org-read-date', a core command of Org.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 20:24 ` Michael Heerdegen
@ 2012-03-23 21:46 ` Bastien
2012-03-23 21:46 ` bug#11042: [O] " Bastien
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Bastien @ 2012-03-23 21:46 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 11042
Hi Michael,
I removed the part of `org-read-date' docstring about
`parse-time-weekdays' and `parse-time-months'. You're right
that this can lead too errors.
Michael Heerdegen <michael_heerdegen@web.de> writes:
> The thread is not completely visible in google groups, dunno why.
> Please read at gnu.emacs.gnus with a newsreader.
Done.
> The problem was that the user replaced the English names with German
> names - instead of adding them to the lists. This broke Gnus.
Chances are that this will break Org too.
> At least, the documentation in the org manual _must_ be improved, so
> that the user is enabled to do the right thing without breaking anything
> else.
Done.
>> Org heavily depends on parse-time.el. Providing a defcustom in Org
>> that is tied to parse-time.el at the same time is not trivial.
>
> Why not? You could just write a function `org-parse-time-string' that
> binds `parse-time-months' and `parse-time-weekdays' accordingly and
> calls `parse-time-string'. Then you would just need to call this new
> function from org code.
Actually, there is already `org-parse-time-string', which does not rely
on `parse-time-string' at all. Org relies on `parse-time-string'
through `org-read-date', a core command of Org.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: [O] bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 20:24 ` Michael Heerdegen
` (2 preceding siblings ...)
2012-03-23 22:27 ` bug#11042: " Bastien
@ 2012-03-23 22:27 ` Bastien
3 siblings, 0 replies; 9+ messages in thread
From: Bastien @ 2012-03-23 22:27 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 11042-done
Closing this bug.
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#11042: bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays
2012-03-21 20:24 ` Michael Heerdegen
2012-03-23 21:46 ` bug#11042: " Bastien
2012-03-23 21:46 ` bug#11042: [O] " Bastien
@ 2012-03-23 22:27 ` Bastien
2012-03-23 22:27 ` bug#11042: [O] " Bastien
3 siblings, 0 replies; 9+ messages in thread
From: Bastien @ 2012-03-23 22:27 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 11042-done
Closing this bug.
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-03-23 22:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-19 0:58 bug#11042: 24.0.94; dangerous org manual: parse-time-months and parse-time-weekdays Michael Heerdegen
2012-03-21 14:00 ` Bastien
2012-03-21 20:24 ` Michael Heerdegen
2012-03-21 20:24 ` Michael Heerdegen
2012-03-23 21:46 ` bug#11042: " Bastien
2012-03-23 21:46 ` bug#11042: [O] " Bastien
2012-03-23 22:27 ` bug#11042: " Bastien
2012-03-23 22:27 ` bug#11042: [O] " Bastien
2012-03-21 14:00 ` Bastien
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.