emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged


From: Bastien
Subject: Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.
Date: Wed, 03 Oct 2012 09:08:22 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux)

Achim Gratz <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]