emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: Bastien <bzg@altern.org>
Cc: emacs-orgmode@gnu.org, Jambunathan K <kjambunathan@gmail.com>
Subject: Re: Location of OpenDocument style files should be configurable
Date: Tue, 3 Jan 2012 15:59:20 +0100	[thread overview]
Message-ID: <20227.6088.37039.993600@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <87k459ulx2.fsf@gnu.org>

>>>>> On Tue, 03 Jan 2012, Bastien  wrote:

>>> ps: Makefiles are beyond my jurisdiction. I will let Bastien act
>>> on your patch(es).
>> 
>> Looks like my earlier patch hasn't been applied for 7.8.03. :(

> Yes -- things are not entirely clear to me in this area, and the
> ongoing discussion between you, Achim and Jambunathan feels like
> we need to move carefully.

To summarise as I see the issue:
 - Because arbitrary paths for datadir can be specified at compile
   time, any approach using (only) heuristic searches at run time is
   bound to fail in some configurations.
 - Most other packages using such heuristics provide a way for
   overriding it. The simplest way is just using defvar or defcustom
   (but not a defconst) for the variable definition. (This was my
   original suggestion, which would have been trivial to implement.)
 - However, if the location is known at compile time, there is also no
   need for such searches, because the datadir path can be embedded in
   the lisp code.
 - Preferably, the package should behave the same, regardless if it is
   loaded as elisp sources or as byte-compiled files. Embedding the
   path only in the byte code may be too fragile (in fact, for 7.8.03
   it currently fails with Gentoo's staged installs), and also lead to
   surprising behaviour.
 - Therefore I think the best approach would be either to record such
   paths in org-install.el (as Achim has suggested), or to have the
   Makefile create a new file like org-paths.el for this purpose.

Cheers,
Ulrich

  reply	other threads:[~2012-01-03 14:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-29 11:24 Location of OpenDocument style files should be configurable Ulrich Mueller
2011-12-29 16:06 ` Jambunathan K
2011-12-29 16:56   ` Ulrich Mueller
2011-12-30  9:07   ` Achim Gratz
2011-12-29 16:56 ` Achim Gratz
2011-12-29 18:32   ` Ulrich Mueller
2011-12-30 19:53 ` Jambunathan K
2011-12-31  0:07   ` Ulrich Mueller
2012-01-01 18:35     ` Ulrich Mueller
2012-01-01 20:43       ` Ulrich Mueller
2012-01-02 14:10         ` Jambunathan K
2012-01-03  9:38           ` Ulrich Mueller
2012-01-03 10:20             ` Bastien
2012-01-03 14:59               ` Ulrich Mueller [this message]
2012-01-03 10:26             ` Bastien
2012-01-03 13:59               ` Ulrich Mueller
2012-02-24 11:01             ` Jambunathan K
2012-02-24 11:20               ` Jambunathan K
2012-01-02 22:11   ` Achim Gratz
2012-01-03 10:10     ` Ulrich Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20227.6088.37039.993600@a1i15.kph.uni-mainz.de \
    --to=ulm@gentoo.org \
    --cc=bzg@altern.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=kjambunathan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).