recent changes to org files

recent changes to org files

[Glenn Morris]

When you install changes to org files, will you please look at the
actual diffs before you do so, and only apply the bits that make sense?

In the changes you just installed, you have:

1) Clobbered existing changes in org-publish.el and org.el without
   comment or explanation.

2) Downcased the copyright header in org-export-latex.el yet again.

3) Put the ChangeLog entry for org.texi in the wrong ChangeLog file
   (and no changes to org.texi were installed).

4) Missed off the "textmodes/" part of "textmodes/org.el" in the
   ChangeLog.

5) Installed changes to org-export-latex with no ChangeLog or CVS log
   entry.

Re: recent changes to org files

[John Wiegley]

Glenn Morris <rgm@gnu.org> writes:

> When you install changes to org files, will you please look at the actual
> diffs before you do so, and only apply the bits that make sense?

Hmm... I'm just installing what the author distributes.  It was never
mentioned to me that the Emacs developers might be making changes directly to
his files without exporting those changes back to his own sources.

Perhaps it would be better if I left it to the author to merge any Emacs CVS
changes into his code and then check them in directly, rather than posting the
contents of his new releases verbatim to CVS.  What do you think, Carsten?

John

Re: recent changes to org files

[Stefan Monnier]

>> When you install changes to org files, will you please look at the actual
>> diffs before you do so, and only apply the bits that make sense?

> Hmm... I'm just installing what the author distributes.  It was never
> mentioned to me that the Emacs developers might be making changes directly to
> his files without exporting those changes back to his own sources.

> Perhaps it would be better if I left it to the author to merge any Emacs CVS
> changes into his code and then check them in directly, rather than posting the
> contents of his new releases verbatim to CVS.  What do you think, Carsten?

To me the rule goes as follows: I only install patches, not files.
That usually takes core of those problems: if the author's version disagrees
with the CVS version I get a conflict when I try to apply the patch.


        Stefan

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 2:57 AM, Stefan Monnier wrote:

>>> When you install changes to org files, will you please look at  
>>> the actual
>>> diffs before you do so, and only apply the bits that make sense?
>
>> Hmm... I'm just installing what the author distributes.  It was never
>> mentioned to me that the Emacs developers might be making changes  
>> directly to
>> his files without exporting those changes back to his own sources.
>
>> Perhaps it would be better if I left it to the author to merge any  
>> Emacs CVS
>> changes into his code and then check them in directly, rather than  
>> posting the
>> contents of his new releases verbatim to CVS.  What do you think,  
>> Carsten?
>
> To me the rule goes as follows: I only install patches, not files.
> That usually takes core of those problems: if the author's version  
> disagrees
> with the CVS version I get a conflict when I try to apply the patch.


OK, obviously I have a version of org-export-latex in my distribution  
that still has the old copyright.  Will fix this.  Sorry for all the  
trouble. Thanks to John for trying to take this off my shoulders.

I will try to do this again myself in the future - which means that  
the Emacs version will lag behind.  We have something like a 2 week  
release schedule, synching up with Emacs is extra work for me, and  
with the next release a year (?) away, I am not sure it is very  
useful to spend the time.

Again, thanks and sorry, to whom it may apply.

- Carsten

Re: recent changes to org files

[Carsten Dominik]

> To me the rule goes as follows: I only install patches, not files.
> That usually takes core of those problems: if the author's version  
> disagrees
> with the CVS version I get a conflict when I try to apply the patch.


To me it works like this:  My copy is the master copy, not the one in  
Emacs.  The best
setup for me would be to get email notifications, maybe with a patch,  
whenever some
Emacs developer touches my files in Emacs.  Then I can decide if I  
agree with these
changes and incorporate the accepted part into my master copy.

- Carsten

Re: recent changes to org files

[Juanma Barranquero]

On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> The best
> setup for me would be to get email notifications, maybe with a patch,
> whenever some
> Emacs developer touches my files in Emacs.

Could you simply subscribe to emacs-diffs and set a filter to remove
any messages from that origin not containing "emacs/lisp/org" or
"emacs/lisp/ChangeLog" in the subject? Or is that infeasible in your
setup?

             Juanma

Re: recent changes to org files

[David Kastrup]

Carsten Dominik <carsten.dominik@gmail.com> writes:

>> To me the rule goes as follows: I only install patches, not files.
>> That usually takes core of those problems: if the author's version
>> disagrees with the CVS version I get a conflict when I try to apply
>> the patch.
>
>
> To me it works like this: My copy is the master copy, not the one in
> Emacs.  The best setup for me would be to get email notifications,
> maybe with a patch, whenever some Emacs developer touches my files
> in Emacs.  Then I can decide if I agree with these changes and
> incorporate the accepted part into my master copy.

But this does not change that any changes by Emacs developers to the
copy in Emacs have been put there in the course of Emacs development
and with the usual amount of peer review for patches.  It is certainly
your choice to accept those patches (or not) into your master copy.
However, that does not mean that this decision should result in
clobbering the changes in the Emacs copy.

It is never correct to do or undo changes in Emacs without Changelog
entry and/or CVS log.  And dissent over the desirability of some
change should not result in "battling commits".

So the right solution can never be just copying over existing files
without any attempt of merging the changes or explaining why they were
undone.

My personal recommendation would be to use the git mirror of Emacs'
CVS.  Using gitk or a number of other git-related tools, it is dead
easy to instantaneously view all changes done in Emacs (git keeps an
impressively well-packed copy of the whole repository with the entire
history locally), merge in your own changes and synchronize stuff.

I think the going rate for the Linux kernel is about 50 patches per
hour that get accepted by Linus Torvalds into upstream, so the
toolchain is rather well-suited to this sort of thing.

-- 
David Kastrup

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 12:08 PM, David Kastrup wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>>> To me the rule goes as follows: I only install patches, not files.
>>> That usually takes core of those problems: if the author's version
>>> disagrees with the CVS version I get a conflict when I try to apply
>>> the patch.
>>
>>
>> To me it works like this: My copy is the master copy, not the one in
>> Emacs.  The best setup for me would be to get email notifications,
>> maybe with a patch, whenever some Emacs developer touches my files
>> in Emacs.  Then I can decide if I agree with these changes and
>> incorporate the accepted part into my master copy.
>
> But this does not change that any changes by Emacs developers to the
> copy in Emacs have been put there in the course of Emacs development
> and with the usual amount of peer review for patches.  It is certainly
> your choice to accept those patches (or not) into your master copy.
> However, that does not mean that this decision should result in
> clobbering the changes in the Emacs copy.


Agreed.  However, it is annoying if changes are made without  
consultation.
Sure, I don't care if that happens for Capitalization of the word  
"Copyright".
But replacing, for example `next-line' by `forward-line' in an  
outline-like mode
is a bug, and such changes should be run by the maintainer who knows the
code well.  Things like this have happened to me in the past, again  
recently.
I don't have the time to spend my days on emacs-devel, my energy goes  
into
making org-mode as good as I can.  The version of org-mode that is  
tested the
most is the one I distribute, and the most likely to not have any  
bugs.  That
is the one I am checking into. Emacs.  When I see changes made to org- 
mode
in Emacs I am incorporating them into my master copy if they make  
sense, and
only then.

If I would follow Stefan' advice and only check in diffs, the `next- 
line' code would
be broken now.

> It is never correct to do or undo changes in Emacs without Changelog
> entry and/or CVS log.  And dissent over the desirability of some
> change should not result in "battling commits".

I do agree, I am not battling, I am doing as good as I can and I
I sometimes slip.  But if I am the maintainer of org-mode in Emacs,  
than I and
no one else decides what goes into the mode and what not.  If people  
disagree,
and I will quit maintaining this mode inside Emacs.

> So the right solution can never be just copying over existing files
> without any attempt of merging the changes or explaining why they were
> undone.
>
> My personal recommendation would be to use the git mirror of Emacs'
> CVS.  Using gitk or a number of other git-related tools, it is dead
> easy to instantaneously view all changes done in Emacs (git keeps an
> impressively well-packed copy of the whole repository with the entire
> history locally), merge in your own changes and synchronize stuff.

Yes, if I find a few hours of free time in the next few month, I can  
start toying with
a new versioning system.  But don't hold your breath.

- Carsten

Re: recent changes to org files

[Juanma Barranquero]

On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> But replacing, for example `next-line' by `forward-line' in an
> outline-like mode
> is a bug, and such changes should be run by the maintainer who knows the
> code well.

I think it is safe to assume whomever did that change didn't know it
was a bug... :) Surely he though it was a simple fix for a simple
problem.

> Things like this have happened to me in the past, again
> recently.
> I don't have the time to spend my days on emacs-devel, my energy goes
> into
> making org-mode as good as I can.

There's a difference between spending your days on emacs-devel, and
spending a bit of time tracking changes to Org in the Emacs CVS. I'm
not saying that you should do it (it's your time, not mine), but if
you don't, then don't be surprised if sometimes problems like this one
happen, and don't blame just the committer.

> If I would follow Stefan' advice and only check in diffs, the `next-
> line' code would
> be broken now.

Surely you're not saying that Stefan spoke *against* fixing bugs in
the CVS, are you?

             Juanma

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 1:11 PM, Juanma Barranquero wrote:

>
>> If I would follow Stefan' advice and only check in diffs, the `next-
>> line' code would
>> be broken now.
>
> Surely you're not saying that Stefan spoke *against* fixing bugs in
> the CVS, are you?

No, I am not saying anything like this.

  - Carsten

Re: recent changes to org files

[Juanma Barranquero]

On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> No, I am not saying anything like this.

Then please interpret this for me:

> If I would follow Stefan' advice and only check in diffs,
> the `next-line' code would be broken now.

             Juanma

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 1:44 PM, Juanma Barranquero wrote:

> On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>> No, I am not saying anything like this.
>
> Then please interpret this for me:
>
>> If I would follow Stefan' advice and only check in diffs,
>> the `next-line' code would be broken now.

Stefan said in an earlier message:

> To me the rule goes as follows: I only install patches, not files.
> That usually takes core of those problems: if the author's version  
> disagrees
> with the CVS version I get a conflict when I try to apply the patch.

I was referring to this statement.  It is not enough to install only  
patches,
I also need to actively monitor changes that are made by others.  There
would have been no conflict when checking in a patch with my latest  
modifications.

- Carsten

Re: recent changes to org files

[Juanma Barranquero]

On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> I was referring to this statement.  It is not enough to install only
> patches,
> I also need to actively monitor changes that are made by others.

OK, now I understand. Thanks.

However, someone has to track the changes. Either you track the
changes in the CVS, or whomever intends to fix or change anything in
the CVS must check that his changes don't conflict with your version
(and that makes having Org in the CVS somewhat irrelevant), or the
person goes ahead, does the change and sends it to you (and then, if
your copy varies much faster than the CVS one, conflicts are bound to
happen and effort is wasted).

             Juanma

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 2:06 PM, Juanma Barranquero wrote:

> On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>> I was referring to this statement.  It is not enough to install only
>> patches,
>> I also need to actively monitor changes that are made by others.
>
> OK, now I understand. Thanks.
>
> However, someone has to track the changes. Either you track the
> changes in the CVS, or whomever intends to fix or change anything in
> the CVS must check that his changes don't conflict with your version
> (and that makes having Org in the CVS somewhat irrelevant), or the
> person goes ahead, does the change and sends it to you (and then, if
> your copy varies much faster than the CVS one, conflicts are bound to
> happen and effort is wasted).

Well, I am doing this.  I am checking changes made in the CVS and
incorporate them into my copy.  I never said that I was not doing this.
I don't know how this discussion came to suggest that I am not doing
it.

However, I made a mistake, partly because too many people made a
mistake became involved in the loop and my own versioning system
seems not good enough.  I will work on this, but I do make mistakes.
And: it would be helpful for me if there was a system through which I
could automatically get patches of changes to Emacs CVS versions
of my files.  I don't think it is too much to ask.  Regulars in the  
emacs
development community probably know that, even though org is
very stable and has only had very few bug reports inside Emacs,
I am still making big changes often.  So notification, better a request
for double checking changes to the files from others is, I think,
reasonable to ask for.

- Carsten

Re: recent changes to org files

[Stefan Monnier]

> could automatically get patches of changes to Emacs CVS versions
> of my files.  I don't think it is too much to ask.  Regulars in the  emacs

I agree that it would be very desirable if we could setup the `commitinfo'
script so that it doesn't just send the commits to emacs-diffs but also to
the address in the `maintainer:' field of the file (for elisp files).


        Stefan

Re: recent changes to org files

[David Kastrup]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> I don't have the time to spend my days on emacs-devel, my energy
> goes into making org-mode as good as I can.  The version of org-mode
> that is tested the most is the one I distribute, and the most likely
> to not have any bugs.

That assumes that more people use the org-mode from your web site than
the org mode in Emacs, since using org-mode is a sort of testing.

If that is the case, there is little point in distributing org-mode as
part of Emacs.

But I really doubt it.

> That is the one I am checking into. Emacs.  When I see changes made
> to org-mode in Emacs I am incorporating them into my master copy if
> they make sense, and only then.
>
> If I would follow Stefan' advice and only check in diffs, the `next-
> line' code would be broken now.

If indeed this would be the case (and I don't see that right now), it
would be broken in a documented and isolatable way, and for a reason.
This reason remains to exist.  Overwriting the change without comment
or documentation means that the same reason will possibly result in
the same change being made later on.

If some code is in violation of the Emacs development guidelines, the
reason should be documented so that people _know_ about it and leave
it alone.  Silently reverting the change in a manner that looks like
an accident will not achieve this.

> I do agree, I am not battling, I am doing as good as I can and I I
> sometimes slip.  But if I am the maintainer of org-mode in Emacs,
> than I and no one else decides what goes into the mode and what not.
> If people disagree, and I will quit maintaining this mode inside
> Emacs.

Basically you are asking that nothing, including bug fixes, may be
committed to org-mode except by yourself.  Then there is no point in
having org-mode inside of Emacs' CVS.

Being a maintainer does not mean that nobody else may do work on the
code.  It means that people in general respect you having the last
word.  But it is the last, not the only word.

-- 
David Kastrup

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 1:16 PM, David Kastrup wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> I don't have the time to spend my days on emacs-devel, my energy
>> goes into making org-mode as good as I can.  The version of org-mode
>> that is tested the most is the one I distribute, and the most likely
>> to not have any bugs.
>
> That assumes that more people use the org-mode from your web site than
> the org mode in Emacs, since using org-mode is a sort of testing.

I do believe that many people use Org-mode in Emacs.  But the people  
who use
it heavily and report back fastest tent to be the ones on the  
development list,
and they tend to run the newest version.  Inside Emacs, I guess the  
version that is
distributed with Emacs 22 is heavily tested, the CVS version less  
so?  Not sure.

>
>> That is the one I am checking into. Emacs.  When I see changes made
>> to org-mode in Emacs I am incorporating them into my master copy if
>> they make sense, and only then.
>>
>> If I would follow Stefan' advice and only check in diffs, the `next-
>> line' code would be broken now.
>
> If indeed this would be the case (and I don't see that right now), it

Well, checking in a patch with changes would not lead to a conflict  
in an
area that I have not modified.  So just checking in patches will not
remove a bug that has (clearly by accident) been introduced in one of  
those
clean-up operations where many files are are modified in order to  
implement
a rule like "don't use next-line in lisp programs".  These changes  
typically
affect many files, and it is impossible for the developer who does  
the change
to be sure in all cases that he has done the right thing.  The only  
way to make sure
is to run these changes by the maintainer.  In that past, that has  
happened
sometimes:  I get an email with proposed changes, with the request to  
check
them before they are committed. For example, Stefan has been doing  
things like
this, and I appreciate his comments and additions, and the  way he  
handles it, a lot.

> would be broken in a documented and isolatable way, and for a reason.
> This reason remains to exist.  Overwriting the change without comment
> or documentation means that the same reason will possibly result in
> the same change being made later on.

>
> If some code is in violation of the Emacs development guidelines, the
> reason should be documented so that people _know_ about it and leave
> it alone.  Silently reverting the change in a manner that looks like
> an accident will not achieve this.

Yes.  Of course I only reverted the change "by accident" without an  
accompanying
change log.  Still, I am maintaining that the copy I work on every  
day is the most
reliable one, and that any significant changes should be run by me.

>
>> I do agree, I am not battling, I am doing as good as I can and I I
>> sometimes slip.  But if I am the maintainer of org-mode in Emacs,
>> than I and no one else decides what goes into the mode and what not.
>> If people disagree, and I will quit maintaining this mode inside
>> Emacs.
>
> Basically you are asking that nothing, including bug fixes, may be
> committed to org-mode except by yourself.

No, this is not correct.  I request that I changes are run by me  
first, and that I get
the last word.  Obviously ion 99% of cases, things are fine and the  
will be
only happy agreement.

> Being a maintainer does not mean that nobody else may do work on the
> code.  It means that people in general respect you having the last
> word.  But it is the last, not the only word.

Exactly my words.

- Carsten

Re: recent changes to org files

[Juanma Barranquero]

On 10/23/07, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> I request that changes are run by me first

That's reasonable for deep changes, or ones that could have implications.

Changing next-line to forward-line would *not* be such a kind of
change, were not for the fact that, in this specific case, it was a
mistake. A pretty small one.

We're not talking of someone modifying hundreds of lines of code
behind your back.

             Juanma

Re: recent changes to org files

[Richard Stallman]

    Changing next-line to forward-line would *not* be such a kind of
    change, were not for the fact that, in this specific case, it was a
    mistake. A pretty small one.

Someone was trying to get rid of uses of `next-line' in Emacs Lisp
programs.  He made a mistake in the process, something we all do.

However, changing org-mode along with lots of other programs is not
generally wrong.  When there is a general change in conventions, or a
general maintenance activity like "Let's get rid all those compiler
warnings", it would be ridiculous to ask the maintainer of every
package about some tiny change.  We could not get these general
changes done, if we had to do that.

Re: recent changes to org files

[David Kastrup]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Well, checking in a patch with changes would not lead to a conflict
> in an area that I have not modified.

It will lead to a successful merge.  Nobody said that synchronization
requires no diligence at all.

> So just checking in patches will not remove a bug that has (clearly
> by accident) been introduced in one of those clean-up operations
> where many files are are modified in order to implement a rule like
> "don't use next-line in lisp programs".  These changes typically
> affect many files, and it is impossible for the developer who does
> the change to be sure in all cases that he has done the right thing.

And it is pretty impossible for the developer to figure out
maintainers for every single file, mail them all, keep book of who
replies within what time frame, and then react accordingly.

> The only way to make sure is to run these changes by the maintainer.

And the most reliable way to do this is to check them in, with a
proper log entry.

> In that past, that has happened sometimes: I get an email with
> proposed changes, with the request to check them before they are
> committed. For example, Stefan has been doing things like this, and
> I appreciate his comments and additions, and the way he handles it,
> a lot.

Single-line purported bugfixes are not really additions or comments.

>> If some code is in violation of the Emacs development guidelines,
>> the reason should be documented so that people _know_ about it and
>> leave it alone.  Silently reverting the change in a manner that
>> looks like an accident will not achieve this.
>
> Yes.  Of course I only reverted the change "by accident" without an
> accompanying change log.  Still, I am maintaining that the copy I
> work on every day is the most reliable one, and that any significant
> changes should be run by me.

That means that improvements by several people must not be combined,
and that the results of uncombined changes have to compete on overall
reliability.  I can't see this.  There is no competition going on.
Instead, every contributor strives to improve reliability in the code
he is overseeing.

>> Basically you are asking that nothing, including bug fixes, may be
>> committed to org-mode except by yourself.
>
> No, this is not correct.  I request that I changes are run by me
> first,

Which means that they must not be committed.  So my description _is_
correct.  Whether you yourself do the actual work of committing or
someone does it on your request is a technical detail.  The sum of it
all is that you don't accept anybody else to take responsibility for
committing anything to org-mode.  And that means that there is no
sense in org-mode being maintained inside of Emacs' CVS if no changes
must ever be introduced that don't simultaneously are checked into
your personal CVS.

>> Being a maintainer does not mean that nobody else may do work on
>> the code.  It means that people in general respect you having the
>> last word.  But it is the last, not the only word.
>
> Exactly my words.

Your words don't match your proposed way of working.  Emacs
maintainance quite often means bulk changes: new interfaces and
semantics are introduced, and things like the multitty changes and the
unicode changes necessitate global work (as do added bytecompiler
warnings).  It is not feasible to do the update work only after
figuring out prospective maintainers for every file.  The only hope to
get things like this done is to do the changes and let the maintainers
check for them.  And merge time is certainly an important point of
time for checking it (though regularly checking for diffs in that area
is not amiss either for a maintainer actually interested in his code).

If your workflow does not permit fixes to be applied to Emacs CVS, the
only sane solution short of adjusting your workflow is to remove
org-mode from Emacs CVS.  Only in that manner can it be assured that
bug fixes and interface changes and other things can actually persist.

-- 
David Kastrup

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 1:59 PM, David Kastrup wrote:
> Your words don't match your proposed way of working.  Emacs
> maintainance quite often means bulk changes: new interfaces and
> semantics are introduced, and things like the multitty changes and the
> unicode changes necessitate global work (as do added bytecompiler
> warnings).  It is not feasible to do the update work only after
> figuring out prospective maintainers for every file.  The only hope to
> get things like this done is to do the changes and let the maintainers
> check for them.  And merge time is certainly an important point of
> time for checking it (though regularly checking for diffs in that area
> is not amiss either for a maintainer actually interested in his code).
>
> If your workflow does not permit fixes to be applied to Emacs CVS, the
> only sane solution short of adjusting your workflow is to remove
> org-mode from Emacs CVS.  Only in that manner can it be assured that
> bug fixes and interface changes and other things can actually persist.

Well, don't turn my words in my mouth.  I believe so far I have been  
constructive in
this discussion and so have you.  Let's keep it that way.

-- Carsten

Re: recent changes to org files

[Richard Stallman]

    If your workflow does not permit fixes to be applied to Emacs CVS, the
    only sane solution short of adjusting your workflow is to remove
    org-mode from Emacs CVS.

Please don't suggest this!  To remove org-mode from Emacs CVS would
mean removing it from the Emacs distribution.  We certainly don't want
to do that.  We must have org-mode in Emacs CVS, whether or not that
is the most convenient scheme for org-mode maintenance, just to have
it in Emacs.

Re: recent changes to org files

[Stefan Monnier]

> affect many files, and it is impossible for the developer who does the
> change to be sure in all cases that he has done the right thing.

In the case of "next-line -> forward-line" it is quite possible to be sure:
just think hard about what the function should do in the presence of
invisible text or images, check at which the column the function may
terminate, check if it may be desired to add newlines at EOB, ...

In the case of org-mode the presence of `invisible' in the code is a good
indication that there's a good chance that the change is unsafe.

> that has  happened sometimes:  I get an email with proposed changes, with
> the request to check them before they are committed.  For example, Stefan
> has been doing things like this, and I appreciate his comments and
> additions, and the way he handles it, a lot.

Actually I often can't be bothered to wait, so I install the change and then
send an email about it (I sometimes prefer to undo/refine the change later,
also because installing the `undo' is a good opportunity to add a comment in
the code explaining why it's the way it is).


        Stefan

Re: recent changes to org files

[Carsten Dominik]

On Oct 23, 2007, at 4:43 PM, Stefan Monnier wrote:

>> affect many files, and it is impossible for the developer who does  
>> the
>> change to be sure in all cases that he has done the right thing.
>
> In the case of "next-line -> forward-line" it is quite possible to  
> be sure:
> just think hard about what the function should do in the presence of
> invisible text or images, check at which the column the function may
> terminate, check if it may be desired to add newlines at EOB, ...
>
> In the case of org-mode the presence of `invisible' in the code is  
> a good
> indication that there's a good chance that the change is unsafe.
>
>> that has  happened sometimes:  I get an email with proposed  
>> changes, with
>> the request to check them before they are committed.  For example,  
>> Stefan
>> has been doing things like this, and I appreciate his comments and
>> additions, and the way he handles it, a lot.
>
> Actually I often can't be bothered to wait, so I install the change  
> and then
> send an email about it

Also that helps, thanks.

- Carsten

> (I sometimes prefer to undo/refine the change later,
> also because installing the `undo' is a good opportunity to add a  
> comment in
> the code explaining why it's the way it is).
>
>
>         Stefan

Re: recent changes to org files

[Richard Stallman]

If calling `next-line' is really correct in org-mode, it ought to be
called inside (with-no-warnings ...) to (1) suppress the compiler
warning and (2) show programmers "yes we really mean this, it wasn't a
dumb mistake".

Thus, the code that called `next-line' needed to be fixed one way or another.
If not by changing to `forward-line' then by adding `with-no-warnings'.

At the same time, this shows the need to look more closely at a program
before changing `next-line' to `forward-line'.  That change is only safe
if point is at the beginning of a line.  So you need to check that that is
always so, before making the change.

Re: recent changes to org files

[Carsten Dominik]

On Oct 24, 2007, at 4:50 AM, Richard Stallman wrote:

> If calling `next-line' is really correct in org-mode, it ought to be
> called inside (with-no-warnings ...) to (1) suppress the compiler
> warning and (2) show programmers "yes we really mean this, it wasn't a
> dumb mistake".
>
> Thus, the code that called `next-line' needed to be fixed one way  
> or another.
> If not by changing to `forward-line' then by adding `with-no- 
> warnings'.
>
> At the same time, this shows the need to look more closely at a  
> program
> before changing `next-line' to `forward-line'.  That change is only  
> safe
> if point is at the beginning of a line.  So you need to check that  
> that is
> always so, before making the change.

And you need to check if there is invisible text in the buffer!!!!!

- Carsten

Re: recent changes to org files

[Glenn Morris]

Please can you install a ChangeLog entry for the 2007-10-22 changes to
org-export-latex. Thanks.

Re: recent changes to org files

[John Wiegley]

Glenn Morris <rgm@gnu.org> writes:

> Please can you install a ChangeLog entry for the 2007-10-22 changes to
> org-export-latex. Thanks.

It is installed next to the other 10-22 changes.

John

Re: recent changes to org files

[Carsten Dominik]

Hi Glen,

I am traveling right now, will take care of it early next week when I  
am back.

- Carsten

On  29Oct2007, at 8:30 AM, Glenn Morris wrote:

>
> Please can you install a ChangeLog entry for the 2007-10-22 changes to
> org-export-latex. Thanks.

Re: recent changes to org files

[Miles Bader]

Carsten Dominik <carsten.dominik@gmail.com> writes:
> To me it works like this:  My copy is the master copy, not the one in
> Emacs.  The best setup for me would be to get email notifications,
> maybe with a patch, whenever some Emacs developer touches my files in
> Emacs.  Then I can decide if I agree with these changes and
> incorporate the accepted part into my master copy.

If you maintain an external copy of these files, it's indeed a good idea
to arrange to be notified of changes in Emacs CVS.

However, anybody who commits to Emacs CVS _must_ take care of merging
issues in some way.  That isn't something optional which depends on the
whims of the file's author/maintainer and/or the existance of other
copies of that file.

If you see changes you don't like in Emacs CVS, then of course, those changes
can be reverted -- but that should be an explicit and intentional action, not an
implicit side-effect of being overwritten by some external "master" copy.

-Miles

-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: recent changes to org files

[Miles Bader]

John Wiegley <johnw@newartisans.com> writes:
> Hmm... I'm just installing what the author distributes.

Don't do that.  Always think of committing files as merging changes,
unless you are very sure of the file's history, and have a good reason
to disregard changes made to CVS.

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.