Matt Lundin writes:
> Bastien writes:
>>
>> I fixed the problem with `org-clock-state'. This should be `org-state'.
>>
>> `state' is a local variable in many org.el functions, I renamed it to
>> `org-state' in org-clock.el and in "caller" sexp from org.el.
>
> Attached please find a patch tha
Bastien writes:
>
> I fixed the problem with `org-clock-state'. This should be `org-state'.
>
> `state' is a local variable in many org.el functions, I renamed it to
> `org-state' in org-clock.el and in "caller" sexp from org.el.
>
Attached please find a patch that fixes the docstring of
org-a
Achim Gratz writes:
> Bastien writes:
>> 1. one about `buffer-substring-filters'
>> We should write a compatibility function to get rid of the first
>> warning.
>
> Actually it is a variable and it "just" needs to be aliased suitably,
> depending on which Emacs version it encounters.
I'm afrai
Bastien writes:
> 1. one about `buffer-substring-filters'
> We should write a compatibility function to get rid of the first
> warning.
Actually it is a variable and it "just" needs to be aliased suitably,
depending on which Emacs version it encounters. This should be done
with a macro in org-com
Hi Achim,
Achim Gratz writes:
> Bastien writes:
>> Let's do some heavy testing against current HEAD and let's carefully
>> review code. But let's not panic -- Emacs is still in pretest, that's
>> the whole purpose of a pretest.
>
> It looks like you've already took care of the fixes. Anythi
Bastien writes:
> Let's do some heavy testing against current HEAD and let's carefully
> review code. But let's not panic -- Emacs is still in pretest, that's
> the whole purpose of a pretest.
It looks like you've already took care of the fixes. Anything that you
specifically want to review?
Hi Nick,
Nick Dokos writes:
> Agreed, but the point is that each and every variable renaming will need
> to be checked in the light of these criteria. Bugs like this have the
> potential of creating havoc for a long time to come.
>
> It may be easier to start from a working state than to try to
Achim Gratz writes:
> Nick Dokos writes:
>> I assume that we are talking about the seven commits
>
> Yes, but likely not all of them (or all changes in them). The only
> problematic ones are where a dynamically scoped variable is renamed and
> there are a bunch of others that probably are OK.
L
Achim Gratz writes:
> Bastien writes:
>> Well -- I'll be pretty busy next week, so hopefully we can fix this
>> soon... any help welcome! :)
>
> Ditto, but you do realize this will be horribly broken in Emacs 24?
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=08d9b466225fad7e4cacd593f5ec7
Achim Gratz writes:
> Bernt Hansen writes:
>> I can see the variable in the source defined as
>>
>> lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this
>> function
>>
>> but I don't get a variable definition with this code in emacs 23.2.1.
>
> You aren't supposed to get on
Nick Dokos writes:
> There is (supposed to be) *one* place somewhere that actually defines
> it:
>
> (defvar foo 1)
... unless foo is dynamically bound into a "caller" sexp.
--
Bastien
Achim Gratz wrote:
> Nick Dokos writes:
> > I assume that we are talking about the seven commits
>
> Yes, but likely not all of them (or all changes in them). The only
> problematic ones are where a dynamically scoped variable is renamed and
> there are a bunch of others that probably are OK.
>
Nick Dokos writes:
> I assume that we are talking about the seven commits
Yes, but likely not all of them (or all changes in them). The only
problematic ones are where a dynamically scoped variable is renamed and
there are a bunch of others that probably are OK.
> $ git log --oneline -100 | grep
Achim Gratz wrote:
> Bastien writes:
> > Well -- I'll be pretty busy next week, so hopefully we can fix this
> > soon... any help welcome! :)
>
> Ditto, but you do realize this will be horribly broken in Emacs 24?
>
> Anyway, for that single dynamic "state" variable: it is let-bound in
> org.
Bastien writes:
> Well -- I'll be pretty busy next week, so hopefully we can fix this
> soon... any help welcome! :)
Ditto, but you do realize this will be horribly broken in Emacs 24?
Anyway, for that single dynamic "state" variable: it is let-bound in
org.el/org-todo and then dynamically scop
Nick Dokos writes:
> Bernt Hansen wrote:
>
>> Hi Bastien,
>>
>> I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01)
>> and am getting errors about org-clock-last-state not defined in my GNU
>> Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on
>> raven, m
Bernt Hansen wrote:
> Hi Bastien,
>
> I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01)
> and am getting errors about org-clock-last-state not defined in my GNU
> Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on
> raven, modified by Debian
>
> I can s
Achim Gratz writes:
> Again, the missing value is not the problem. The problem arises when
> the variable name in the caller and the callee becomes different. I'll
> let Bastien and Martyn sort that one out... :-)
Well -- I'll be pretty busy next week, so hopefully we can fix this
soon... any
Bernt Hansen writes:
> I can see the variable in the source defined as
>
> lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this
> function
>
> but I don't get a variable definition with this code in emacs 23.2.1.
You aren't supposed to get one, as this should have been pulli
Hi Bastien,
I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01)
and am getting errors about org-clock-last-state not defined in my GNU
Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on
raven, modified by Debian
I can see the variable in the source defined
20 matches
Mail list logo
