From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz 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:48:40 +0200 Organization: Linux Private Site Message-ID: <87obkkhu7b.fsf@Rainer.invalid> 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> <87626sxcbd.fsf@bzg.ath.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349252308 28902 80.91.229.3 (3 Oct 2012 08:18:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 08:18:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 10:18:33 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 1TJK9N-0005lV-Rj for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 10:17:50 +0200 Original-Received: from localhost ([::1]:58749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJK9I-0002li-9J for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 04:17:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJJi6-0001js-TX for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:49:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJJi5-0005Md-B0 for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:49:38 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:58121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJJi5-0005MN-3J for emacs-devel@gnu.org; Wed, 03 Oct 2012 03:49:37 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TJJhu-0003Mc-Vu for emacs-devel@gnu.org; Wed, 03 Oct 2012 09:49:27 +0200 Original-Received: from pd9eb581d.dip.t-dialin.net ([217.235.88.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2012 09:49:26 +0200 Original-Received: from Stromeko by pd9eb581d.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2012 09:49:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 76 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb581d.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:vtmvVUfDvbXrvyOPu3WiIPv5UVI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:153991 Archived-At: 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