From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bastien Newsgroups: gmane.emacs.devel 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 Message-ID: <87626sxcbd.fsf@bzg.ath.cx> References: <87pq5267ew.fsf@bzg.ath.cx> <87sj9yt6if.fsf@Rainer.invalid> <871uhhxcap.fsf@bzg.ath.cx> <87ehlgbybl.fsf@Rainer.invalid> <874nmc94ki.fsf@bzg.ath.cx> <87626sbxbd.fsf@Rainer.invalid> <87vces7oqs.fsf@bzg.ath.cx> <87lifoagld.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349248123 28278 80.91.229.3 (3 Oct 2012 07:08:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 07:08:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 09:08:48 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TJJ4H-0000dq-Hj for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 09:08:29 +0200 Original-Received: from localhost ([::1]:60971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJJ4B-0000dC-Qd for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 03:08:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJJ48-0000ct-BS for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:08:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJJ44-0008F1-7k for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:08:20 -0400 Original-Received: from mail-wi0-f171.google.com ([209.85.212.171]:45007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJJ43-0008Ex-Nd for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:08:16 -0400 Original-Received: by mail-wi0-f171.google.com with SMTP id hj13so1625001wib.12 for ; Wed, 03 Oct 2012 00:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=IGbxW6lKWuWKnMzzE3oyGqpA30LV18OIyI9QWH7nOHQ=; b=eMCKeh9lcbvEiKfUyYpqZVWBh6ZM6G7bb84Mvql5GUXrgjak46yMzqFEMyWShn51Nz RLuOnOQrfoxx9NE4fvzDVVAv69NWWjb14dP712OjeV6HXZy6dc+gAXH6XBfqrH/S7PNH WLWl0T8SPdEd9D2dBFTw/ejNFCbX9zCTEQEBCB8P68Pn5XBlNqXyVjQ4wpb1SuQ6mWBW i1HwzE3cLGAOaLueOWKGUUFaabxG5+yA6xe4JEkkWPcL1AyZ5Y7rqBOAkA3unbg7TQxV AG8IicBzkrtY3p9Rt6LrQ5rrSWb/S3GuNaq5c/8XNVCDDBgE+uOzFBHAF/Onyw7Y64WO JuhQ== Original-Received: by 10.180.79.34 with SMTP id g2mr2738556wix.19.1349248094823; Wed, 03 Oct 2012 00:08:14 -0700 (PDT) Original-Received: from bzg.localdomain (mar75-2-81-56-68-112.fbx.proxad.net. [81.56.68.112]) by mx.google.com with ESMTPS id w7sm25478975wiz.0.2012.10.03.00.08.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 00:08:13 -0700 (PDT) Original-Received: by bzg.localdomain (Postfix, from userid 1000) id 4029922EDC; Wed, 3 Oct 2012 09:08:22 +0200 (CEST) In-Reply-To: <87lifoagld.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 02 Oct 2012 20:12:14 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.171 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153988 Archived-At: Achim Gratz 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