Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Load literate user settings #693

Closed
wants to merge 3 commits into from

6 participants

@jleechpe

This provides support for literate (.org) files to be used for package specific customizations via el-get-user-package-directory.

I based it in part off of #539 and off of the method used by Eric Schulte in Emacs 24 starter kit.

It provides customizable variables for supported file extensions as well as a fairly simple way of adding other loadable file-types that might currently or one day exist (a new variable and a single line in the or statement is needed for each additional type).

It does not check to ensure that only one file will match and be loaded. This is impossible because org-babel-load-file creates a .el file with the same name. Since this new file is not compiled by babel I also removed compilation of .el files so that they will all be loaded the same way. Changing this would require adding a function that compiles then loads the file, and setting plain-type-load to that function.

The (catch ... (throw ...)) loop ensures that only the first matching extension will be used, the custom variables used for file extensions are in the order they will be checked and give priority first to encrypted, then to compressed formats.

@DarwinAwardWinner
Collaborator

Is there any possible bootstrapping issue here? If the user installs org-mode via el-get and then uses .org files for their customizations, then they would have to load org-mode first before any of the packages for which they have .org files as customizations, correct? What if the user has a .org files for org-mode?

@jleechpe

In Emacs24 there should be no issues at all. The version of Org that is bundled with Emacs24 is recent enough to provide org-babel-load-file by default so nothing runs the risk of failing.

Emacs23 does need a bit more care.

Org would have to be the first package loaded (or at least before any using .org customizations) to ensure that the features are available (since the autoloads are only included via (require 'org-install)).

Reading through el-get-init there is one other situation that could lead to bootstrapping issues (possibly). Features are loaded before el-get-load-package-user-init-file unless el-get is lazy. If el-get is not lazy all the features will be available before the customization file is loaded and it should be fine. If el-get is lazy el-get-load-package-user-init-file gets evaluated under eval-after-load so as long as the first package to be manually loaded is org-install I don't think there should be any issues.

So as long as org-mode is the first package loaded by el-get in Emacs23, or the first manually loaded when el-get-is-lazy is non-nil, there should be no bootstrapping issues.

@DarwinAwardWinner
Collaborator

Even in lazy mode, el-get still sets up autoloads for packages, so as long as org-mode provides an autoload for org-babel-load-file the value of el-get-is-lazy should be irrelevant. If it doesn't provide such an autoload, we can manually add it to the recipe to fix that.

One possible way to mitigate this is to modify el-get-dependencies to add org-mode to a package's dependency list if that package has a .org config file. That should cover any package except org-mode itself. This is kind of hacky though, since we are hard-coding the package name of org-mode. But it should work.

What about the case when the user's org-mode package config is a .org file? I guess it should still work since the config file is loaded after the package itself (or its autoloads if lazy).

@jleechpe

For Org itself there won't be an issue for that reason. The features will be loaded before the config file is (either because :feature (require 'org-install) was evaluated or the config file will be in (eval-after-load 'org-install <config file>)

Org provides it's own autoload file (org-install.el) so it loads as a feature rather than as autoloads (:autoloads nil in the recipe). However manually adding org-babel-load-file as an autoload to the recipe would allow it to be loaded (and through it a fair bit of Org I suspect) and thereby allow any .org configuration files to load. I would still probably recommend loading Org first in the list of packages just to be certain on Emacs23.

@DarwinAwardWinner
Collaborator

Regarding loading org-mode first, that's why I suggested that any package with a .org config file could automatically have org-mode added to its dependencies. Do you think that would be sufficient? The one problem that arises then is the possibility of this automated dependency-adding introducing circular dependencies.

@jleechpe

If we want to ensure there aren't potential issues I could change org-type-load to be an additional flet (or independent function that essentially would be written as (I have to test it to ensure it won't cause any errors before committing, and SSH is blocked where I am currently):

(org-type-load (init-file)
               (eval-after-load "org-install" (org-babel-load-file init-file)))

This should lead to a similar effect as automatically adding dependencies, without the risk of circular dependencies.

If I did implement it as an additional function, I would likely do the same for plain-load-type and provide a custom variable to allow users to decide if they want to compile their configuration file or not (I'd default it to 'nil just to keep it matching the .org files).

This would actually provide a bit more flexibility, I should be able to get this written up this weekend assuming everything goes as expected.

@DarwinAwardWinner
Collaborator

By the way, could you give me a minimal .org config file that I can use for testing? Just the required headers and a block of elisp that sets a variable (whose value I can test later to see if the config was loaded).

@jleechpe

The following is what I'm using currently to test my implementation (I just have to test it in emacs23 to ensure it is behaving as expected and then I'll push to update the commits here).

* Initialization test
Test to ensure that the file has loaded
#+name: org-mode-test-init
#+begin_src emacs-lisp
  (setq test:el-get-org-mode-config "Success")
  (el-get-notify "Org Mode Config" "file loaded")
#+end_src

It sets the variable test:el-get-org-mode-config while also providing a popup message when loading. I had a couple other I used for other packages, changing the package name (org-mode) and notification title to fit the package that was loaded.

@DarwinAwardWinner
Collaborator

Ok, thanks. I'll convert that into a test when I get the chance. Or you can take a shot at doing it yourself if you're interested. See test/README.asciidoc, and see the various el-get-issue-*.el tests for examples. You can add the test as el-get-issue-693.el. I suggest you don't use an actual package in testing, but rather create a trivial "no-op" package like (:name test-pkg :type builtin) and create a .org config file for that. This way you won't be hammering anyone's server just to repeatedly install the same package for testing.

@jleechpe

I didn't try to write any test yet, I was more interested in ensuring that the code change that would prevent bootstrapping was properly written to and would work for both Emacs23 and Emacs24. I preferred to test it manually for the moment to be able to specify when org was loaded and thereby insure the code behaves as expected in cases where org-babel-load-file is not available.

I did not end up adding in an option to compile el init files because I was not entirely sure how to approach it in this case while ensuring there would not be potential issues later, or changing the format of the functions that are passed. Archived (.el.gz), strip both extensions off the filename, while filename-sans-extension will only strip off the first. If someone has a suggestion on how to handle this elegantly (and without risk of a recipe with a . in the filename being trimmed too far), I'd gladly incorporate it into the pull request, or it can be added in later on.

Since Org is bundled with Emacs24, I could not simply rely on (eval-after-load 'org-install ...) since that feature is never loaded on startup. Instead I have the function first try with ignore-errors, loading the init-file if able, otherwise it wraps it in eval-after-load 'org-install and waits for the feature to come available. Since (el-get-init 'org-mode) has :features org-install there is no issue with the configuration files being loaded once it becomes available.

I tested this in Emacs23 by running:

(el-get-init 'color-theme) ;; this has a .org init file
(el-get-init 'org-mode)  ;; this does as well

and then ensuring that the configuration files were loaded at the right time by watching for the el-get-notify message in the configuration file.

The only case that might lead to a failure to load the configuration files is if the user is tracking org independently of el-get. If this is the case they have to either (require 'org) before el-get init's the configuration files, or ensure they load it by using (require 'org-install). Otherwise the files will never be loaded, although they should not cause errors in and of themselves (only later calls to things defined in configuration files might cause an issue).

@DarwinAwardWinner
Collaborator

You can use (eval-after-load "org-install" ...) (note the string instead of the symbol) to run some code if "org-install" has already been loaded without having to do any error-catching. Also, the correct way to do try/catch semantics in Elisp is with condition-case.

Alternatively, if your code has already determined that it needs to load a .org config, and you can be sure that org-install is available, then there's no harm in doing (require 'org-install), since you're going to need it anyway. This would save you from having to do the eval-after-load at all.

Obviously if the user is tracking Org outside of el-get, then they are on their own, so there's not much point in worrying about that.

@DarwinAwardWinner
Collaborator

One thing that would be nice is a warning if el-get finishes initializing and some org config files were found, but org-mode still isn't loaded. This warning would instruct the user to load org-mode to activate those config files.

@jleechpe

Using (eval-after-load "org-install" ...) as opposed to (eval-after-load 'org-install ...) in this case would make no difference from what I can see. The version of Org bundled with Emacs24 doesn't use org-install as far as I can tell since neither form is evaluated when loading from the bundled version or with (org-reload) to grab a more up-to-date copy in the load path. This is why I needed some form of error-catching, Emacs24 won't match on the feature/library, but it will autoload the function.

Is there any advantage to using

(condition-case nil
    (org-babel-load-file package)
  (error (eval-after-load 'org-install `(org-babel-load-file ,package)))) ;; or should it be void-function instead of error?

compared to what I used:

(or (ignore-errors (org-babel-load-file package))
    (eval-after-load 'org-install `(org-babel-load-file ,package)))

I can easily change it to the former, I'd forgotten about condition-case and used or since it gave the desired result in this case.

There is no guarantee that org-install will be available at that point in time when loading a user's customization file since el-get only adds packages to the load path at init. The only way this would work would be by ensuring Org is added to the load path before el-get-init is ever called for a package with a .org customization file.

I agree there's no reason to worry about users tracking Org outside of el-get, however at the very least the implementation won't cause errors on el-get's side.

Adding a warning that way could solve that last issue as well. Is there a hook that runs after all initializations are completed where this could be tied in? Or would that simply be a check that should be made at the end of (el-get) either before or after calling (el-get-eval-autoloads)? I'd have to think about where that check could be performed and how to ensure it is done properly, but there's probably some way to include that.

@DarwinAwardWinner
Collaborator

I guess you can use (functionp 'org-babel-load-file) to detect whether org-mode loading is available now? Or use (find-library-name "ob-tangle"), which will throw an error if the required library is not available for loading?

@DarwinAwardWinner
Collaborator

I've successfully written a basic test case for this. I'll extend it to some of the pathological cases we've been discussing in this thread, and that I'll make any necessary fixes and merge it when I get the time.

@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@jleechpe

I think the easiest way to add a message if there are org-configs that are still not-loaded (because org is not yet loaded) would be to add another variable that gets set to t when org-configurations are available, and add a function to check for that variable to the end of el-get, which will prompt the user to load org if org-babel-load-file is still unavailable.

Other than that I think the code accounts for all of the cases we've discussed, I'll implement the messaging function, switch to condition-case and then double check all the possible cases to make sure I haven't missed any.

@DarwinAwardWinner
Collaborator

Ok, that all sounds good. I think this is getting close to being ready to merge.

@jleechpe

I've commited the changes locally and listed below the issues I tested and/or accounted for. I'll push the changes this afternoon when I'm at home and not being a network where ssh is blocked.

I used el-get-notify to warn the user when the .org* init files were not yet loaded and have the check being performed in el-get just before the closing bracket for the let*. I wasn't sure if it should go there or inside the prog1 section, but that can always be changed when merging.


Emacs 23

Org is not available by default in Emacs23, this can cause loading issues.

DONE Bootstrapping [4/4]

Solution
If org-babel-load-file is not available, wrap it in eval after load

(eval-after-load 'org-install \`(org-babel-load-file ,package))
  1. Org is tracked by el-get but is not loaded first
    FIXED by eval-after-load

  2. Org has a .org init file
    Not an issue, init files are loaded after the package is loaded or set to autoload. Functions are available in time.

  3. El-get-is-lazy is set to 't, so org-install is not loaded by el-get-init
    This is a non-issue as well. Init files are wrapped in eval-after-load so they will not be loaded until the package is required. This then becomes issue 1.

  4. Org is not being tracked by el-get
    Because of eval-after-load this is not an issue. The file will simply wait for org-install.

TODO Org init-file not loaded [1/3]

Using eval-after-load can lead to a situation where initialization completes successfully but the init file is never actually loaded. Issues 3 and 4 above can both lead to this situation.

Solution
A variable is used to check if an init file is wrapped in eval-after-load. If there is and org-install is not yet available, it notifies the user using el-get-notify that not all init files are loaded, and that (require 'org-install) will complete the installation.

  1. El-get is lazy is set to 't. Init files are not loaded since org-install is never loaded. (Continuing from 3 above)
    No warning is given in this case that the init files are not loaded. Since there is no attempt to load the init file at the point where the check is performed the variable is not set. Running (el-get 'sync) a second time after requiring the package will warn that the init file is not loaded yet. Short of checking at the time of loading every .org* user init file I could not see how to account for this case.

  2. Org is not being tracked so the init file is waiting in eval-after-load. (Continuing from 4 above)
    FIXED The package check and warning alert the user to this case, it is then up to them to load org-install to complete initialization.

  3. User loads packages using el-get-init instead of (el-get).
    I did not implement any check in this situation. Checking in this instance would need to be on a package by package basis, similarly to when el-get-is-lazy.

Emacs 24

None. org-babel-load-file is available within the default installation.

@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@DarwinAwardWinner
Collaborator

@dimitri, any objections to merging this? Note that I have written some tests for it in my own repo: https://github.com/DarwinAwardWinner/el-get/commits/literate-user-settings

It passes the tests in both emacs 23 and 24. The tests cover usage with el-get-is-lazy set to t.

@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit in DarwinAwardWinner/el-get
@DarwinAwardWinner DarwinAwardWinner Add test for #693 223c5a2
@DarwinAwardWinner DarwinAwardWinner referenced this pull request from a commit in DarwinAwardWinner/el-get
@DarwinAwardWinner DarwinAwardWinner Make test #693 pass in Emacs 23
The test only passes if org-mode is available, so for emacs 23 we just
install org mode. More work is needed to test some pathological cases.
7711a59
@dimitri
Owner

It looks mostly good, I wonder what is that package-load function though, and would simplify a lot the flet/loop/throw etc business by using loop facility some more, but that can indeed be done as an after commit cleanup work. If you're backing that and saying it now works as intended, then the only objection I can make is that it's a user visible improvement lacking documentation.

Thanks for the work guys, let's have that in el-get 4.1!

@DamienCassou

I don't think this feature should defer the release of 4.1 any longer. Why not keeping it for 4.2 if it has some documentation and users at this time?

@dimitri
Owner

Punting to 4.2 is a fair proposal, I will see if I get the round tuits to get it commited before doing that though.

@DarwinAwardWinner
Collaborator

I've cleared the milestone field from this one. If we merge it in time for 4.1 that's fine, but if not, that's fine too.

@jleechpe

I've been using this for my personal init without any issues. (Well beyond a few issues related to packages actually loading the files when el-get-is-lazy and they are called by autoloads, but that's a different issue).

I haven't seen any issues with it as it is. I'll look it over again to see about cleaning up the flet.

As to documentation, I'm assuming you'd want it submitted as a patch against the .texinfo file, and the info file that is generated from it?

@DarwinAwardWinner
Collaborator

The only issue with merging it is that if I merge it, I want to be able to take the time to properly test it and make sure it merges cleanly and so on, since it's quite a large and complicated diff.

@dimitri
Owner

Indeed @DarwinAwardWinner there's something to be said about this patch being too complex for what it does. As much as I would enjoy having literal support for setup in el-get, I guess it will have to wait till either 4.2 or 5.1. My guess at this point is that we should get back to releasing more often.

@jd
Collaborator
jd commented

@jleechpe You should rework your patch set so it does not include commit for corrections on your own previous commits. That does not help the readability for review and has little sense. Use git rebase --interactive to enhance that.

Otherwise, the patch does not look so bad, but just because there's too much commit, I didn't review it more than that. It's probably mergeable in the end, once it's rebased.

@jleechpe jleechpe Provides support for literate configuration files for specific packages.
  - Variable defined for .org file types `el-get-user-package-org-type`.
  - Function defined for loading .org file types
    `el-get-user-package-org-load`.
  - Variable defined for .el file types `el-get-user-package-el-type`.
  - Function defined for loading .el file types `el-get-user-package-el-load`.
  - `el-get-load-package-user-init-file` rewritten to support loading
    literate configuration files with extensions matching
    `el-get-user-package-org-type` before loading those matching
    `el-get-user-package-el-type`
  - .el files will be byte-compiled if `el-get-byte-compile` is `'t`.
    Otherwise they will be left uncompiled.  However .el files created
    from tangling .org files will not be compiled.

Added verification to avoid bootstrapping issues and errors from unavailable functions.

  - Added variable `el-get-user-package-org-pending` to be set to `'t`
    when user init file is wrapped in `eval-after-load`.  This is set
    to `'t` in `el-get-user-package-org-load` when wrapping the init
    file in `eval-after-load`.
  - Added function `el-get-user-package-org-check` to notify user if
    .org* user init files were wrapped in `eval-after-load` and
    `org-install` has still not been required.
  - Appended `el-get-user-package-org-check` to `el-get` after package
    loading is complete.
  - `Org` files are first loaded within `ignore-errors` to allow them
    to load if the function is already present (Emacs24).  If
    `org-babel-load-file` is not available, the loading is wrapped in
    `eval-after-load 'org-install` which will load the customizations
    once `org` is available.

The check for pending packages will fail when `el-get-is-lazy`.  Users
using `el-get-is-lazy` will have to ensure `org-install` is required
after calling `(el-get)` or that `org-babel-load-file` is already
available.  I cannot determine how to provide the warning in this case
without providing it after every package is loaded.

The check is also not called when a single package is being loaded
using `el-get-init`.  It is only performed when loading a package
using `(el-get package)`.
0932e76
@jleechpe

@jd Done, as well as rebased against Master.

I also managed to find a way to implement byte-compiling of .el files, which has been added.

Hopefully this leaves the changes easier to test and review.

@DamienCassou

I'm still unsure we want that before release.

@dimitri
Owner

I share @DamienCassou view on this, I think I'm going to apply last minute fixes, review the changelog and push 4.1 out the door. The goal would then be to release 4.2 soon enough with literate code support, etc. Maybe we can have several 4.x releases before we need to call it 5.1 :)

jleechpe added some commits
@jleechpe jleechpe Merge remote-tracking branch 'upstream/master' into literate-user-set…
…tings
e71e78d
@jleechpe jleechpe Replaced 'org-install with 'ob-tangle when checking to see if
org-babel-load-file is present.

'org-install is now deprecated in Org (current git HEAD) and will be
deprecated in the version shipped with Emacs 24.3.  The loading
function is found in `ob-tangle` however the message will prompt users
to `(require 'org)` since this will load `ob-tangle` as well.

Also fixed missing quote on package loading functions.
2c1bf1a
@dimitri
Owner

Let's get back to integrating that guys? What do you think? :)

@DarwinAwardWinner
Collaborator

I think our tests have sufficient coverage to give us good confidence in merging this if the merge passes all tests.

@dimitri
Owner

Great! Who's in for merging, testing, pushing, dancing? :)

@npostavs
Collaborator

Closing, as this seems to have stalled.

In my opinion, it's too much complexity to add to el-get just to save the user the trouble of adding (:name some-package :after (org-babel-load-file "init-some-package.org")) to their el-get-sources.

@npostavs npostavs closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 30, 2012
  1. @jleechpe

    Provides support for literate configuration files for specific packages.

    jleechpe authored
      - Variable defined for .org file types `el-get-user-package-org-type`.
      - Function defined for loading .org file types
        `el-get-user-package-org-load`.
      - Variable defined for .el file types `el-get-user-package-el-type`.
      - Function defined for loading .el file types `el-get-user-package-el-load`.
      - `el-get-load-package-user-init-file` rewritten to support loading
        literate configuration files with extensions matching
        `el-get-user-package-org-type` before loading those matching
        `el-get-user-package-el-type`
      - .el files will be byte-compiled if `el-get-byte-compile` is `'t`.
        Otherwise they will be left uncompiled.  However .el files created
        from tangling .org files will not be compiled.
    
    Added verification to avoid bootstrapping issues and errors from unavailable functions.
    
      - Added variable `el-get-user-package-org-pending` to be set to `'t`
        when user init file is wrapped in `eval-after-load`.  This is set
        to `'t` in `el-get-user-package-org-load` when wrapping the init
        file in `eval-after-load`.
      - Added function `el-get-user-package-org-check` to notify user if
        .org* user init files were wrapped in `eval-after-load` and
        `org-install` has still not been required.
      - Appended `el-get-user-package-org-check` to `el-get` after package
        loading is complete.
      - `Org` files are first loaded within `ignore-errors` to allow them
        to load if the function is already present (Emacs24).  If
        `org-babel-load-file` is not available, the loading is wrapped in
        `eval-after-load 'org-install` which will load the customizations
        once `org` is available.
    
    The check for pending packages will fail when `el-get-is-lazy`.  Users
    using `el-get-is-lazy` will have to ensure `org-install` is required
    after calling `(el-get)` or that `org-babel-load-file` is already
    available.  I cannot determine how to provide the warning in this case
    without providing it after every package is loaded.
    
    The check is also not called when a single package is being loaded
    using `el-get-init`.  It is only performed when loading a package
    using `(el-get package)`.
Commits on Oct 5, 2012
  1. @jleechpe
  2. @jleechpe

    Replaced 'org-install with 'ob-tangle when checking to see if

    jleechpe authored
    org-babel-load-file is present.
    
    'org-install is now deprecated in Org (current git HEAD) and will be
    deprecated in the version shipped with Emacs 24.3.  The loading
    function is found in `ob-tangle` however the message will prompt users
    to `(require 'org)` since this will load `ob-tangle` as well.
    
    Also fixed missing quote on package loading functions.
This page is out of date. Refresh to see the latest.
Showing with 100 additions and 13 deletions.
  1. +94 −12 el-get-recipes.el
  2. +6 −1 el-get.el
View
106 el-get-recipes.el 100644 → 100755
@@ -54,24 +54,106 @@ should be placed last in this list."
:group 'el-get
:type '(choice (const :tag "Off" nil) directory))
+(defcustom el-get-user-package-org-type
+ (list "org.gpg.bz2" "org.gpg.gz" "org.gpg" "org.bz2" "org.gz" "org")
+ "Define the .org* file extensions to look for when loading user init
+files. The extensions are matched in the order listed and the first
+one found is used."
+ :group 'el-get
+ :type '(repeat (string)))
+
+(defcustom el-get-user-package-el-type
+ (list "el.gpg.bz2" "el.gpg.gz" "el.gpg" "el.bz2" "el.gz" "el")
+ "Define the .el* file extensions to look for when loading user
+init files. The extensions are matched in the order listed and
+the first one found is used."
+ :group 'el-get
+ :type '(repeat (string)))
+
+(defvar el-get-user-package-org-pending 'nil
+ "Used to track whether org needs to be loaded for user
+ init files to finish being initialized.")
+
+(defun el-get-user-package-org-load (package-init-file)
+ "Function for loading user init files stored as .org*"
+ (condition-case nil
+ (org-babel-load-file package-init-file)
+ (error (eval-after-load 'ob-tangle `(org-babel-load-file
+ ,package-init-file))
+ (setq el-get-user-package-org-pending 't))))
+
+(defun el-get-user-package-org-check ()
+ "Check to see if any user init files are waiting on ob-tangle.
+
+If 'nil then either `org-babel-load-file' is available, or no
+user init files are .org*. If 't then notify user that
+org is not yet loaded."
+ (when el-get-user-package-org-pending
+ ;; Check to see if ob-tangle or org were required after
+ ;; (eval-after-load 'ob-tangle) was called. Org will load
+ ;; ob-tangle as well.
+ (unless (featurep 'ob-tangle)
+ (el-get-notify "Loading of user init files incomplete"
+ "Add Org-Mode to path and run `(require 'org)' to complete initialization."))))
+
+(defun el-get-user-package-el-load (package-init-file)
+ "Function for loading user init files stored as .el*.
+
+This also respects the settings for `el-get-byte-compile'."
+ (if el-get-byte-compile
+ ;; Determine what the compiled filename will be. Since the
+ ;; package could have multiple extensions due to archiving and
+ ;; encrypting you cannot simply remove the last extension.
+ (let ((compile-name (byte-compile-dest-file package-init-file)))
+ (el-get-byte-compile package-init-file)
+ ;; Load the compiled file. This ensures you do not
+ ;; accidentally load a non .el/.elc file if there is such
+ ;; present in the directory.
+ (load-file compile-name))
+ ;; Otherwise load the uncompiled file.
+ (load-file package-init-file)))
+
(defun el-get-load-package-user-init-file (package)
"Load the user init file for PACKAGE, called init-package.el
and to be found in `el-get-user-package-directory'. Do nothing
when this custom is nil.
-Will automatically compile the init file as needed and load the
-compiled version."
+If the file is a literate file create in Org Mode it will
+automatically create a .el as needed based on file modification
+times and load it. If the file is a traditional elisp file it
+will load it directly."
(when el-get-user-package-directory
- (let* ((init-file-name (format "init-%s.el" package))
- (package-init-file
- (expand-file-name init-file-name el-get-user-package-directory))
- (file-name-no-extension (file-name-sans-extension package-init-file))
- (compiled-init-file (concat file-name-no-extension ".elc")))
- (when (file-exists-p package-init-file)
- (when el-get-byte-compile
- (el-get-byte-compile-file package-init-file))
- (el-get-verbose-message "el-get: load %S" file-name-no-extension)
- (load file-name-no-extension 'noerror)))))
+ ;; Match the package against the extension to determine which
+ ;; command to use when loading it. This returns the first
+ ;; matching filename+extension to be loaded, as well as the method
+ ;; to load it (org or elisp).
+ (flet ((package-load (base ext-type command)
+ (catch 'exists
+ (loop for ext in ext-type do
+ (let ((filename (format "%s.%s" base ext)))
+ (if (file-exists-p filename)
+ (throw 'exists `(,command ,filename)))))
+ nil)))
+ (let* ((package-name (format "init-%s" package))
+ (base (expand-file-name package-name
+ el-get-user-package-directory))
+ ;; By preferring .org files over .el files you ensure
+ ;; that changes to the .org files will be taken into
+ ;; account and a new .el file will be tangled to reflect
+ ;; those changes.
+ (load-method (or
+ (package-load base
+ el-get-user-package-org-type
+ 'el-get-user-package-org-load)
+ (package-load base
+ el-get-user-package-el-type
+ 'el-get-user-package-el-load))))
+ ;; Perform load evalation here
+ (if load-method
+ (progn
+ (el-get-verbose-message "el-get: load %S" (cdr load-method))
+ (eval load-method))
+ (el-get-verbose-message "el-get: No init file for %S" package))))))
(defun el-get-recipe-dirs ()
"Return the elements of el-get-recipe-path that actually exist.
View
7 el-get.el
@@ -1037,7 +1037,12 @@ already installed packages is considered."
(el-get-init-and-install (mapcar 'el-get-as-symbol packages))
;; now is a good time to care about autoloads
- (el-get-eval-autoloads))))
+ (el-get-eval-autoloads))
+
+ ;; Now that package loading is complete, check that .org user init
+ ;; files were loaded and not simply left waiting for
+ ;; 'org-install to be required.
+ (el-get-user-package-org-check)))
(provide 'el-get)
Something went wrong with that request. Please try again.