* [RFC] Change some defcustoms into defcont
@ 2013-10-20 8:47 Nicolas Goaziou
2013-10-20 18:23 ` Carsten Dominik
2013-10-21 8:17 ` Sebastien Vauban
0 siblings, 2 replies; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-20 8:47 UTC (permalink / raw)
To: Org Mode List
Hello,
I'd like to suggest changing the following defcustom variables into
defconst:
- org-deadline-string
- org-scheduled-string
- org-closed-string
- org-clock-string
- org-comment-string
- org-quote-string
- org-effort-property
- org-archive-tag
There's no fundamental reason to change these, as they belong to Org
syntax, much like star character for headlines and ":END:" closing
string for drawers.
They can also introduce bugs in code when modified (e.g. modifying
`org-effort-property' breaks `ox-taskjuggler'). Of course, this can be
avoided with careful checks, but this puts an extra burden on developers
for a tiny benefit for the user.
Eventually, they can be costly, since changing any of them implies that
cache in every Org buffer must be erased.
Allowing customization is generally good, but I think Org syntax should
never be a moving target.
Note that this shouldn't introduce much backward incompatibility (unless
user changes them through customize interface) since a defconst can
still be setq'ed and variables will still be used in code base.
Opinions?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-20 8:47 [RFC] Change some defcustoms into defcont Nicolas Goaziou
@ 2013-10-20 18:23 ` Carsten Dominik
2013-10-21 8:56 ` Nicolas Goaziou
2013-10-21 8:17 ` Sebastien Vauban
1 sibling, 1 reply; 19+ messages in thread
From: Carsten Dominik @ 2013-10-20 18:23 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Hi Nicolas,
I think this change breaks user setups. I don't know how many
people do change these keywords, but I know some do, if
only for localization purposes. I myself have modified the
archive keyword in some cases, if I use this feature for a
different purpose.
You probably want to do this to make Org syntax less fragile. A good
goal. However, I think it can also be achieved by leaving these
as defcustom and discouraging changes in the docstring with a
standard sentence about about deprecation.
Your most important argument to me seems about efficiency of cashing.
We can fix this by providing :set methods for the customize entries
that will trigger global cache erasing, so that you do not need to
programmatically check this all the time.
Regards
- Carsten
On 20.10.2013, at 10:47, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> I'd like to suggest changing the following defcustom variables into
> defconst:
>
> - org-deadline-string
> - org-scheduled-string
> - org-closed-string
> - org-clock-string
> - org-comment-string
> - org-quote-string
> - org-effort-property
> - org-archive-tag
>
> There's no fundamental reason to change these, as they belong to Org
> syntax, much like star character for headlines and ":END:" closing
> string for drawers.
>
> They can also introduce bugs in code when modified (e.g. modifying
> `org-effort-property' breaks `ox-taskjuggler'). Of course, this can be
> avoided with careful checks, but this puts an extra burden on developers
> for a tiny benefit for the user.
>
> Eventually, they can be costly, since changing any of them implies that
> cache in every Org buffer must be erased.
>
> Allowing customization is generally good, but I think Org syntax should
> never be a moving target.
>
> Note that this shouldn't introduce much backward incompatibility (unless
> user changes them through customize interface) since a defconst can
> still be setq'ed and variables will still be used in code base.
>
> Opinions?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-20 8:47 [RFC] Change some defcustoms into defcont Nicolas Goaziou
2013-10-20 18:23 ` Carsten Dominik
@ 2013-10-21 8:17 ` Sebastien Vauban
1 sibling, 0 replies; 19+ messages in thread
From: Sebastien Vauban @ 2013-10-21 8:17 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hello Nicolas,
Nicolas Goaziou wrote:
> I'd like to suggest changing the following defcustom variables into
> defconst:
>
> - org-deadline-string
> - org-scheduled-string
> - org-closed-string
> - org-clock-string
> - org-comment-string
> - org-quote-string
> - org-effort-property
> - org-archive-tag
At first, I thought: "I certainly have changed at least one of them" (such
`org-log-note-headings' for which I changed the `state' string to "State %-12S
-> %-12s %t" -- as I prefer the FROM -> TO presentation of state changes).
Though, FWIW, no, these are still the original values in my case as well.
> There's no fundamental reason to change these, as they belong to Org
> syntax, much like star character for headlines and ":END:" closing
> string for drawers.
>
> They can also introduce bugs in code when modified (e.g. modifying
> `org-effort-property' breaks `ox-taskjuggler'). Of course, this can be
> avoided with careful checks, but this puts an extra burden on developers
> for a tiny benefit for the user.
>
> Eventually, they can be costly, since changing any of them implies that
> cache in every Org buffer must be erased.
>
> Allowing customization is generally good, but I think Org syntax should
> never be a moving target.
>
> Note that this shouldn't introduce much backward incompatibility (unless
> user changes them through customize interface) since a defconst can
> still be setq'ed and variables will still be used in code base.
I thought that users never ever could change constants. But the docstring of
`defconst' indeed tells that "this constancy is not actually enforced by Emacs
Lisp". Though, can we be sure that this will stay true?
> Opinions?
OK for me.
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-20 18:23 ` Carsten Dominik
@ 2013-10-21 8:56 ` Nicolas Goaziou
2013-10-21 10:26 ` Carsten Dominik
0 siblings, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-21 8:56 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Hello,
Carsten Dominik <carsten.dominik@gmail.com> writes:
> I think this change breaks user setups. I don't know how many
> people do change these keywords, but I know some do, if
> only for localization purposes. I myself have modified the
> archive keyword in some cases, if I use this feature for a
> different purpose.
I don't think it breaks their setup, since you can do:
(setq org-deadline-string "SOMETHING:")
Of course, if they change it with `custom-set-variables', they will have
to change it.
> You probably want to do this to make Org syntax less fragile.
Correct.
> However, I think it can also be achieved by leaving these as defcustom
> and discouraging changes in the docstring with a standard sentence
> about about deprecation.
That's exactly the point of the defconst: you can still modify the
variable, but it sends a strong message to the user. Also, it's not
about deprecation: code base should still rely on these variables.
> Your most important argument to me seems about efficiency of cashing.
> We can fix this by providing :set methods for the customize entries
> that will trigger global cache erasing, so that you do not need to
> programmatically check this all the time.
I know, and I still have to do it for variables like
`org-todo-keywords', which are meant to be modified.
My main concern is about core Org syntax.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-21 8:56 ` Nicolas Goaziou
@ 2013-10-21 10:26 ` Carsten Dominik
2013-10-21 10:51 ` Nicolas Goaziou
0 siblings, 1 reply; 19+ messages in thread
From: Carsten Dominik @ 2013-10-21 10:26 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
On 21.10.2013, at 10:56, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> I think this change breaks user setups. I don't know how many
>> people do change these keywords, but I know some do, if
>> only for localization purposes. I myself have modified the
>> archive keyword in some cases, if I use this feature for a
>> different purpose.
>
> I don't think it breaks their setup, since you can do:
>
> (setq org-deadline-string "SOMETHING:")
Yes. But in particular the less well versed users will likely
have used customize.
>
> Of course, if they change it with `custom-set-variables', they will have
> to change it.
>
>> You probably want to do this to make Org syntax less fragile.
>
> Correct.
>
>> However, I think it can also be achieved by leaving these as defcustom
>> and discouraging changes in the docstring with a standard sentence
>> about about deprecation.
>
> That's exactly the point of the defconst: you can still modify the
> variable, but it sends a strong message to the user. Also, it's not
> about deprecation: code base should still rely on these variables.
This is where I disagree. I think the Emacs implementation of defconst
is broken, and retained in this way only for backward compatibility.
If we still allow users to edit this in principle, I do not think we
should make these variables defconst. If editing is not
even depreciated, there is even less reason to make this change.
How about we add a sentence like this:
Changing this variable may cause compatibility problems with other users
trying to edit your file in Emacs.
>
>> Your most important argument to me seems about efficiency of cashing.
>> We can fix this by providing :set methods for the customize entries
>> that will trigger global cache erasing, so that you do not need to
>> programmatically check this all the time.
>
> I know, and I still have to do it for variables like
> `org-todo-keywords', which are meant to be modified.
>
> My main concern is about core Org syntax.
- Carsten
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-21 10:26 ` Carsten Dominik
@ 2013-10-21 10:51 ` Nicolas Goaziou
2013-10-21 11:56 ` Carsten Dominik
0 siblings, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-21 10:51 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On 21.10.2013, at 10:56, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> That's exactly the point of the defconst: you can still modify the
>> variable, but it sends a strong message to the user. Also, it's not
>> about deprecation: code base should still rely on these variables.
>
> This is where I disagree. I think the Emacs implementation of defconst
> is broken, and retained in this way only for backward compatibility.
I won't judge Elisp implementation. AFAIC, defining a variable as
a defconst means : "change it at your own risk", which is exactly my
point.
Anyway, FWIW, even a defvar would suffice.
> If we still allow users to edit this in principle,
We have no way to prevent them from modifying it. In principle, they
mustn't be changed, but it's Free software.
> I do not think we should make these variables defconst. If editing is
> not even depreciated, there is even less reason to make this change.
> How about we add a sentence like this:
>
> Changing this variable may cause compatibility problems with other users
> trying to edit your file in Emacs.
It's not only about compatibility problems. As I pointed out, modifying
these variable can break your own Org.
Using a defcustom is ambiguous here. On the one hand, we say "You can
modify this variable, we even help you to do so" and on the other hand
"Upon changing this variable, horrible things can happen".
Let's, at least, not help users shoot themselves in the foot.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-21 10:51 ` Nicolas Goaziou
@ 2013-10-21 11:56 ` Carsten Dominik
2013-10-21 15:15 ` Nicolas Goaziou
0 siblings, 1 reply; 19+ messages in thread
From: Carsten Dominik @ 2013-10-21 11:56 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Hi Nicolas,
On 21.10.2013, at 12:51, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On 21.10.2013, at 10:56, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>>> That's exactly the point of the defconst: you can still modify the
>>> variable, but it sends a strong message to the user. Also, it's not
>>> about deprecation: code base should still rely on these variables.
>>
>> This is where I disagree. I think the Emacs implementation of defconst
>> is broken, and retained in this way only for backward compatibility.
>
> I won't judge Elisp implementation. AFAIC, defining a variable as
> a defconst means : "change it at your own risk", which is exactly my
> point.
The documentation of defconst says:
> Define SYMBOL as a constant variable.
> This declares that neither programs nor users should ever change the
> value. This constancy is not actually enforced by Emacs Lisp, but
> SYMBOL is marked as a special variable so that it is never lexically
> bound.
So it is pretty clear about the intent of such a definition, which is
to never change it - even though it does not enforce it.
As you have said, we still want to allow users in principle to change
these variables. They have been defcustoms in the past, some people will
have changed them. Their setup will break when they switch to a new
version. That is why I object to changing their status. I think it
causes unnecessary breakage, and we can prevent this by keeping them
defcustom. Nothing is really gained by changing their status.
- Carsten
>
> Anyway, FWIW, even a defvar would suffice.
>
>> If we still allow users to edit this in principle,
>
> We have no way to prevent them from modifying it. In principle, they
> mustn't be changed, but it's Free software.
>
>> I do not think we should make these variables defconst. If editing is
>> not even depreciated, there is even less reason to make this change.
>> How about we add a sentence like this:
>>
>> Changing this variable may cause compatibility problems with other users
>> trying to edit your file in Emacs.
>
> It's not only about compatibility problems. As I pointed out, modifying
> these variable can break your own Org.
>
> Using a defcustom is ambiguous here. On the one hand, we say "You can
> modify this variable, we even help you to do so" and on the other hand
> "Upon changing this variable, horrible things can happen".
>
> Let's, at least, not help users shoot themselves in the foot.
>
>
> Regards,
>
> --
> Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-21 11:56 ` Carsten Dominik
@ 2013-10-21 15:15 ` Nicolas Goaziou
2013-10-22 7:50 ` Carsten Dominik
0 siblings, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-21 15:15 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Carsten Dominik <carsten.dominik@gmail.com> writes:
> The documentation of defconst says:
>
>> Define SYMBOL as a constant variable.
>> This declares that neither programs nor users should ever change the
>> value. This constancy is not actually enforced by Emacs Lisp, but
>> SYMBOL is marked as a special variable so that it is never lexically
>> bound.
>
> So it is pretty clear about the intent of such a definition, which is
> to never change it - even though it does not enforce it.
I must have been clear as mud, because that's exactly what I'm
suggesting since the beginning of this thread: set "DEADLINE" and al. in
stone, and never change them again.
I have been pointing out, though, that it would not break previous
changes if they were done with `setq', according to how defconst are
handled. But I never intended to make it a feature, nor did I suggest
that was desirable.
> As you have said, we still want to allow users in principle to change
> these variables.
No, I haven't said such a thing. I said, verbatim, "In principle, they
mustn't be changed", which means quite the contrary.
> They have been defcustoms in the past, some people will have changed
> them. Their setup will break when they switch to a new version.
Indeed. But that's easy to fix programmatically.
> That is why I object to changing their status. I think it causes
> unnecessary breakage, and we can prevent this by keeping them
> defcustom. Nothing is really gained by changing their status.
It fixes at least a bug, prevents headaches by simplifying maintenance,
makes Org syntax more portable and more cache friendly. I wouldn't call
that "nothing".
Anyway, I have well understood that you don't want to change their
status. So be it.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-21 15:15 ` Nicolas Goaziou
@ 2013-10-22 7:50 ` Carsten Dominik
2013-10-22 9:52 ` Nicolas Goaziou
0 siblings, 1 reply; 19+ messages in thread
From: Carsten Dominik @ 2013-10-22 7:50 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Dear Nicolas,
On Oct 21, 2013, at 5:15 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> The documentation of defconst says:
>>
>>> Define SYMBOL as a constant variable.
>>> This declares that neither programs nor users should ever change the
>>> value. This constancy is not actually enforced by Emacs Lisp, but
>>> SYMBOL is marked as a special variable so that it is never lexically
>>> bound.
>>
>> So it is pretty clear about the intent of such a definition, which is
>> to never change it - even though it does not enforce it.
>
> I must have been clear as mud, because that's exactly what I'm
> suggesting since the beginning of this thread: set "DEADLINE" and al. in
> stone, and never change them again.
You also said things like
> That's exactly the point of the defconst: you can still modify the
> variable, but it sends a strong message to the user. Also, it's not
> about deprecation: code base should still rely on these variables.
so maybe I picked one interpretation over the other.
>
> I have been pointing out, though, that it would not break previous
> changes if they were done with `setq', according to how defconst are
> handled. But I never intended to make it a feature, nor did I suggest
> that was desirable.
>
>> As you have said, we still want to allow users in principle to change
>> these variables.
>
> No, I haven't said such a thing. I said, verbatim, "In principle, they
> mustn't be changed", which means quite the contrary.
>
>> They have been defcustoms in the past, some people will have changed
>> them. Their setup will break when they switch to a new version.
>
> Indeed. But that's easy to fix programmatically.
>
>> That is why I object to changing their status. I think it causes
>> unnecessary breakage, and we can prevent this by keeping them
>> defcustom. Nothing is really gained by changing their status.
>
> It fixes at least a bug, prevents headaches by simplifying maintenance,
> makes Org syntax more portable and more cache friendly. I wouldn't call
> that "nothing".
Yes, sorry. By "nothing" I mean nothing we cannot achieve with documentation
and a :set method. Since we will still rely on the variables, the advantage for
maintenance is something I do not see. Cache friendliness I see, but I would think
that if someone changes these variables, they will not keep changing them.
>
> Anyway, I have well understood that you don't want to change their
> status. So be it.
OK, thank you.
Regards
- Carsten
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-22 7:50 ` Carsten Dominik
@ 2013-10-22 9:52 ` Nicolas Goaziou
2013-10-22 10:34 ` Carsten Dominik
0 siblings, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-22 9:52 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Hello,
> You also said things like
>
>> That's exactly the point of the defconst: you can still modify the
>> variable, but it sends a strong message to the user. Also, it's not
>> about deprecation: code base should still rely on these variables.
>
> so maybe I picked one interpretation over the other.
I don't see any contradiction. You can modify a defconst, but the strong
message is "you are not supposed to do that". I didn't suggest modifying
these variables was expected. Anyway, I acknowledge I wasn't very clear.
> Yes, sorry. By "nothing" I mean nothing we cannot achieve with
> documentation and a :set method.
This will not fix the bug.
> Since we will still rely on the variables, the advantage for
> maintenance is something I do not see.
As a developer, you have to keep in mind that the string might be
changed. Sometimes, it's easy to forget you cannot hardcode it, e.g.
when writing a search regexp. I have done a similar mistake in
ox-taskjuggler.el, where I expect the effort property to be named
":EFFORT:". More things to remember, more potential bugs, more
maintenance efforts.
> Cache friendliness I see, but I would think that if someone changes
> these variables, they will not keep changing them.
Of course. I shouldn't have talked about cache since it makes me sound
like a lazy person. I can work around the cache problem.
Again my main concern was to move to a proper, Emacs-independent,
/minimal/ core syntax, i.e., to define the "Org format". For example, at
the moment, external tools cannot rely on "SCHEDULED:" string to write
even a basic Org file, because "SCHEDULED:" doesn't clearly belong to
the syntax and, therefore, might be incompatible with some
configurations.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-22 9:52 ` Nicolas Goaziou
@ 2013-10-22 10:34 ` Carsten Dominik
2013-10-22 18:28 ` Torsten Wagner
2013-10-23 8:56 ` Nicolas Goaziou
0 siblings, 2 replies; 19+ messages in thread
From: Carsten Dominik @ 2013-10-22 10:34 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List, Carsten Dominik
On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
>> You also said things like
>>
>>> That's exactly the point of the defconst: you can still modify the
>>> variable, but it sends a strong message to the user. Also, it's not
>>> about deprecation: code base should still rely on these variables.
>>
>> so maybe I picked one interpretation over the other.
>
> I don't see any contradiction. You can modify a defconst, but the strong
> message is "you are not supposed to do that". I didn't suggest modifying
> these variables was expected. Anyway, I acknowledge I wasn't very clear.
>
>> Yes, sorry. By "nothing" I mean nothing we cannot achieve with
>> documentation and a :set method.
>
> This will not fix the bug.
Hi Nicolas,
can you remind me what the bug was? The taskjuggler issue?
>
>> Since we will still rely on the variables, the advantage for
>> maintenance is something I do not see.
>
> As a developer, you have to keep in mind that the string might be
> changed. Sometimes, it's easy to forget you cannot hardcode it, e.g.
> when writing a search regexp. I have done a similar mistake in
> ox-taskjuggler.el, where I expect the effort property to be named
> ":EFFORT:". More things to remember, more potential bugs, more
> maintenance efforts.
>
>> Cache friendliness I see, but I would think that if someone changes
>> these variables, they will not keep changing them.
>
> Of course. I shouldn't have talked about cache since it makes me sound
> like a lazy person. I can work around the cache problem.
>
> Again my main concern was to move to a proper, Emacs-independent,
> /minimal/ core syntax, i.e., to define the "Org format". For example, at
> the moment, external tools cannot rely on "SCHEDULED:" string to write
> even a basic Org file, because "SCHEDULED:" doesn't clearly belong to
> the syntax and, therefore, might be incompatible with some
> configurations.
Yes, as I said, I do see all these problems, but I also feel the responsibility
to break as few as possible existing configurations.
If you want, I can take a shot at documenting this properly.
- Carsten
>
>
> Regards,
>
> --
> Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-22 10:34 ` Carsten Dominik
@ 2013-10-22 18:28 ` Torsten Wagner
2013-10-22 20:00 ` Florian Beck
2013-10-23 8:56 ` Nicolas Goaziou
1 sibling, 1 reply; 19+ messages in thread
From: Torsten Wagner @ 2013-10-22 18:28 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List, Nicolas Goaziou
Hi,
not being a dev and really not being a lisp programmer, I still can
see Nicolas attempt to unify the syntax in a way "all and
everyone/everything" can rely on it. The question would be what would
be more troublesome? Dealing in future with people who by chance
changed some of those variables and who suddenly face problems using
third party (internal as well as external) tools. E.g., tools like
org-ruby came to my mind. More and more projects start to include
org-syntax too. For all those it would become difficult to rely on
certain keywords.
Or is it more problematic that those who changed variables already,
might find there system broken / in need of manual adoption after an
update?
Anyhow, I just had this idea that org-mode could rely on a fixed (as
written in stone) set of keywords and that an a new exporter backend
will be introduced which simply creates a standard-conform org-mode
file. Let's call it ox-legacy ;) Those created files could be send to
others to work on it or could be used in conjunction with 3rd party
programs.
By time, one could think of a org-mode import, which again takes a
standard conform org-mode file and translates it back into the
individual settings of a specific user.
Having an legacy org-mode exporter and importer, could even allow to
customize org-mode for different languages, e.g. one could set (setq
org-mode-language "german") to get a set of keywords in German.
Exporting it into legacy org-mode would translate it back into e.g.
English, which then again could be read-in by a user who set (setq
org-mode-language "japanese") and who would be able to read the file
with a set of Japanese keywords.
Just an idea I had following this thread.
All the best
Torsten
On 22 October 2013 12:34, Carsten Dominik <drostekirsten@gmail.com> wrote:
>
> On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>> Hello,
>>
>>> You also said things like
>>>
>>>> That's exactly the point of the defconst: you can still modify the
>>>> variable, but it sends a strong message to the user. Also, it's not
>>>> about deprecation: code base should still rely on these variables.
>>>
>>> so maybe I picked one interpretation over the other.
>>
>> I don't see any contradiction. You can modify a defconst, but the strong
>> message is "you are not supposed to do that". I didn't suggest modifying
>> these variables was expected. Anyway, I acknowledge I wasn't very clear.
>>
>>> Yes, sorry. By "nothing" I mean nothing we cannot achieve with
>>> documentation and a :set method.
>>
>> This will not fix the bug.
>
> Hi Nicolas,
>
> can you remind me what the bug was? The taskjuggler issue?
>
>
>>
>>> Since we will still rely on the variables, the advantage for
>>> maintenance is something I do not see.
>>
>> As a developer, you have to keep in mind that the string might be
>> changed. Sometimes, it's easy to forget you cannot hardcode it, e.g.
>> when writing a search regexp. I have done a similar mistake in
>> ox-taskjuggler.el, where I expect the effort property to be named
>> ":EFFORT:". More things to remember, more potential bugs, more
>> maintenance efforts.
>>
>>> Cache friendliness I see, but I would think that if someone changes
>>> these variables, they will not keep changing them.
>>
>> Of course. I shouldn't have talked about cache since it makes me sound
>> like a lazy person. I can work around the cache problem.
>>
>> Again my main concern was to move to a proper, Emacs-independent,
>> /minimal/ core syntax, i.e., to define the "Org format". For example, at
>> the moment, external tools cannot rely on "SCHEDULED:" string to write
>> even a basic Org file, because "SCHEDULED:" doesn't clearly belong to
>> the syntax and, therefore, might be incompatible with some
>> configurations.
>
> Yes, as I said, I do see all these problems, but I also feel the responsibility
> to break as few as possible existing configurations.
>
> If you want, I can take a shot at documenting this properly.
>
> - Carsten
>
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-22 18:28 ` Torsten Wagner
@ 2013-10-22 20:00 ` Florian Beck
0 siblings, 0 replies; 19+ messages in thread
From: Florian Beck @ 2013-10-22 20:00 UTC (permalink / raw)
To: Torsten Wagner; +Cc: Nicolas Goaziou, Org Mode List, Carsten Dominik
Torsten Wagner <torsten.wagner@gmail.com> writes:
> Anyhow, I just had this idea that org-mode could rely on a fixed (as
> written in stone) set of keywords and that an a new exporter backend
> will be introduced which simply creates a standard-conform org-mode
> file.
Well, I like the idea of an importer. Not so much because of keywords,
but because org should work on text files and text files often work with
different conventions (I still have muse files around and old org files
where I used *this* for emphasis.)
> By time, one could think of a org-mode import, which again takes a
> standard conform org-mode file and translates it back into the
> individual settings of a specific user.
This I would call export.
> Having an legacy org-mode exporter and importer, could even allow to
> customize org-mode for different languages, e.g. one could set (setq
> org-mode-language "german") to get a set of keywords in German.
> Exporting it into legacy org-mode would translate it back into e.g.
> English, which then again could be read-in by a user who set (setq
> org-mode-language "japanese") and who would be able to read the file
> with a set of Japanese keywords.
The problem is, the exporter can only be used if org-element can parse
the syntax, which is exactly what Nicolas wants to get rid of.
Org-element clearly isn't intend to be a general parser.
So an importer/preprocessor/old->new converter would have to be either a
simple search and replace mechanism or do all the heavy lifting itself.
Hm, if I'd have, say, an xml of lisp representation of the buffer (i.g.
(ELEMENT (OPTIONS) ((ELEMENT (OPTIONS) ...)))), is there a way to hand
that of to org-element or the exporter?
--
Florian Beck
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-22 10:34 ` Carsten Dominik
2013-10-22 18:28 ` Torsten Wagner
@ 2013-10-23 8:56 ` Nicolas Goaziou
2013-10-23 13:25 ` Carsten Dominik
1 sibling, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-23 8:56 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Hello,
Carsten Dominik <drostekirsten@gmail.com> writes:
> can you remind me what the bug was? The taskjuggler issue?
Correct. I will fix it today.
> Yes, as I said, I do see all these problems, but I also feel the responsibility
> to break as few as possible existing configurations.
I understand. Though, almost any serious change breaks some existing
configuration. It is unfortunate, but I hope it will not prevent us from
correcting past, and future, mistakes. Without that right to be wrong,
we'd better plan Org development a very long time ahead and cross
fingers hoping we will never fail. Don't cross too hard.
> If you want, I can take a shot at documenting this properly.
I'm not convinced by that documentation thing, i.e. "we allow you to
change the string, but we remind you that you shouldn't do it". It even
goes against my initial suggestion, so I cannot say I "want" anything in
that area.
Unless, that is, you're talking about a deprecation warning, e.g. "In
future releases, this variable will not be customizable anymore, so be
careful when changing its default value". But, IIUC, that's not what you
want.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-23 8:56 ` Nicolas Goaziou
@ 2013-10-23 13:25 ` Carsten Dominik
2013-10-29 14:04 ` Nicolas Goaziou
2013-11-16 20:25 ` Nicolas Goaziou
0 siblings, 2 replies; 19+ messages in thread
From: Carsten Dominik @ 2013-10-23 13:25 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Hi Nicolas, and everyone else.
I have just investigated what actually happens is someone has a
customize setting for a variable in his/her setup, and then the variable
is changed to a defconst behind his/her back. The result was very
surprising to me: customize-set-variables still does set the variable
to the stored value. Changing a different customize variable
and selecting "apply and change" updates the init file where
customize-set-variables is stored, and interestingly still preserves
the customize setting for the variable that now has become
a defconst.
This surprised me, and it seems to indicate that existing configurations
would not break.
Furthermore, I have looked at the old customization survey
at http://orgmode.org/worg/org-configs/org-customization-survey.html
It turns out that none of the variables Nicolas listed seems to have been
customized by the people participating in this survey.
Tanking these together, I am now inclined to change my view and
to let Nicolas make his proposed change.
What I would like to request is that we try to make Org still work if these
variables do in fact have a different value - but that is what Nicolas
already said.
So: IF YOU HAVE CUSTOMIZED any of this variables, I'd like to hear about it.
Otherwise, I now think that the proposal is actually good and should move ahead.
- Carsten
On Oct 23, 2013, at 10:56 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> can you remind me what the bug was? The taskjuggler issue?
>
> Correct. I will fix it today.
>
>> Yes, as I said, I do see all these problems, but I also feel the responsibility
>> to break as few as possible existing configurations.
>
> I understand. Though, almost any serious change breaks some existing
> configuration. It is unfortunate, but I hope it will not prevent us from
> correcting past, and future, mistakes. Without that right to be wrong,
> we'd better plan Org development a very long time ahead and cross
> fingers hoping we will never fail. Don't cross too hard.
>
>> If you want, I can take a shot at documenting this properly.
>
> I'm not convinced by that documentation thing, i.e. "we allow you to
> change the string, but we remind you that you shouldn't do it". It even
> goes against my initial suggestion, so I cannot say I "want" anything in
> that area.
>
> Unless, that is, you're talking about a deprecation warning, e.g. "In
> future releases, this variable will not be customizable anymore, so be
> careful when changing its default value". But, IIUC, that's not what you
> want.
>
>
> Regards,
>
> --
> Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-23 13:25 ` Carsten Dominik
@ 2013-10-29 14:04 ` Nicolas Goaziou
2013-10-29 14:11 ` Nicolas Goaziou
2013-11-16 20:25 ` Nicolas Goaziou
1 sibling, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-29 14:04 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Hello,
Carsten Dominik <drostekirsten@gmail.com> writes:
> So: IF YOU HAVE CUSTOMIZED any of this variables, I'd like to hear about it.
> Otherwise, I now think that the proposal is actually good and should
> move ahead.
Here is the suggested patch.
Regards,
--
Nicolas Goaziou
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Change-some-defcustoms-into-defconsts.patch --]
[-- Type: text/x-diff, Size: 17875 bytes --]
From b7bed5ebaf41498a70f8df18a4441d1a0732a737 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Tue, 29 Oct 2013 14:53:21 +0100
Subject: [PATCH] Change some defcustoms into defconsts
* lisp/org.el (org-clock-string, org-closed-string)
(org-deadline-string, org-scheduled-string)
(org-archive-tag, org-comment-string, org-quote-string): Turn
variables into constants.
Also collect all syntax related constants in the same part of the
file.
---
lisp/org.el | 343 +++++++++++++++++++++++++++++++-----------------------------
1 file changed, 176 insertions(+), 167 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f3bf4b..06fceb4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -314,8 +314,181 @@ When MESSAGE is non-nil, display a message with the version."
(defconst org-version (org-version))
-;;; Compatibility constants
+\f
+;;; Syntax Constants
+
+;;;; Blocks
+
+(defconst org-block-regexp
+ "^[ \t]*#\\+begin_?\\([^ \n]+\\)\\(\\([^\n]+\\)\\)?\n\\([^\000]+?\\)#\\+end_?\\1[ \t]*$"
+ "Regular expression for hiding blocks.")
+
+(defconst org-dblock-start-re
+ "^[ \t]*#\\+\\(?:BEGIN\\|begin\\):[ \t]+\\(\\S-+\\)\\([ \t]+\\(.*\\)\\)?"
+ "Matches the start line of a dynamic block, with parameters.")
+
+(defconst org-dblock-end-re "^[ \t]*#\\+\\(?:END\\|end\\)\\([: \t\r\n]\\|$\\)"
+ "Matches the end of a dynamic block.")
+
+;;;; Clock and Planning
+
+(defconst org-clock-string "CLOCK:"
+ "String used as prefix for timestamps clocking work hours on an item.")
+
+(defconst org-closed-string "CLOSED:"
+ "String used as the prefix for timestamps logging closing a TODO entry.")
+
+(defconst org-deadline-string "DEADLINE:"
+ "String to mark deadline entries.
+A deadline is this string, followed by a time stamp. Should be a word,
+terminated by a colon. You can insert a schedule keyword and
+a timestamp with \\[org-deadline].")
+
+(defconst org-scheduled-string "SCHEDULED:"
+ "String to mark scheduled TODO entries.
+A schedule is this string, followed by a time stamp. Should be a word,
+terminated by a colon. You can insert a schedule keyword and
+a timestamp with \\[org-schedule].")
+
+(defconst org-planning-or-clock-line-re
+ (concat "^[ \t]*"
+ (regexp-opt
+ (list org-clock-string org-closed-string org-deadline-string
+ org-scheduled-string)
+ t))
+ "Matches a line with planning or clock info.
+Matched keyword is in group 1.")
+
+;;;; Drawer
+
+(defconst org-property-start-re "^[ \t]*:PROPERTIES:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-property-end-re "^[ \t]*:END:[ \t]*$"
+ "Regular expression matching the last line of a property drawer.")
+
+(defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-clock-drawer-end-re "^[ \t]*:END:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-property-drawer-re
+ (concat "\\(" org-property-start-re "\\)[^\000]*?\\("
+ org-property-end-re "\\)\n?")
+ "Matches an entire property drawer.")
+
+(defconst org-clock-drawer-re
+ (concat "\\(" org-clock-drawer-start-re "\\)[^\000]*?\\("
+ org-property-end-re "\\)\n?")
+ "Matches an entire clock drawer.")
+
+;;;; Headline
+
+(defconst org-heading-keyword-regexp-format
+ "^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
+ "Printf format for a regexp matching a headline with some keyword.
+This regexp will match the headline of any node which has the
+exact keyword that is put into the format. The keyword isn't in
+any group by default, but the stars and the body are.")
+
+(defconst org-heading-keyword-maybe-regexp-format
+ "^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$"
+ "Printf format for a regexp matching a headline, possibly with some keyword.
+This regexp can match any headline with the specified keyword, or
+without a keyword. The keyword isn't in any group by default,
+but the stars and the body are.")
+
+(defconst org-archive-tag "ARCHIVE"
+ "The tag that marks a subtree as archived.
+An archived subtree does not open during visibility cycling, and does
+not contribute to the agenda listings.")
+
+(defconst org-comment-string "COMMENT"
+ "Entries starting with this keyword will never be exported.
+An entry can be toggled between COMMENT and normal with
+\\[org-toggle-comment].")
+
+(defconst org-quote-string "QUOTE"
+ "Entries starting with this keyword will be exported in fixed-width font.
+Quoting applies only to the text in the entry following the headline, and does
+not extend beyond the next headline, even if that is lower level.
+An entry can be toggled between QUOTE and normal with
+\\[org-toggle-fixed-width-section].")
+
+;;;; Table
+
+(defconst org-table-any-line-regexp "^[ \t]*\\(|\\|\\+-[-+]\\)"
+ "Detect an org-type or table-type table.")
+
+(defconst org-table-line-regexp "^[ \t]*|"
+ "Detect an org-type table line.")
+
+(defconst org-table-dataline-regexp "^[ \t]*|[^-]"
+ "Detect an org-type table line.")
+
+(defconst org-table-hline-regexp "^[ \t]*|-"
+ "Detect an org-type table hline.")
+
+(defconst org-table1-hline-regexp "^[ \t]*\\+-[-+]"
+ "Detect a table-type table hline.")
+
+(defconst org-table-any-border-regexp "^[ \t]*[^|+ \t]"
+ "Detect the first line outside a table when searching from within it.
+This works for both table types.")
+
+(defconst org-TBLFM-regexp "^[ \t]*#\\+TBLFM: "
+ "Detect a #+TBLFM line.")
+
+;;;; Timestamp
+
+(defconst org-ts-regexp "<\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^\r\n>]*?\\)>"
+ "Regular expression for fast time stamp matching.")
+
+(defconst org-ts-regexp-both "[[<]\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^]\r\n>]*?\\)[]>]"
+ "Regular expression for fast time stamp matching.")
+
+(defconst org-ts-regexp0
+ "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\)\\( +[^]+0-9>\r\n -]+\\)?\\( +\\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
+ "Regular expression matching time strings for analysis.
+This one does not require the space after the date, so it can be used
+on a string that terminates immediately after the date.")
+
+(defconst org-ts-regexp1 "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\) *\\([^]+0-9>\r\n -]*\\)\\( \\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
+ "Regular expression matching time strings for analysis.")
+
+(defconst org-ts-regexp2 (concat "<" org-ts-regexp1 "[^>\n]\\{0,16\\}>")
+ "Regular expression matching time stamps, with groups.")
+
+(defconst org-ts-regexp3 (concat "[[<]" org-ts-regexp1 "[^]>\n]\\{0,16\\}[]>]")
+ "Regular expression matching time stamps (also [..]), with groups.")
+
+(defconst org-tr-regexp (concat org-ts-regexp "--?-?" org-ts-regexp)
+ "Regular expression matching a time stamp range.")
+
+(defconst org-tr-regexp-both
+ (concat org-ts-regexp-both "--?-?" org-ts-regexp-both)
+ "Regular expression matching a time stamp range.")
+
+(defconst org-tsr-regexp (concat org-ts-regexp "\\(--?-?"
+ org-ts-regexp "\\)?")
+ "Regular expression matching a time stamp or time stamp range.")
+
+(defconst org-tsr-regexp-both
+ (concat org-ts-regexp-both "\\(--?-?"
+ org-ts-regexp-both "\\)?")
+ "Regular expression matching a time stamp or time stamp range.
+The time stamps may be either active or inactive.")
+
+(defconst org-repeat-re
+ "<[0-9]\\{4\\}-[0-9][0-9]-[0-9][0-9] [^>\n]*?\\([.+]?\\+[0-9]+[hdwmy]\\(/[0-9]+[hdwmy]\\)?\\)"
+ "Regular expression for specifying repeated events.
+After a match, group 1 contains the repeat expression.")
+
+(defconst org-time-stamp-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
+ "Formats for `format-time-string' which are used for time stamps.")
+\f
;;; The custom variables
(defgroup org nil
@@ -824,34 +997,6 @@ effective."
:tag "Org Keywords"
:group 'org)
-(defcustom org-deadline-string "DEADLINE:"
- "String to mark deadline entries.
-A deadline is this string, followed by a time stamp. Should be a word,
-terminated by a colon. You can insert a schedule keyword and
-a timestamp with \\[org-deadline].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-scheduled-string "SCHEDULED:"
- "String to mark scheduled TODO entries.
-A schedule is this string, followed by a time stamp. Should be a word,
-terminated by a colon. You can insert a schedule keyword and
-a timestamp with \\[org-schedule].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-closed-string "CLOSED:"
- "String used as the prefix for timestamps logging closing a TODO entry."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-clock-string "CLOCK:"
- "String used as prefix for timestamps clocking work hours on an item."
- :group 'org-keywords
- :type 'string)
-
(defcustom org-closed-keep-when-no-todo nil
"Remove CLOSED: time-stamp when switching back to a non-todo state?"
:group 'org-todo
@@ -860,35 +1005,6 @@ Changes become only effective after restarting Emacs."
:package-version '(Org . "8.0")
:type 'boolean)
-(defconst org-planning-or-clock-line-re (concat "^[ \t]*\\("
- org-scheduled-string "\\|"
- org-deadline-string "\\|"
- org-closed-string "\\|"
- org-clock-string "\\)")
- "Matches a line with planning or clock info.")
-
-(defcustom org-comment-string "COMMENT"
- "Entries starting with this keyword will never be exported.
-An entry can be toggled between COMMENT and normal with
-\\[org-toggle-comment].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-quote-string "QUOTE"
- "Entries starting with this keyword will be exported in fixed-width font.
-Quoting applies only to the text in the entry following the headline, and does
-not extend beyond the next headline, even if that is lower level.
-An entry can be toggled between QUOTE and normal with
-\\[org-toggle-fixed-width-section]."
- :group 'org-keywords
- :type 'string)
-
-(defconst org-repeat-re
- "<[0-9]\\{4\\}-[0-9][0-9]-[0-9][0-9] [^>\n]*?\\([.+]?\\+[0-9]+[hdwmy]\\(/[0-9]+[hdwmy]\\)?\\)"
- "Regular expression for specifying repeated events.
-After a match, group 1 contains the repeat expression.")
-
(defgroup org-structure nil
"Options concerning the general structure of Org-mode files."
:tag "Org Structure"
@@ -2851,10 +2967,6 @@ the time stamp will always be forced into the second line."
:group 'org-time
:type 'boolean)
-(defconst org-time-stamp-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
- "Formats for `format-time-string' which are used for time stamps.
-It is not recommended to change this constant.")
-
(defcustom org-time-stamp-rounding-minutes '(0 5)
"Number of minutes to round time stamps to.
These are two values, the first applies when first creating a time stamp.
@@ -4228,32 +4340,13 @@ Normal means, no org-mode-specific context."
;;; Autoload and prepare some org modules
-;; Some table stuff that needs to be defined here, because it is used
-;; by the functions setting up org-mode or checking for table context.
-
-(defconst org-table-any-line-regexp "^[ \t]*\\(|\\|\\+-[-+]\\)"
- "Detect an org-type or table-type table.")
-(defconst org-table-line-regexp "^[ \t]*|"
- "Detect an org-type table line.")
-(defconst org-table-dataline-regexp "^[ \t]*|[^-]"
- "Detect an org-type table line.")
-(defconst org-table-hline-regexp "^[ \t]*|-"
- "Detect an org-type table hline.")
-(defconst org-table1-hline-regexp "^[ \t]*\\+-[-+]"
- "Detect a table-type table hline.")
-(defconst org-table-any-border-regexp "^[ \t]*[^|+ \t]"
- "Detect the first line outside a table when searching from within it.
-This works for both table types.")
-
-;; Autoload the functions in org-table.el that are needed by functions here.
+;;;; Autoload the functions in org-table.el that are needed by
+;;;; functions here.
(eval-and-compile
(org-autoload "org-table"
'(org-table-begin org-table-blank-field org-table-end)))
-(defconst org-TBLFM-regexp "^[ \t]*#\\+TBLFM: "
- "Detect a #+TBLFM line.")
-
;;;###autoload
(defun turn-on-orgtbl ()
"Unconditionally turn on `orgtbl-mode'."
@@ -4461,16 +4554,6 @@ the hierarchy, it will be used."
:group 'org-archive
:type 'string)
-(defcustom org-archive-tag "ARCHIVE"
- "The tag that marks a subtree as archived.
-An archived subtree does not open during visibility cycling, and does
-not contribute to the agenda listings.
-After changing this, font-lock must be restarted in the relevant buffers to
-get the proper fontification."
- :group 'org-archive
- :group 'org-keywords
- :type 'string)
-
(defcustom org-agenda-skip-archived-trees t
"Non-nil means the agenda will skip any items located in archived trees.
An archived tree is a tree marked with the tag ARCHIVE. The use of this
@@ -4784,22 +4867,6 @@ means to push this value onto the list in the variable.")
(cons (cons key (if previous (concat previous " " val) val)) remainder)
(cons (cons key val) remainder))))
-(defconst org-block-regexp
- "^[ \t]*#\\+begin_?\\([^ \n]+\\)\\(\\([^\n]+\\)\\)?\n\\([^\000]+?\\)#\\+end_?\\1[ \t]*$"
- "Regular expression for hiding blocks.")
-(defconst org-heading-keyword-regexp-format
- "^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
- "Printf format for a regexp matching a headline with some keyword.
-This regexp will match the headline of any node which has the
-exact keyword that is put into the format. The keyword isn't in
-any group by default, but the stars and the body are.")
-(defconst org-heading-keyword-maybe-regexp-format
- "^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$"
- "Printf format for a regexp matching a headline, possibly with some keyword.
-This regexp can match any headline with the specified keyword, or
-without a keyword. The keyword isn't in any group by default,
-but the stars and the body are.")
-
(defcustom org-group-tags t
"When non-nil (the default), use group tags.
This can be turned on/off through `org-toggle-tags-groups'."
@@ -5662,35 +5729,6 @@ This should be called after the variable `org-link-types' has changed."
(org-make-link-regexps)
-(defconst org-ts-regexp "<\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^\r\n>]*?\\)>"
- "Regular expression for fast time stamp matching.")
-(defconst org-ts-regexp-both "[[<]\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^]\r\n>]*?\\)[]>]"
- "Regular expression for fast time stamp matching.")
-(defconst org-ts-regexp0
- "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\)\\( +[^]+0-9>\r\n -]+\\)?\\( +\\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
- "Regular expression matching time strings for analysis.
-This one does not require the space after the date, so it can be used
-on a string that terminates immediately after the date.")
-(defconst org-ts-regexp1 "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\) *\\([^]+0-9>\r\n -]*\\)\\( \\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
- "Regular expression matching time strings for analysis.")
-(defconst org-ts-regexp2 (concat "<" org-ts-regexp1 "[^>\n]\\{0,16\\}>")
- "Regular expression matching time stamps, with groups.")
-(defconst org-ts-regexp3 (concat "[[<]" org-ts-regexp1 "[^]>\n]\\{0,16\\}[]>]")
- "Regular expression matching time stamps (also [..]), with groups.")
-(defconst org-tr-regexp (concat org-ts-regexp "--?-?" org-ts-regexp)
- "Regular expression matching a time stamp range.")
-(defconst org-tr-regexp-both
- (concat org-ts-regexp-both "--?-?" org-ts-regexp-both)
- "Regular expression matching a time stamp range.")
-(defconst org-tsr-regexp (concat org-ts-regexp "\\(--?-?"
- org-ts-regexp "\\)?")
- "Regular expression matching a time stamp or time stamp range.")
-(defconst org-tsr-regexp-both
- (concat org-ts-regexp-both "\\(--?-?"
- org-ts-regexp-both "\\)?")
- "Regular expression matching a time stamp or time stamp range.
-The time stamps may be either active or inactive.")
-
(defvar org-emph-face nil)
(defun org-do-emphasis-faces (limit)
@@ -11834,13 +11872,6 @@ If not found, stay at current position and return nil."
(if pos (goto-char pos))
pos))
-(defconst org-dblock-start-re
- "^[ \t]*#\\+\\(?:BEGIN\\|begin\\):[ \t]+\\(\\S-+\\)\\([ \t]+\\(.*\\)\\)?"
- "Matches the start line of a dynamic block, with parameters.")
-
-(defconst org-dblock-end-re "^[ \t]*#\\+\\(?:END\\|end\\)\\([: \t\r\n]\\|$\\)"
- "Matches the end of a dynamic block.")
-
(defun org-create-dblock (plist)
"Create a dynamic block section, with parameters taken from PLIST.
PLIST must contain a :name entry which is used as name of the block."
@@ -15036,28 +15067,6 @@ but in some other way.")
"Some properties that are used by Org-mode for various purposes.
Being in this list makes sure that they are offered for completion.")
-(defconst org-property-start-re "^[ \t]*:PROPERTIES:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-property-end-re "^[ \t]*:END:[ \t]*$"
- "Regular expression matching the last line of a property drawer.")
-
-(defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-clock-drawer-end-re "^[ \t]*:END:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-property-drawer-re
- (concat "\\(" org-property-start-re "\\)[^\000]*?\\("
- org-property-end-re "\\)\n?")
- "Matches an entire property drawer.")
-
-(defconst org-clock-drawer-re
- (concat "\\(" org-clock-drawer-start-re "\\)[^\000]*?\\("
- org-property-end-re "\\)\n?")
- "Matches an entire clock drawer.")
-
(defun org-property-action ()
"Do an action on properties."
(interactive)
--
1.8.4.2
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-29 14:04 ` Nicolas Goaziou
@ 2013-10-29 14:11 ` Nicolas Goaziou
0 siblings, 0 replies; 19+ messages in thread
From: Nicolas Goaziou @ 2013-10-29 14:11 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Correcting myself,
> Here is the suggested patch.
I forgot `org-effort-property'. Also, the new version moves
`org-latex-regexps' from defvar to defconst status.
--
Nicolas Goaziou
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Change-some-defcustoms-into-defconsts.patch --]
[-- Type: text/x-diff, Size: 21077 bytes --]
From d002525910b6fbeaec530138494bf43397be200b Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Tue, 29 Oct 2013 14:53:21 +0100
Subject: [PATCH] Change some defcustoms into defconsts
* lisp/org.el (org-clock-string, org-closed-string)
(org-deadline-string, org-scheduled-string)
(org-archive-tag, org-comment-string, org-quote-string)
(org-effort-property, org-latex-regexps): Turn variables into
constants.
* testing/lisp/test-org-element.el: Update test.
Also collect all syntax related constants in the same part of the
file.
---
lisp/org.el | 380 ++++++++++++++++++++-------------------
testing/lisp/test-org-element.el | 20 +--
2 files changed, 201 insertions(+), 199 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f3bf4b..2f4535d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -314,8 +314,200 @@ When MESSAGE is non-nil, display a message with the version."
(defconst org-version (org-version))
-;;; Compatibility constants
+\f
+;;; Syntax Constants
+
+;;;; Block
+
+(defconst org-block-regexp
+ "^[ \t]*#\\+begin_?\\([^ \n]+\\)\\(\\([^\n]+\\)\\)?\n\\([^\000]+?\\)#\\+end_?\\1[ \t]*$"
+ "Regular expression for hiding blocks.")
+
+(defconst org-dblock-start-re
+ "^[ \t]*#\\+\\(?:BEGIN\\|begin\\):[ \t]+\\(\\S-+\\)\\([ \t]+\\(.*\\)\\)?"
+ "Matches the start line of a dynamic block, with parameters.")
+
+(defconst org-dblock-end-re "^[ \t]*#\\+\\(?:END\\|end\\)\\([: \t\r\n]\\|$\\)"
+ "Matches the end of a dynamic block.")
+
+;;;; Clock and Planning
+
+(defconst org-clock-string "CLOCK:"
+ "String used as prefix for timestamps clocking work hours on an item.")
+
+(defconst org-closed-string "CLOSED:"
+ "String used as the prefix for timestamps logging closing a TODO entry.")
+
+(defconst org-deadline-string "DEADLINE:"
+ "String to mark deadline entries.
+A deadline is this string, followed by a time stamp. Should be a word,
+terminated by a colon. You can insert a schedule keyword and
+a timestamp with \\[org-deadline].")
+
+(defconst org-scheduled-string "SCHEDULED:"
+ "String to mark scheduled TODO entries.
+A schedule is this string, followed by a time stamp. Should be a word,
+terminated by a colon. You can insert a schedule keyword and
+a timestamp with \\[org-schedule].")
+
+(defconst org-planning-or-clock-line-re
+ (concat "^[ \t]*"
+ (regexp-opt
+ (list org-clock-string org-closed-string org-deadline-string
+ org-scheduled-string)
+ t))
+ "Matches a line with planning or clock info.
+Matched keyword is in group 1.")
+
+;;;; Drawer
+
+(defconst org-property-start-re "^[ \t]*:PROPERTIES:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-property-end-re "^[ \t]*:END:[ \t]*$"
+ "Regular expression matching the last line of a property drawer.")
+
+(defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-clock-drawer-end-re "^[ \t]*:END:[ \t]*$"
+ "Regular expression matching the first line of a property drawer.")
+
+(defconst org-property-drawer-re
+ (concat "\\(" org-property-start-re "\\)[^\000]*?\\("
+ org-property-end-re "\\)\n?")
+ "Matches an entire property drawer.")
+
+(defconst org-clock-drawer-re
+ (concat "\\(" org-clock-drawer-start-re "\\)[^\000]*?\\("
+ org-property-end-re "\\)\n?")
+ "Matches an entire clock drawer.")
+
+;;;; Headline
+
+(defconst org-heading-keyword-regexp-format
+ "^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
+ "Printf format for a regexp matching a headline with some keyword.
+This regexp will match the headline of any node which has the
+exact keyword that is put into the format. The keyword isn't in
+any group by default, but the stars and the body are.")
+
+(defconst org-heading-keyword-maybe-regexp-format
+ "^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$"
+ "Printf format for a regexp matching a headline, possibly with some keyword.
+This regexp can match any headline with the specified keyword, or
+without a keyword. The keyword isn't in any group by default,
+but the stars and the body are.")
+
+(defconst org-archive-tag "ARCHIVE"
+ "The tag that marks a subtree as archived.
+An archived subtree does not open during visibility cycling, and does
+not contribute to the agenda listings.")
+
+(defconst org-comment-string "COMMENT"
+ "Entries starting with this keyword will never be exported.
+An entry can be toggled between COMMENT and normal with
+\\[org-toggle-comment].")
+
+(defconst org-quote-string "QUOTE"
+ "Entries starting with this keyword will be exported in fixed-width font.
+Quoting applies only to the text in the entry following the headline, and does
+not extend beyond the next headline, even if that is lower level.
+An entry can be toggled between QUOTE and normal with
+\\[org-toggle-fixed-width-section].")
+
+;;;; LaTeX Environments and Fragments
+
+(defconst org-latex-regexps
+ '(("begin" "^[ \t]*\\(\\\\begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?\\\\end{\\2}\\)" 1 t)
+ ;; ("$" "\\([ (]\\|^\\)\\(\\(\\([$]\\)\\([^ \r\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \r\n,.$]\\)\\4\\)\\)\\([ .,?;:'\")]\\|$\\)" 2 nil)
+ ;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
+ ("$1" "\\([^$]\\|^\\)\\(\\$[^ \r\n,;.$]\\$\\)\\([- .,?;:'\")\000]\\|$\\)" 2 nil)
+ ("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^ \r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \r\n,.$]\\)\\$\\)\\)\\([- .,?;:'\")\000]\\|$\\)" 2 nil)
+ ("\\(" "\\\\([^\000]*?\\\\)" 0 nil)
+ ("\\[" "\\\\\\[[^\000]*?\\\\\\]" 0 nil)
+ ("$$" "\\$\\$[^\000]*?\\$\\$" 0 nil))
+ "Regular expressions for matching embedded LaTeX.")
+
+;;;; Node Property
+
+(defconst org-effort-property "Effort"
+ "The property that is being used to keep track of effort estimates.
+Effort estimates given in this property need to have the format H:MM.")
+
+;;;; Table
+
+(defconst org-table-any-line-regexp "^[ \t]*\\(|\\|\\+-[-+]\\)"
+ "Detect an org-type or table-type table.")
+
+(defconst org-table-line-regexp "^[ \t]*|"
+ "Detect an org-type table line.")
+
+(defconst org-table-dataline-regexp "^[ \t]*|[^-]"
+ "Detect an org-type table line.")
+
+(defconst org-table-hline-regexp "^[ \t]*|-"
+ "Detect an org-type table hline.")
+
+(defconst org-table1-hline-regexp "^[ \t]*\\+-[-+]"
+ "Detect a table-type table hline.")
+
+(defconst org-table-any-border-regexp "^[ \t]*[^|+ \t]"
+ "Detect the first line outside a table when searching from within it.
+This works for both table types.")
+
+(defconst org-TBLFM-regexp "^[ \t]*#\\+TBLFM: "
+ "Detect a #+TBLFM line.")
+
+;;;; Timestamp
+
+(defconst org-ts-regexp "<\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^\r\n>]*?\\)>"
+ "Regular expression for fast time stamp matching.")
+
+(defconst org-ts-regexp-both "[[<]\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^]\r\n>]*?\\)[]>]"
+ "Regular expression for fast time stamp matching.")
+
+(defconst org-ts-regexp0
+ "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\)\\( +[^]+0-9>\r\n -]+\\)?\\( +\\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
+ "Regular expression matching time strings for analysis.
+This one does not require the space after the date, so it can be used
+on a string that terminates immediately after the date.")
+
+(defconst org-ts-regexp1 "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\) *\\([^]+0-9>\r\n -]*\\)\\( \\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
+ "Regular expression matching time strings for analysis.")
+
+(defconst org-ts-regexp2 (concat "<" org-ts-regexp1 "[^>\n]\\{0,16\\}>")
+ "Regular expression matching time stamps, with groups.")
+
+(defconst org-ts-regexp3 (concat "[[<]" org-ts-regexp1 "[^]>\n]\\{0,16\\}[]>]")
+ "Regular expression matching time stamps (also [..]), with groups.")
+
+(defconst org-tr-regexp (concat org-ts-regexp "--?-?" org-ts-regexp)
+ "Regular expression matching a time stamp range.")
+
+(defconst org-tr-regexp-both
+ (concat org-ts-regexp-both "--?-?" org-ts-regexp-both)
+ "Regular expression matching a time stamp range.")
+
+(defconst org-tsr-regexp (concat org-ts-regexp "\\(--?-?"
+ org-ts-regexp "\\)?")
+ "Regular expression matching a time stamp or time stamp range.")
+
+(defconst org-tsr-regexp-both
+ (concat org-ts-regexp-both "\\(--?-?"
+ org-ts-regexp-both "\\)?")
+ "Regular expression matching a time stamp or time stamp range.
+The time stamps may be either active or inactive.")
+
+(defconst org-repeat-re
+ "<[0-9]\\{4\\}-[0-9][0-9]-[0-9][0-9] [^>\n]*?\\([.+]?\\+[0-9]+[hdwmy]\\(/[0-9]+[hdwmy]\\)?\\)"
+ "Regular expression for specifying repeated events.
+After a match, group 1 contains the repeat expression.")
+
+(defconst org-time-stamp-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
+ "Formats for `format-time-string' which are used for time stamps.")
+\f
;;; The custom variables
(defgroup org nil
@@ -824,34 +1016,6 @@ effective."
:tag "Org Keywords"
:group 'org)
-(defcustom org-deadline-string "DEADLINE:"
- "String to mark deadline entries.
-A deadline is this string, followed by a time stamp. Should be a word,
-terminated by a colon. You can insert a schedule keyword and
-a timestamp with \\[org-deadline].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-scheduled-string "SCHEDULED:"
- "String to mark scheduled TODO entries.
-A schedule is this string, followed by a time stamp. Should be a word,
-terminated by a colon. You can insert a schedule keyword and
-a timestamp with \\[org-schedule].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-closed-string "CLOSED:"
- "String used as the prefix for timestamps logging closing a TODO entry."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-clock-string "CLOCK:"
- "String used as prefix for timestamps clocking work hours on an item."
- :group 'org-keywords
- :type 'string)
-
(defcustom org-closed-keep-when-no-todo nil
"Remove CLOSED: time-stamp when switching back to a non-todo state?"
:group 'org-todo
@@ -860,35 +1024,6 @@ Changes become only effective after restarting Emacs."
:package-version '(Org . "8.0")
:type 'boolean)
-(defconst org-planning-or-clock-line-re (concat "^[ \t]*\\("
- org-scheduled-string "\\|"
- org-deadline-string "\\|"
- org-closed-string "\\|"
- org-clock-string "\\)")
- "Matches a line with planning or clock info.")
-
-(defcustom org-comment-string "COMMENT"
- "Entries starting with this keyword will never be exported.
-An entry can be toggled between COMMENT and normal with
-\\[org-toggle-comment].
-Changes become only effective after restarting Emacs."
- :group 'org-keywords
- :type 'string)
-
-(defcustom org-quote-string "QUOTE"
- "Entries starting with this keyword will be exported in fixed-width font.
-Quoting applies only to the text in the entry following the headline, and does
-not extend beyond the next headline, even if that is lower level.
-An entry can be toggled between QUOTE and normal with
-\\[org-toggle-fixed-width-section]."
- :group 'org-keywords
- :type 'string)
-
-(defconst org-repeat-re
- "<[0-9]\\{4\\}-[0-9][0-9]-[0-9][0-9] [^>\n]*?\\([.+]?\\+[0-9]+[hdwmy]\\(/[0-9]+[hdwmy]\\)?\\)"
- "Regular expression for specifying repeated events.
-After a match, group 1 contains the repeat expression.")
-
(defgroup org-structure nil
"Options concerning the general structure of Org-mode files."
:tag "Org Structure"
@@ -2851,10 +2986,6 @@ the time stamp will always be forced into the second line."
:group 'org-time
:type 'boolean)
-(defconst org-time-stamp-formats '("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
- "Formats for `format-time-string' which are used for time stamps.
-It is not recommended to change this constant.")
-
(defcustom org-time-stamp-rounding-minutes '(0 5)
"Number of minutes to round time stamps to.
These are two values, the first applies when first creating a time stamp.
@@ -3522,13 +3653,6 @@ or nil if the normal value should be used."
:group 'org-properties
:type '(choice (const nil) (function)))
-(defcustom org-effort-property "Effort"
- "The property that is being used to keep track of effort estimates.
-Effort estimates given in this property need to have the format H:MM."
- :group 'org-properties
- :group 'org-progress
- :type '(string :tag "Property"))
-
(defconst org-global-properties-fixed
'(("VISIBILITY_ALL" . "folded children content all")
("CLOCK_MODELINE_TOTAL_ALL" . "current today repeat all auto"))
@@ -4228,32 +4352,13 @@ Normal means, no org-mode-specific context."
;;; Autoload and prepare some org modules
-;; Some table stuff that needs to be defined here, because it is used
-;; by the functions setting up org-mode or checking for table context.
-
-(defconst org-table-any-line-regexp "^[ \t]*\\(|\\|\\+-[-+]\\)"
- "Detect an org-type or table-type table.")
-(defconst org-table-line-regexp "^[ \t]*|"
- "Detect an org-type table line.")
-(defconst org-table-dataline-regexp "^[ \t]*|[^-]"
- "Detect an org-type table line.")
-(defconst org-table-hline-regexp "^[ \t]*|-"
- "Detect an org-type table hline.")
-(defconst org-table1-hline-regexp "^[ \t]*\\+-[-+]"
- "Detect a table-type table hline.")
-(defconst org-table-any-border-regexp "^[ \t]*[^|+ \t]"
- "Detect the first line outside a table when searching from within it.
-This works for both table types.")
-
-;; Autoload the functions in org-table.el that are needed by functions here.
+;;;; Autoload the functions in org-table.el that are needed by
+;;;; functions here.
(eval-and-compile
(org-autoload "org-table"
'(org-table-begin org-table-blank-field org-table-end)))
-(defconst org-TBLFM-regexp "^[ \t]*#\\+TBLFM: "
- "Detect a #+TBLFM line.")
-
;;;###autoload
(defun turn-on-orgtbl ()
"Unconditionally turn on `orgtbl-mode'."
@@ -4461,16 +4566,6 @@ the hierarchy, it will be used."
:group 'org-archive
:type 'string)
-(defcustom org-archive-tag "ARCHIVE"
- "The tag that marks a subtree as archived.
-An archived subtree does not open during visibility cycling, and does
-not contribute to the agenda listings.
-After changing this, font-lock must be restarted in the relevant buffers to
-get the proper fontification."
- :group 'org-archive
- :group 'org-keywords
- :type 'string)
-
(defcustom org-agenda-skip-archived-trees t
"Non-nil means the agenda will skip any items located in archived trees.
An archived tree is a tree marked with the tag ARCHIVE. The use of this
@@ -4784,22 +4879,6 @@ means to push this value onto the list in the variable.")
(cons (cons key (if previous (concat previous " " val) val)) remainder)
(cons (cons key val) remainder))))
-(defconst org-block-regexp
- "^[ \t]*#\\+begin_?\\([^ \n]+\\)\\(\\([^\n]+\\)\\)?\n\\([^\000]+?\\)#\\+end_?\\1[ \t]*$"
- "Regular expression for hiding blocks.")
-(defconst org-heading-keyword-regexp-format
- "^\\(\\*+\\)\\(?: +%s\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
- "Printf format for a regexp matching a headline with some keyword.
-This regexp will match the headline of any node which has the
-exact keyword that is put into the format. The keyword isn't in
-any group by default, but the stars and the body are.")
-(defconst org-heading-keyword-maybe-regexp-format
- "^\\(\\*+\\)\\(?: +%s\\)?\\(?: +\\(.*?\\)\\)?[ \t]*$"
- "Printf format for a regexp matching a headline, possibly with some keyword.
-This regexp can match any headline with the specified keyword, or
-without a keyword. The keyword isn't in any group by default,
-but the stars and the body are.")
-
(defcustom org-group-tags t
"When non-nil (the default), use group tags.
This can be turned on/off through `org-toggle-tags-groups'."
@@ -5662,35 +5741,6 @@ This should be called after the variable `org-link-types' has changed."
(org-make-link-regexps)
-(defconst org-ts-regexp "<\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^\r\n>]*?\\)>"
- "Regular expression for fast time stamp matching.")
-(defconst org-ts-regexp-both "[[<]\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?[^]\r\n>]*?\\)[]>]"
- "Regular expression for fast time stamp matching.")
-(defconst org-ts-regexp0
- "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\)\\( +[^]+0-9>\r\n -]+\\)?\\( +\\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
- "Regular expression matching time strings for analysis.
-This one does not require the space after the date, so it can be used
-on a string that terminates immediately after the date.")
-(defconst org-ts-regexp1 "\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\) *\\([^]+0-9>\r\n -]*\\)\\( \\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\)"
- "Regular expression matching time strings for analysis.")
-(defconst org-ts-regexp2 (concat "<" org-ts-regexp1 "[^>\n]\\{0,16\\}>")
- "Regular expression matching time stamps, with groups.")
-(defconst org-ts-regexp3 (concat "[[<]" org-ts-regexp1 "[^]>\n]\\{0,16\\}[]>]")
- "Regular expression matching time stamps (also [..]), with groups.")
-(defconst org-tr-regexp (concat org-ts-regexp "--?-?" org-ts-regexp)
- "Regular expression matching a time stamp range.")
-(defconst org-tr-regexp-both
- (concat org-ts-regexp-both "--?-?" org-ts-regexp-both)
- "Regular expression matching a time stamp range.")
-(defconst org-tsr-regexp (concat org-ts-regexp "\\(--?-?"
- org-ts-regexp "\\)?")
- "Regular expression matching a time stamp or time stamp range.")
-(defconst org-tsr-regexp-both
- (concat org-ts-regexp-both "\\(--?-?"
- org-ts-regexp-both "\\)?")
- "Regular expression matching a time stamp or time stamp range.
-The time stamps may be either active or inactive.")
-
(defvar org-emph-face nil)
(defun org-do-emphasis-faces (limit)
@@ -11834,13 +11884,6 @@ If not found, stay at current position and return nil."
(if pos (goto-char pos))
pos))
-(defconst org-dblock-start-re
- "^[ \t]*#\\+\\(?:BEGIN\\|begin\\):[ \t]+\\(\\S-+\\)\\([ \t]+\\(.*\\)\\)?"
- "Matches the start line of a dynamic block, with parameters.")
-
-(defconst org-dblock-end-re "^[ \t]*#\\+\\(?:END\\|end\\)\\([: \t\r\n]\\|$\\)"
- "Matches the end of a dynamic block.")
-
(defun org-create-dblock (plist)
"Create a dynamic block section, with parameters taken from PLIST.
PLIST must contain a :name entry which is used as name of the block."
@@ -15036,28 +15079,6 @@ but in some other way.")
"Some properties that are used by Org-mode for various purposes.
Being in this list makes sure that they are offered for completion.")
-(defconst org-property-start-re "^[ \t]*:PROPERTIES:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-property-end-re "^[ \t]*:END:[ \t]*$"
- "Regular expression matching the last line of a property drawer.")
-
-(defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-clock-drawer-end-re "^[ \t]*:END:[ \t]*$"
- "Regular expression matching the first line of a property drawer.")
-
-(defconst org-property-drawer-re
- (concat "\\(" org-property-start-re "\\)[^\000]*?\\("
- org-property-end-re "\\)\n?")
- "Matches an entire property drawer.")
-
-(defconst org-clock-drawer-re
- (concat "\\(" org-clock-drawer-start-re "\\)[^\000]*?\\("
- org-property-end-re "\\)\n?")
- "Matches an entire clock drawer.")
-
(defun org-property-action ()
"Do an action on properties."
(interactive)
@@ -18203,17 +18224,6 @@ Revert to the normal definition outside of these fragments."
\f
;;;; LaTeX fragments
-(defvar org-latex-regexps
- '(("begin" "^[ \t]*\\(\\\\begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?\\\\end{\\2}\\)" 1 t)
- ;; ("$" "\\([ (]\\|^\\)\\(\\(\\([$]\\)\\([^ \r\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \r\n,.$]\\)\\4\\)\\)\\([ .,?;:'\")]\\|$\\)" 2 nil)
- ;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
- ("$1" "\\([^$]\\|^\\)\\(\\$[^ \r\n,;.$]\\$\\)\\([- .,?;:'\")\000]\\|$\\)" 2 nil)
- ("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^ \r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \r\n,.$]\\)\\$\\)\\)\\([- .,?;:'\")\000]\\|$\\)" 2 nil)
- ("\\(" "\\\\([^\000]*?\\\\)" 0 nil)
- ("\\[" "\\\\\\[[^\000]*?\\\\\\]" 0 nil)
- ("$$" "\\$\\$[^\000]*?\\$\\$" 0 nil))
- "Regular expressions for matching embedded LaTeX.")
-
(defun org-inside-LaTeX-fragment-p ()
"Test if point is inside a LaTeX fragment.
I.e. after a \\begin, \\(, \\[, $, or $$, without the corresponding closing
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 4f08e3e..a59ea14 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2476,20 +2476,12 @@ DEADLINE: <2012-01-01> SCHEDULED: <2012-01-01> CLOSED: [2012-01-01]\n"))))
(ert-deftest test-org-element/latex-fragment-interpreter ()
"Test latex fragment interpreter."
- (let ((org-latex-regexps
- '(("begin" "^[ ]*\\(\\\\begin{\\([a-zA-Z0-9\\*]+\\)[^
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-10-23 13:25 ` Carsten Dominik
2013-10-29 14:04 ` Nicolas Goaziou
@ 2013-11-16 20:25 ` Nicolas Goaziou
2013-11-16 23:55 ` Carsten Dominik
1 sibling, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2013-11-16 20:25 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode List
Hello,
Carsten Dominik <drostekirsten@gmail.com> writes:
> So: IF YOU HAVE CUSTOMIZED any of this variables, I'd like to hear about it.
> Otherwise, I now think that the proposal is actually good and should
> move ahead.
I applied the patch.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] Change some defcustoms into defcont
2013-11-16 20:25 ` Nicolas Goaziou
@ 2013-11-16 23:55 ` Carsten Dominik
0 siblings, 0 replies; 19+ messages in thread
From: Carsten Dominik @ 2013-11-16 23:55 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List, Carsten Dominik
On 16.11.2013, at 21:25, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Carsten Dominik <drostekirsten@gmail.com> writes:
>
>> So: IF YOU HAVE CUSTOMIZED any of this variables, I'd like to hear about it.
>> Otherwise, I now think that the proposal is actually good and should
>> move ahead.
>
> I applied the patch.
Thank you.
- Carsten
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-11-16 23:55 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-20 8:47 [RFC] Change some defcustoms into defcont Nicolas Goaziou
2013-10-20 18:23 ` Carsten Dominik
2013-10-21 8:56 ` Nicolas Goaziou
2013-10-21 10:26 ` Carsten Dominik
2013-10-21 10:51 ` Nicolas Goaziou
2013-10-21 11:56 ` Carsten Dominik
2013-10-21 15:15 ` Nicolas Goaziou
2013-10-22 7:50 ` Carsten Dominik
2013-10-22 9:52 ` Nicolas Goaziou
2013-10-22 10:34 ` Carsten Dominik
2013-10-22 18:28 ` Torsten Wagner
2013-10-22 20:00 ` Florian Beck
2013-10-23 8:56 ` Nicolas Goaziou
2013-10-23 13:25 ` Carsten Dominik
2013-10-29 14:04 ` Nicolas Goaziou
2013-10-29 14:11 ` Nicolas Goaziou
2013-11-16 20:25 ` Nicolas Goaziou
2013-11-16 23:55 ` Carsten Dominik
2013-10-21 8:17 ` Sebastien Vauban
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).