Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Only trivial comments:


ChangeLog entries that are not applicable (as already mentioned):

+    * org.texi: Include "org-version.inc" instead of
+    "git-describe.texi".
+ 
+   * org.texi: Remove @set for VERSION and DATE and do an @include
+   git-describe.texi instead.

Not relevant since Paul already did it 2012-09-01:

+   * org-id.el: Do not use (random t), we just want a new random
+   number, not a re-seeding of the PRNG for which (random t) doesn't
+   provide enough entropy anyway.  Even if (random) would always
+   produce the same sequence, the other components going into the MD5
+   hash ensure that the result will be unique.


No ChangeLog entries:
=== modified file 'etc/org/OrgOdtContentTemplate.xml'
=== modified file 'etc/org/OrgOdtStyles.xml'
=== modified file 'etc/refcards/orgcard.tex'


It's weird to see this as a constant (rather than something related to
the installation prefix), since it won't be correct for many
installations (but I did not check how it is actually used):

;;;###autoload
(defconst org-odt-data-dir "/usr/share/emacs/etc/org"
  "The location of ODT styles.")


Also, have you considered having a separate org-loaddefs.el, for
autoloads that are not relevant until org.el is loaded?

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> ChangeLog entries that are not applicable (as already mentioned):
>
> +    * org.texi: Include "org-version.inc" instead of
> +    "git-describe.texi".
> + 
> +   * org.texi: Remove @set for VERSION and DATE and do an @include
> +   git-describe.texi instead.

Yep, already done.

> Not relevant since Paul already did it 2012-09-01:
>
> +   * org-id.el: Do not use (random t), we just want a new random
> +   number, not a re-seeding of the PRNG for which (random t) doesn't
> +   provide enough entropy anyway.  Even if (random) would always
> +   produce the same sequence, the other components going into the MD5
> +   hash ensure that the result will be unique.

Deleted, thanks.

> No ChangeLog entries:
> === modified file 'etc/org/OrgOdtContentTemplate.xml'
> === modified file 'etc/org/OrgOdtStyles.xml'
> === modified file 'etc/refcards/orgcard.tex'

I added a ChangeLog entry.

> It's weird to see this as a constant (rather than something related to
> the installation prefix), since it won't be correct for many
> installations (but I did not check how it is actually used):
>
> ;;;###autoload
> (defconst org-odt-data-dir "/usr/share/emacs/etc/org"
>   "The location of ODT styles.")

This is not only weird, this is wrong.  I fixed this in Org,
this will be part of the next bugfix sync with Emacs.

> Also, have you considered having a separate org-loaddefs.el, for
> autoloads that are not relevant until org.el is loaded?

Yes, I can how loaddefs.el could benefit from an org-loaddefs.el.

I see how I can generate a separate org-loaddefs.el (and we do this
already for people who install Org separately, the file is called
org-install.el) but I don't see how I can prevent Emacs from adding
the same autoloaded functions in loaddefs.el.

I've had a look at the way Gnus does this.  

I would expect all entries in gnus-load.el would not be in Emacs
loaddefs.el -- but eg gnus-article-outlook-deuglify-article is.
(Or maybe this is due to my Git Gnus repo not being up to date
enough).

Thanks for any guidance on this!

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Bastien wrote:

> Yes, I can how loaddefs.el could benefit from an org-loaddefs.el.
>
> I see how I can generate a separate org-loaddefs.el (and we do this
> already for people who install Org separately, the file is called
> org-install.el) but I don't see how I can prevent Emacs from adding
> the same autoloaded functions in loaddefs.el.

The simple method is to set a file local value for
generated-autoload-file in org/*.el files (apart from org.el). Eg have a
look at how calc does it.

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Bastien wrote:
>
>> Yes, I can how loaddefs.el could benefit from an org-loaddefs.el.
>>
>> I see how I can generate a separate org-loaddefs.el (and we do this
>> already for people who install Org separately, the file is called
>> org-install.el) but I don't see how I can prevent Emacs from adding
>> the same autoloaded functions in loaddefs.el.
>
> The simple method is to set a file local value for
> generated-autoload-file in org/*.el files (apart from org.el). Eg have a
> look at how calc does it.

I will have a look, thanks for the pointer.

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
>> It's weird to see this as a constant (rather than something related to
>> the installation prefix), since it won't be correct for many
>> installations (but I did not check how it is actually used):

This is a generated file in Org and the path generated is related to the
installation prefix.  Not sure how this should be handled in Emacs.

Reminds me: the file local variable that say "version control: never"
should also be deleted from that file.

>> ;;;###autoload
>> (defconst org-odt-data-dir "/usr/share/emacs/etc/org"
>>   "The location of ODT styles.")
>
> This is not only weird, this is wrong.  I fixed this in Org,
> this will be part of the next bugfix sync with Emacs.

Huh?  How is a defvar any different than a defconst?  The problem is not
the defconst as such.

>> Also, have you considered having a separate org-loaddefs.el, for
>> autoloads that are not relevant until org.el is loaded?
>
> Yes, I can how loaddefs.el could benefit from an org-loaddefs.el.
>
> I see how I can generate a separate org-loaddefs.el (and we do this
> already for people who install Org separately, the file is called
> org-install.el) but I don't see how I can prevent Emacs from adding
> the same autoloaded functions in loaddefs.el.

You change all autoload cookies to some different value like
autoload-org.  Then you generate org-loaddefs.el using that cookie and
when loaddefs.el is generated using the original cookie it comes up
empty.  The real work there is to decide, for each autoload, whether it
belongs into org-loaddefs.el or loaddefs.el.  This is decidedly not the
same thing that org-install.el does.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Achim Gratz wrote:

> You change all autoload cookies to some different value like
> autoload-org.  Then you generate org-loaddefs.el using that cookie and
> when loaddefs.el is generated using the original cookie it comes up
> empty.  The real work there is to decide, for each autoload, whether it
> belongs into org-loaddefs.el or loaddefs.el. 

That is the more complex method, yes, which you need if a given file
needs both kinds of autoloads (ones that belong in org-loaddefs and also
ones that belong in loaddefs). Hopefully the simpler
generated-autoload-file method suffices. It depends how many entry
points Org needs beyond the obvious "org-mode"...

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Glenn Morris writes:
> That is the more complex method, yes, which you need if a given file
> needs both kinds of autoloads (ones that belong in org-loaddefs and also
> ones that belong in loaddefs). Hopefully the simpler
> generated-autoload-file method suffices. It depends how many entry
> points Org needs beyond the obvious "org-mode"...

My current view is that this is something that should be evaluated for
the next major Org release.  I have been thinking about an org-loaddefs
when reworking the build system for Org, but I decided that it would be
a change too many at that time.  The simpler method of converting all
autoloads should indeed work, but that would not be different from the
org-install.el the standalone Org already has, so I would not want to
change the name to org-loaddefs.el if possible (or change it for
standalone Org also if necessary).

Also Stefan said that he thinks of moving Org and other large packages
to ELPA anyway, so that would also be another consideration to make.
The package manager would need a few additions IMHO before this can
happen, so I would welcome if this could be discussed after the release
of 24.3 (or even right now if you prefer).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
>> ;;;###autoload
>> (defconst org-odt-data-dir "/usr/share/emacs/etc/org"
>>   "The location of ODT styles.")
>
> This is not only weird, this is wrong.  I fixed this in Org,
> this will be part of the next bugfix sync with Emacs.

I've had another look.  Please simply remove that definition completely
from the org-version.el in Emacs.  The search heuristics should then
find the styles installed with Emacs.  For standalone Org, please leave
the defconst — this is correct there, since the content is generated.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Oh sure, I absolutely did not mean this to be something for 24.3. It was
just something that occurred to me...

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Jambunathan K]

> It's weird to see this as a constant (rather than something related to
> the installation prefix), since it won't be correct for many
> installations (but I did not check how it is actually used):
>
> ;;;###autoload
> (defconst org-odt-data-dir "/usr/share/emacs/etc/org"
>   "The location of ODT styles.")

In vanilla Emacs, org-odt-data-dir should be nil.

,----
| (defvar org-odt-data-dir nil
|   "Data directory for ODT exporter.
| Use this to infer values of `org-odt-styles-dir' and
| `org-export-odt-schema-dir'.")
`----

The style files will be picked from the 'system' (see below).

,----
| (defconst org-odt-styles-dir-list
|   (list
|    (and org-odt-data-dir
| 	(expand-file-name "./styles/" org-odt-data-dir)) ; bail out
|    (eval-when-compile
|      (and (boundp 'org-odt-data-dir) org-odt-data-dir ; see make install
| 	  (expand-file-name "./styles/" org-odt-data-dir)))
|    (expand-file-name "../etc/styles/" org-odt-lib-dir) ; git
|    (expand-file-name "./etc/styles/" org-odt-lib-dir)  ; elpa
|    (expand-file-name "./org/" data-directory)	       ; system
|    )
|   "List of directories to search for OpenDocument styles files.
| See `org-odt-styles-dir'.  The entries in this list are populated
| heuristically based on the values of `org-odt-lib-dir' and
| `org-odt-data-dir'.")
`----

ps-1: Recent changes to Make targets in Org repo touches
`org-odt-data-dir'.  I have not reviewed these changes closely.

ps-2: I have taken deliberate decision to stay out of Org-mode
development and the mailing list.  Any bugs in the ODT exporter in
vanilla Emacs will be promptly addressed (as long as it comes via
debbugs or other Emacs mailing lists)
-- 

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> I've had another look.  Please simply remove that definition completely
> from the org-version.el in Emacs.  The search heuristics should then
> find the styles installed with Emacs.  For standalone Org, please leave
> the defconst — this is correct there, since the content is generated.

Well, I've had a close look at what does org-odt-data-dir and I simply
removed it.

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Hi Glenn,

Glenn Morris <rgm@gnu.org> writes:

> Oh sure, I absolutely did not mean this to be something for 24.3. It was
> just something that occurred to me...

I reworked autoloads in Org by following the Calc way.
The loaddefs.el in Emacs will be far less cluttered now.

This will be in Org 7.9.3 and I'll merge this before Emacs 24.3.

Thanks again for the directions,

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> ps-2: I have taken deliberate decision to stay out of Org-mode
> development and the mailing list.  Any bugs in the ODT exporter in
> vanilla Emacs will be promptly addressed (as long as it comes via
> debbugs or other Emacs mailing lists)

I regret this decision.

I've removed your public key from the orgmode.org server.

If you want to contribute again directly to the org-mode.git
repository let me know, I will give you push access again,
your help will always be welcome.

Thanks for your great contributing so far!

Best,

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
>> I've had another look.  Please simply remove that definition completely
>> from the org-version.el in Emacs.  The search heuristics should then
>> find the styles installed with Emacs.  For standalone Org, please leave
>> the defconst — this is correct there, since the content is generated.
>
> Well, I've had a close look at what does org-odt-data-dir and I simply
> removed it.

You've removed functionality that some systems (mine for instance)
relied on.  Since there is no replacement, you effectively broke Org.
Worse, you did all that on the maint branch which has the promise that
there are exactly no non-bugfixes between releases.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
> I reworked autoloads in Org by following the Calc way.

I specifically referred you to the more complicated way because
building Org let-binds some variables that you now use as file-local
variables.  The result may be the same (I really don't know), but that's
another breakage.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>>> I've had another look.  Please simply remove that definition completely
>>> from the org-version.el in Emacs.  The search heuristics should then
>>> find the styles installed with Emacs.  For standalone Org, please leave
>>> the defconst — this is correct there, since the content is generated.
>>
>> Well, I've had a close look at what does org-odt-data-dir and I simply
>> removed it.
>
> You've removed functionality that some systems (mine for instance)
> relied on.  Since there is no replacement, you effectively broke Org.
> Worse, you did all that on the maint branch which has the promise that
> there are exactly no non-bugfixes between releases.

Can you tell me how I broke your system so that I can help fixing it?

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> I specifically referred you to the more complicated way because
> building Org let-binds some variables that you now use as file-local
> variables.  The result may be the same (I really don't know), but that's
> another breakage.

What is the breakage exactly?

Can I reproduce it?

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
>> You've removed functionality that some systems (mine for instance)
>> relied on.  Since there is no replacement, you effectively broke Org.
>> Worse, you did all that on the maint branch which has the promise that
>> there are exactly no non-bugfixes between releases.
>
> Can you tell me how I broke your system so that I can help fixing it?

All XML schema files reside in their own hierarchy.  The heuristics
won't find them and you've removed the only means to skip that useless
search and tell the installation exactly where they are.

Furthermore, searches into ../something can very well lead to much more
fun than you seem to be aware of.  They could try to search the whole
network for instance.  Slow network drives in conjunction with stupid
virus scanner (i.e. almost all corporate environments) have noticeably
degraded performce even when the search stays within the same filesystem
and finds the files it is looking for.

You've not made anything simpler there, really.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> I specifically referred you to the more complicated way because
>> building Org let-binds some variables that you now use as file-local
>> variables.  The result may be the same (I really don't know), but that's
>> another breakage.
>
> What is the breakage exactly?

…
Generating autoloads for ob-js.el...done
Making generated-autoload-file local to  *autoload-file* while let-bound!
Generating autoloads for ob-keys.el...
…

> Can I reproduce it?

Certainly.  But it is clear that this will happen without even trying.
As long as the two values are the same probably nothing bad happens (I
really hope), but that was the reason I'd have preferred to change the
autoload cookie.  I still think that's the only clean solution.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Achim Gratz wrote:

> Generating autoloads for ob-js.el...done
> Making generated-autoload-file local to  *autoload-file* while let-bound!
> Generating autoloads for ob-keys.el...

I don't believe that message is Org-specific, or in itself anything to
worry about.

http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg01184.html

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Hi Achim,

I still don't know what used to work for you and what does not
work anymore.

Among the things that I'm not aware of (there are plenty of them!)
there are those that I can't guess until I'm told :)

Please let me know how we can fix things for you.

Thanks,

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Glenn Morris writes:
> Achim Gratz wrote:
>
>> Generating autoloads for ob-js.el...done
>> Making generated-autoload-file local to  *autoload-file* while let-bound!
>> Generating autoloads for ob-keys.el...
>
> I don't believe that message is Org-specific, or in itself anything to
> worry about.

If there was nothing to worry about, then that message should not be printed.

> http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg01184.html

Well, this doesn't say that there is nothing to worry about, only that
the probability of finding something wrong is small.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Achim Gratz wrote:

> If there was nothing to worry about, then that message should not be printed.

If there was something to worry about, we would not use that method for
generating Emacs autoloads. Since we have for years with no problems...
it's fine for Org to do the same.

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
> I still don't know what used to work for you and what does not
> work anymore.

When the variable org-odt-datadir was set, no heuristics were used to
find the style and schema files.  This variable was set by the build
system and thus tracked the installation (or rather many of them, since
I have multiple installations that I need to keep seperate).  For this
very reason it was also the right thing to use a defconst rather than a
defvar.

The heuristics you've put in place now don't work if the user wants to
install schema files (which are not delivered with Emacs), but the Emacs
installation is not writeable by the user.  This used to work simply by
configuring that variable in the init file.

> Please let me know how we can fix things for you.

Don't delete configuration variables that belong to the user; or rather,
bring them back in this case.

> Among the things that I'm not aware of (there are plenty of them!)
> there are those that I can't guess until I'm told :)

Let's not go there.  But please ask if you intend to remove user
configuration because the world is a bit larger than just your laptop
computer.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Glenn Morris writes:
>> If there was nothing to worry about, then that message should not be printed.
>
> If there was something to worry about, we would not use that method for
> generating Emacs autoloads. Since we have for years with no problems...
> it's fine for Org to do the same.

Again, if that's the case there should be no warning printed.  Should I
open a bug report or feature request to suppress the warning if both the
let-bind and the local variable point to the same file?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Glenn Morris]

Achim Gratz wrote:

> Again, if that's the case there should be no warning printed.  Should I
> open a bug report or feature request to suppress the warning if both the
> let-bind and the local variable point to the same file?

I wouldn't bother. A warning sometimes just means "this code use can be
problematic, maybe you want to check it", not "this code use is
definitely wrong, you should change it".

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> I still don't know what used to work for you and what does not
>> work anymore.
>
> When the variable org-odt-datadir was set, no heuristics were used to
> find the style and schema files.  This variable was set by the build
> system and thus tracked the installation (or rather many of them, since
> I have multiple installations that I need to keep seperate).  For this
> very reason it was also the right thing to use a defconst rather than a
> defvar.

This is how the previous situation looked like:

1. even when org-odt.el was not loaded, users had a org-odt-data-dir
   variable pointing to "/usr/share/emacs/etc/org", and this was set in
   org-version.el, created by make or included in Emacs or Org.

   org-odt-data-dir was not an option, just an internal variable,
   accessible directly as a defvar or through the make system with
   "datadir".

   The docstring of org-odt-data-dir said that this variable was used to
   infer values of org-odt-styles-dir and org-export-odt-schema-dir.  If
   a user installs Org from git and check the value of org-odt-data-dir,
   she will think styles and schema will be searched in
   "/usr/share/emacs/etc/org", which is wrong.

2. org-export-odt-schema-dir was a defcustom, which default value was
   set through org-odt-schema-dir-list (a defconst), which was in turn
   set by checking org-odt-data-dir.

3. org-odt-styles-dir was a defconst, set by checking against
   org-odt-styles-dir-list (another defconst) which was set by checking
   against org-odt-data-dir.

4. org-export-odt-styles-file was a defcustom, taking its default value
   from org-odt-styles-dir, set through org-odt-styles-dir-list, set
   through org-odt-data-dir.

The two defcustoms above are what the users are exposed to:
org-export-odt-schema-dir org-export-odt-styles-file are untouched.

But I got rid of the -dir-list steps, which let me get rid of the
org-odt-data-dir org-odt-data-lib variables, which I found confusing.

> The heuristics you've put in place now don't work if the user wants to
> install schema files (which are not delivered with Emacs), but the Emacs
> installation is not writeable by the user.  

Just customize org-export-odt-schema-dir.

> This used to work simply by configuring that variable in the init
> file.

I think configuring a defcustom is more natural than configuring a
Makefile variable that is a defvar when you install things from Org 
and a defconst when you get Org from Emacs, which is the solution
you suggested. 

>> Please let me know how we can fix things for you.
>
> Don't delete configuration variables that belong to the user; or rather,
> bring them back in this case.

I deleted no defcustom.  Did I?

As for confusing internal vars, I always feel better when I delete them.

>> Among the things that I'm not aware of (there are plenty of them!)
>> there are those that I can't guess until I'm told :)
>
> Let's not go there.

Please let's go there: let me know wwat you could do wrt to ODT
exporting that you cannot anymore with latest Org.  A concrete example.
If I broke something, I'll happily fix it.

> But please ask if you intend to remove user
> configuration because the world is a bit larger than just your laptop
> computer.

Indeed.  The world is so large that there is no need to insult people 
because of such tiny details.

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Bastien writes:
> This is how the previous situation looked like:
>
> 1. even when org-odt.el was not loaded, users had a org-odt-data-dir
>    variable pointing to "/usr/share/emacs/etc/org", and this was set in
>    org-version.el, created by make or included in Emacs or Org.

Emacs didn't have that before the merge and was relying on heuristics.
I did say that it can very well continue to do so since the layout of
files within the Emacs installation conforms to the expectation of the
heuristics.

>    org-odt-data-dir was not an option, just an internal variable,
>    accessible directly as a defvar or through the make system with
>    "datadir".

This variable was set be the build system and the user had precise
control over where to point it.  More importantly, the build system made
sure that the files actually were accessible at that place after
installation.

Now, this is not a discussion for Emacs because it uses a different
build system, but for sake of completeness: if a user configures a
non-standard place for those files right now, they will be happily
installed there, but Emacs won't find them because you've removed the
connection between the installation and those files through Emacs.
You've also deleted a variable that make uses to install those files
from the default template, so those files will now be installed entirely
in the wrong place when the stock defaults are used.

> The two defcustoms above are what the users are exposed to:
> org-export-odt-schema-dir org-export-odt-styles-file are untouched.

But you've removed the default value for the installation.  I've not
customized these variables because I have many installations, all
pointing to different files.  Since the actual values used by Emacs were
relying on the default value that was working until you've removed the
default haphazardly.

> But I got rid of the -dir-list steps, which let me get rid of the
> org-odt-data-dir org-odt-data-lib variables, which I found confusing.

Yes, you didn't understand why they were there.  Maybe this can be
implemented in a different way.  But there was nothing broken in this
area before your change, but it is broken just now.

>> Don't delete configuration variables that belong to the user; or rather,
>> bring them back in this case.
>
> I deleted no defcustom.  Did I?

You've deleted a configuration variable for the build system that was
used to describe how the user wanted to set his system up.  You didn't
actually care to check that everything else is still working.  Don't try
to distract from that fact by pointing at some other configuration
option that has nothing to do with that.

> Please let's go there: let me know wwat you could do wrt to ODT
> exporting that you cannot anymore with latest Org.  A concrete example.
> If I broke something, I'll happily fix it.

If you really must know what's broken, please do a fresh clone of Org
and then issue (as root)

make clean-install

It is sheer luck that on most systems this will not remove vital files.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Bastien]

I see now what was wrong and I reverted the bad commits in Org.

What is still wrong is the tone you use when reporting these 
problems, which just makes me want to stop maintaining Org.

I don't know how this could be fixed, but this bugs me a lot.

-- 
 Bastien

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Glenn Morris writes:
> I wouldn't bother. A warning sometimes just means "this code use can be
> problematic, maybe you want to check it", not "this code use is
> definitely wrong, you should change it".

Well, I couldn't help bothering… :-)

The let-binding that triggers the message is actually established in
autoloads.el in generate-file-autoloads, which then goes on to call
autoload-generate-file-autoloads, which actually expects a buffer local
variable.  Apparently the let-binding "wins" in that situation and the
buffer-local variable is ignored, which is probably why the warning is
printed (even though the two values are the same)?

I can fix this by calling autoload-generate-file-autoloads directly,
setting the default value for generated-autoload-file instead of doing a
let-bind.  This works without printing any warnings, but fails when any
of the files tries to set a buffer-local variable with a different value
for generated-autoload-file: the file is produced, but does not collect
any autoload definitions.  It actually blows up in that case unless I
provide a let-bind for autoload-modified-buffers (like in
update-directory-autoloads, where I gleaned this from and which also
let-binds generated-autoload-file and thus produces the same warning).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Stefan Monnier]

> The let-binding that triggers the message is actually established in
> autoloads.el in generate-file-autoloads, which then goes on to call
> autoload-generate-file-autoloads, which actually expects a buffer local
> variable.

Actually, there are several functions that do the let-binding, and
generate-file-autoloads is the least problematic because it's almost
never used.
But, yes, we have a problem in that area in autoload.el.
It would be good for someone to sit down and try and figure out how to
clean it up.


        Stefan

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz]

Stefan Monnier writes:
> But, yes, we have a problem in that area in autoload.el.

Good to know that I'm not chasing ghosts…

> It would be good for someone to sit down and try and figure out how to
> clean it up.

I'd give it a shot, but this is all very delicately intertwined and it
appears that the documentation and the comments to gether either don't
tell the full story or are outdated in several places.  Does anybody
have better information on what the "public interfaces" of that code are
and what are the assumptions that a cleanup needs to keep?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Stefan Monnier]

> I'd give it a shot, but this is all very delicately intertwined and it
> appears that the documentation and the comments to gether either don't
> tell the full story or are outdated in several places.

I know, I spent a fair amount of time in that code a few years ago to
eliminate an O(N^2) behavior and then later to add the support for
file-local settings of generated-autoload-file.

> Does anybody have better information on what the "public interfaces"
> of that code are and what are the assumptions that a cleanup needs
> to keep?

IIRC there are fairly few entry points:
update-directory-autoloads, update-file-autoloads, and
batch-update-autoloads.

Not sure about generate-file-autoloads which is either dead, or a very
rarely used entry point.

BTW, if/when considering how to fix it, it might be worth considering at
the same time how to improve it so as to support ';;;###foo-autoload'
directly (without having to scan the file twice, for example).
Probably by looking for ";;;###\\(.*-\\)?autoload" and using an alist
that maps from foo to the corresponding file.


        Stefan