bug#8205: user-controlled load-path extension: load-dir

bug#8205: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1.1: Type: text/plain, Size: 1146 bytes --]

Hello,

I have attached to this message version 2 of user-load-dir.el.  This version
incorporates the recursive load-dir function written by Evans Winner (see <
http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>).  It
also adds two new defcustom variables,
load-files-in-user-load-dir-recursively and
auto-load-files-in-user-load-dir.

Note that one major new feature introduced by this version is that if the
.el file has been byte compiled, the byte compiled version will be loaded
instead of the source version.  This is a major improvement over my original
version which would only load .el files.

There are two remaining issues with this version.  If one of the files in
the user-load-dir has been byte-compiled, it will be loaded twice.  Also it
has no error handling.

I am more than willing to continue development of this file into an Emacs
package that can be included in ELPA.  This would make it possible for this
useful feature to be made readily available to those who want to use it
without including it in Emacs itself.

I have one question.  What sort of error handling should I incorporate into
this package?

[-- Attachment #1.2: Type: text/html, Size: 1306 bytes --]

[-- Attachment #2: user-load-dir.el --]
[-- Type: application/octet-stream, Size: 3741 bytes --]

;;; user-load-dir.el -- A quick and dirty implementation of a user load
;;; directory.  This file is provided as a possible answer to the
;;; "user-controlled load-path extension: load-dir" discussion on the
;;; emacs-devel list found at
;;; <http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00048.html>.

;;; This could eventually be turned into an Emacs package that can be
;;; installed via package.el.  For now, this file can be installed by
;;; placing it somewhere in your load path and add the line
;;; (require 'user-load-dir)
;;; to your .emacs or site-start.el file.

;;; Copyright (c) 2011 Ben Key

;; This file is free software: you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This file is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with the bk-emacs-tools package.  If not, see
;; <http://www.gnu.org/licenses/>.

(defcustom user-load-dir
  (format "%s.emacs.d/load" (file-name-directory (expand-file-name user-init-file)))
  "A user defined directory in which the user can place .el files that
will automatically be loaded after Emacs initialization is complete."
  :type 'directory
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom load-files-in-user-load-dir-recursively nil
  "Non-nil causes `load-user-load-dir-files' to load all .el or .elc
files in the `user-load-dir' and in all subdirectories of the
`user-load-dir.'  Nil causes `load-user-load-dir-files' to load only
the files in the `user-load-dir.'

The default value is nil."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom auto-load-files-in-user-load-dir t
"Non-nil causes `load-user-load-dir-files' to be called automatically
from the `after-init-hook.'  Nil suppresses this automatic loading.
Note that since `load-user-load-dir-files' is an interactive function,
you may call it manually by using 'M-x load-user-load-dir-files' if you
choose to set this variable to nil.

The default value is t."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defun load-dir (directory &optional recurse)
  "Load all Emacs Lisp files in DIRECTORY.
If RECURSE is non-nil, recursively load all such files in all
subdirectories.

This function was written by Evans Winner.  See the message
<http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>"
  (interactive "D")
  (dolist (file
           (directory-files (expand-file-name directory) t
                            directory-files-no-dot-files-regexp) nil)
    (cond
     ((and recurse (file-directory-p file))
      (when recurse (load-dir file)))
     ((string-match "\\.el$\\|\\.elc$" file)
      (load-library (file-name-sans-extension file))))))

(defun load-user-load-dir-files ()
  "Loads all .el files found in the `user-load-dir.'"
  (interactive)
  (load-dir user-load-dir load-files-in-user-load-dir-recursively)
  )

(defun user-load-dir-after-init-hook ()
  "An `after-init-hook' function that is used to conditionally call
`load-user-load-dir-files' depending on the value of
`auto-load-files-in-user-load-dir'."
  (if auto-load-files-in-user-load-dir
	  (load-user-load-dir-files)
	)
  )

(add-hook 'after-init-hook 'load-user-load-dir-files)

(provide 'user-load-dir)

bug#8205: user-controlled load-path extension: load-dir (Ben Key)

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

Hello,

Please ignore this bug.  I did not intend to send the message to
bug-gnu-emacs@gnu.org.  I meant it to go to Emacs-devel@gnu.org.  I guess I
was just careless then typing the addresses in the To field.

[-- Attachment #2: Type: text/html, Size: 335 bytes --]

RE: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1.1: Type: text/plain, Size: 1146 bytes --]

Hello,

I have attached to this message version 2 of user-load-dir.el.  This version
incorporates the recursive load-dir function written by Evans Winner (see <
http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>).  It
also adds two new defcustom variables,
load-files-in-user-load-dir-recursively and
auto-load-files-in-user-load-dir.

Note that one major new feature introduced by this version is that if the
.el file has been byte compiled, the byte compiled version will be loaded
instead of the source version.  This is a major improvement over my original
version which would only load .el files.

There are two remaining issues with this version.  If one of the files in
the user-load-dir has been byte-compiled, it will be loaded twice.  Also it
has no error handling.

I am more than willing to continue development of this file into an Emacs
package that can be included in ELPA.  This would make it possible for this
useful feature to be made readily available to those who want to use it
without including it in Emacs itself.

I have one question.  What sort of error handling should I incorporate into
this package?

[-- Attachment #1.2: Type: text/html, Size: 1365 bytes --]

[-- Attachment #2: user-load-dir.el --]
[-- Type: application/octet-stream, Size: 3741 bytes --]

;;; user-load-dir.el -- A quick and dirty implementation of a user load
;;; directory.  This file is provided as a possible answer to the
;;; "user-controlled load-path extension: load-dir" discussion on the
;;; emacs-devel list found at
;;; <http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00048.html>.

;;; This could eventually be turned into an Emacs package that can be
;;; installed via package.el.  For now, this file can be installed by
;;; placing it somewhere in your load path and add the line
;;; (require 'user-load-dir)
;;; to your .emacs or site-start.el file.

;;; Copyright (c) 2011 Ben Key

;; This file is free software: you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This file is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with the bk-emacs-tools package.  If not, see
;; <http://www.gnu.org/licenses/>.

(defcustom user-load-dir
  (format "%s.emacs.d/load" (file-name-directory (expand-file-name user-init-file)))
  "A user defined directory in which the user can place .el files that
will automatically be loaded after Emacs initialization is complete."
  :type 'directory
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom load-files-in-user-load-dir-recursively nil
  "Non-nil causes `load-user-load-dir-files' to load all .el or .elc
files in the `user-load-dir' and in all subdirectories of the
`user-load-dir.'  Nil causes `load-user-load-dir-files' to load only
the files in the `user-load-dir.'

The default value is nil."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom auto-load-files-in-user-load-dir t
"Non-nil causes `load-user-load-dir-files' to be called automatically
from the `after-init-hook.'  Nil suppresses this automatic loading.
Note that since `load-user-load-dir-files' is an interactive function,
you may call it manually by using 'M-x load-user-load-dir-files' if you
choose to set this variable to nil.

The default value is t."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defun load-dir (directory &optional recurse)
  "Load all Emacs Lisp files in DIRECTORY.
If RECURSE is non-nil, recursively load all such files in all
subdirectories.

This function was written by Evans Winner.  See the message
<http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>"
  (interactive "D")
  (dolist (file
           (directory-files (expand-file-name directory) t
                            directory-files-no-dot-files-regexp) nil)
    (cond
     ((and recurse (file-directory-p file))
      (when recurse (load-dir file)))
     ((string-match "\\.el$\\|\\.elc$" file)
      (load-library (file-name-sans-extension file))))))

(defun load-user-load-dir-files ()
  "Loads all .el files found in the `user-load-dir.'"
  (interactive)
  (load-dir user-load-dir load-files-in-user-load-dir-recursively)
  )

(defun user-load-dir-after-init-hook ()
  "An `after-init-hook' function that is used to conditionally call
`load-user-load-dir-files' depending on the value of
`auto-load-files-in-user-load-dir'."
  (if auto-load-files-in-user-load-dir
	  (load-user-load-dir-files)
	)
  )

(add-hook 'after-init-hook 'load-user-load-dir-files)

(provide 'user-load-dir)

bug#8205: Closing bug#8205: user-controlled load-path extension: load-dir (Ben Key)

[Ted Zlatanov]

On Tue, 8 Mar 2011 12:48:58 -0600 Ben Key <bkey76@gmail.com> wrote: 

BK> Hello,
BK> Please ignore this bug.  I did not intend to send the message to
BK> bug-gnu-emacs@gnu.org.  I meant it to go to Emacs-devel@gnu.org.  I guess I
BK> was just careless then typing the addresses in the To field.

This should close the bug.

Ted

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Ben Key <bkey76@gmail.com> writes: 
> I am more than willing to continue development of this file into 
> an Emacs package that can be included in ELPA.  This would make 
> it possible for this useful feature to be made readily available 
> to those who want to use it without including it in Emacs 
> itself. 
 
In my opinion, the biggest value by far of such a feature is to be 
able to depend on `user-load-dir' with no active collaboration of 
the user.  So please consider including in Emacs, not as an 
additional package.   Really the goal is to simplify as much as 
possible the steps required to install a new elisp file as a user. 
See how it goes each time (and that's only too often each day) on 
the help channel:  20:55 <dim> ,install
20:55 <fsbot> install -- [0] To install a <file>.el, save it to, 
say ~/elisp
20:55 <fsbot> [1] add to the beginning of ~/.emacs: (add-to-list 
'load-path 
              "~/elisp"), ..[Type ,more]
20:55 <dim> ,m
20:56 <fsbot> [2] now FOLLOW THE INSTALLATION INSTRUCTIONS IN THE 
FILE, 
              typically adding (require '<file>) to the end of 
              ~/.emacs,
20:56 <fsbot> [3] see 
http://www.emacswiki.org/cgi-bin/wiki.pl?LoadPath, ..[Type 
              ,more]
20:56 <dim> ,m
20:56 <fsbot> [4] the site-wide emacs extension directory is 
usually 
              `/usr/local/share/emacs/site-lisp',
20:56 <fsbot> [5] see autoload

With this new facility, we could say to newbies to just save the
<file>.el in ~/.emacs.d/load.d and do M-x load-user-files, or even M-x
load-new-user-files.  And of course we could bootstrap external scripts
much more easily: if we take el-get as an example, the user would never
have to worry about the load-path any more.  Ever.


Also I think that `user-load-dir' should default to "~/.emacs.d/load.d/".

I have no particular opinion on the autoloading facility that Julien
requires, because it seems to me that as soon as the `user-load-dir' is
there, it's easy to provide for a snippet that allow support for
"~/.emacs.d/autoload.d", whereas I don't see how to go the other route.

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Chad Brown]

On Mar 8, 2011, at 12:01 PM, Dimitri Fontaine wrote:
> With this new facility, we could say to newbies to just save the
> <file>.el in ~/.emacs.d/load.d and do M-x load-user-files, or even M-x
> load-new-user-files.

Without the problems of a magic directory, we just just tell the user something
like:

``in emacs: M-x browse-packages RET, browse to <packagename>, and click `install'.''

or, for random `snippets' in things like github or emacswiki:

``in emacs: M-x install-by-url RET <paste URL here>''

and have emacs download the package, unpack it, describe it to the user, and offer to activate it (adding any necessary code to .emacs, probably via a custom-style equivalent).  This could also ask any required questions up front. This seems easier (for the user) and more capable (for the developer).  Why the opposition? Emacs already contains facilities that modify the user's startup files for them, and has for decades.

From the point of view of emacs 24 and inexperienced users, I again suggest that the Firefox extensions/themes mechanism is a much better model to examine than magic directories.
 
I hope that helps.
*Chad

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Chad Brown <yandros@MIT.EDU> writes:
> ``in emacs: M-x install-by-url RET <paste URL here>''
>
> and have emacs download the package, unpack it, describe it to the user, and
> offer to activate it (adding any necessary code to .emacs, probably via a
> custom-style equivalent).

You are pretty much describing how el-get already works.

>  This could also ask any required questions up
> front. This seems easier (for the user) and more capable (for the
> developer).  Why the opposition? Emacs already contains facilities that
> modify the user's startup files for them, and has for decades.

I hate it when any other software edit my user files, that's the whole
point of `user-load-dir'.

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Chad Brown]

On Mar 8, 2011, at 12:38 PM, Dimitri Fontaine wrote:

> You are pretty much describing how el-get already works.

Yep; that's why I suggested it to Ted back in the original thread. For emacs 24, I'd like to see the other parts added (the questions and configuration, basically). Package.el provides most of the building blocks for this already, which is why I suggested to Ted that he could perhaps usefully combine the two.

>> This could also ask any required questions up
>> front. This seems easier (for the user) and more capable (for the
>> developer).  Why the opposition? Emacs already contains facilities that
>> modify the user's startup files for them, and has for decades.
> 
> I hate it when any other software edit my user files, that's the whole
> point of `user-load-dir'.

I guess I can see your complaint, since I also don't like software munging my .emacs file, but I find it hard to believe that there are many (any?) users who need your simplified method and yet don't want code messing with .emacs automatically.  Take a look at the documentation for custom-file and see if that doesn't address your concern.

*Chad

Re: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Hello,

What is the general consensus on this?  Should we build this feature in as
Ted Zlatanov has requested or should we simply continue the development of
the package I have started that implements this feature and perhaps make it
available on ELPA?

I fully understand the reasoning behind this request.  What Ted wants is to
be able to download a .el file from the Internet, place it into a given
directory, and not have to do anything else to make it just work.  He wants
an alternative to changing his .emacs file, either manually or through an
automated mechanism, that is simpler to use than the Emacs package
mechanism.

The user-load-dir.el file I have provided accomplishes this task.  I am more
than willing to continue developing it into an Emacs package (I just have
not read the documentation yet so I know little more about the Emacs package
mechanism than it exists).

I know that providing this functionality as an Emacs package does not do
precisely what Ted wants because it does not make it "just work" in a clean
Emacs installation, which I think is what he was really hoping for.  But it
does make it possible to make Emacs behave as he has requested after
installing a single Emacs package, which is the next best thing.

If we go forward with providing this feature as an Emacs Package, I will
need to either get permission from Evans Winner to include his load-dir
function or write an implementation of it myself.

What is the next step?

[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

Re: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1.1: Type: text/plain, Size: 885 bytes --]

Hello,

I have attached to this message version 3 of user-load-dir.el.  This version
fixes a bug in the prior version in the usage of the after-init-hook.  It
also incorporates some basic error handling in the load-dir function.  The
load-dir function has also been modified so that when a .el file has been
byte-compiled, thus causing a .el and a .elc file of the same name to exist,
the file is only loaded once.  In addition, user-load-dir.el now works
correctly when it is loaded from site-start.el (I had to deal with the fact
that user-init-file is nil at that point).  Finally it now works correctly
in XEmacs (directory-files-no-dot-files-regexp is not defined in XEmacs).

I look forward to any feedback anyone might have to offer on this
implementation of the user-load-dir feature.  I also look forward to a
discussion about how this feature will be offered to Emacs users.

[-- Attachment #1.2: Type: text/html, Size: 932 bytes --]

[-- Attachment #2: user-load-dir.el --]
[-- Type: application/octet-stream, Size: 4843 bytes --]

;;; user-load-dir.el -- A quick and dirty implementation of a user load
;;; directory.  This file is provided as a possible answer to the
;;; "user-controlled load-path extension: load-dir" discussion on the
;;; emacs-devel list found at
;;; <http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00048.html>.

;;; This could eventually be turned into an Emacs package that can be
;;; installed via package.el.  For now, this file can be installed by
;;; placing it somewhere in your load path and add the line
;;; (require 'user-load-dir)
;;; to your .emacs or site-start.el file.

;;; Copyright (c) 2011 Ben Key

;; This file is free software: you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This file is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with the bk-emacs-tools package.  If not, see
;; <http://www.gnu.org/licenses/>.

(if (not (boundp 'directory-files-no-dot-files-regexp))
	(defconst directory-files-no-dot-files-regexp
	  "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*"
	  "Regexp matching any file name except \".\" and \"..\".")
  )

(defcustom user-load-dir
  (if (not (null user-init-file))
	  ;; If this file is loaded from site-start.el, `user-init-file'
	  ;; will be nil, this will cause `file-name-directory' to throw an
	  ;; error due to the argument not being a string.  As a result, we
	  ;; only attempt to set the default value of `user-load-dir' here
	  ;; if `user-init-file' is not nil.
	  (format "%s.emacs.d/load.d" (file-name-directory (expand-file-name user-init-file)))
	nil
	)
  "A user defined directory in which the user can place .el files that
will automatically be loaded after Emacs initialization is complete."
  :type 'directory
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom load-files-in-user-load-dir-recursively nil
  "Non-nil causes `load-user-load-dir-files' to load all .el or .elc
files in the `user-load-dir' and in all subdirectories of the
`user-load-dir.'  Nil causes `load-user-load-dir-files' to load only
the files in the `user-load-dir.'

The default value is nil."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom auto-load-files-in-user-load-dir t
  "Non-nil causes `load-user-load-dir-files' to be called automatically
from the `after-init-hook.'  Nil suppresses this automatic loading.
Note that since `load-user-load-dir-files' is an interactive function,
you may call it manually by using 'M-x load-user-load-dir-files' if you
choose to set this variable to nil.

The default value is t."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defun load-dir (directory &optional recurse)
  "Load all Emacs Lisp files in DIRECTORY.
If RECURSE is non-nil, recursively load all such files in all
subdirectories.

This function was written by Evans Winner.  See the message
<http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>"
  (interactive "D")
  (let (this-file loaded-files-list)
	(dolist 
		(file 
		 (directory-files
		  (expand-file-name directory) 
		  t directory-files-no-dot-files-regexp) nil)
	  (cond
	   ((and recurse (file-directory-p file))
		(when recurse (load-dir file))
		)
	   ((string-match "\\.el$\\|\\.elc$" file)
		(setq this-file (file-name-sans-extension file))
		(if (not (member this-file loaded-files-list))
			(condition-case err
				(progn
				  (load-library this-file)
				  (setq loaded-files-list (add-to-list 'loaded-files-list this-file))
				  )
			  (message "An error occurred while loading '%s.'" file)
			  )
		  )
		)
	   )
	  )
	)
  )

(defun load-user-load-dir-files ()
  "Loads all .el files found in the `user-load-dir.'"
  (interactive)
  (load-dir user-load-dir load-files-in-user-load-dir-recursively)
  )

(defun user-load-dir-after-init-hook ()
  "An `after-init-hook' function that is used to conditionally call
`load-user-load-dir-files' depending on the value of
`auto-load-files-in-user-load-dir'."
  (if (null user-load-dir)
	  ;; If this file is loaded from site-start.el, `user-load-dir' may
	  ;; be nil at this point.  See the comments for `user-load-dir'
	  ;; above. If this happens, use the default value here.
	  (setq user-load-dir (format "%s.emacs.d/load.d" (file-name-directory (expand-file-name user-init-file))))
	)
  (if auto-load-files-in-user-load-dir
	  (load-user-load-dir-files)
	)
  )

(add-hook 'after-init-hook 'user-load-dir-after-init-hook)

(provide 'user-load-dir)

Re: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1.1: Type: text/plain, Size: 1587 bytes --]

Hello,

I have attached to this message version 4 of user-load-dir.el.

Several changes have been made to this version.

   1. The error handling in load-dir actually works as expected.  If one of
   the files in the user-load-dir generates an error, it is silently ignored
   and load-dir continues to load all the other files in the user-load-dir.
   2. Added the function byte-compile-dir to user-load-dir.el.  This
   function can be used to byte compile all files in the directory specified by
   the directory parameter.  If the optional parameter recurs is non-nil, this
   is done recursively.
   3. Added the function byte-compile-user-load-dir-files.  This interactive
   function may be used to byte compile all files in the user-load-dir.
   4. The function load-user-load-dir-files does nothing if user-load-dir is
   nil.
   5. Modified the user-load-dir defcustom so that it is set to t instead of
   nil in the case that it cannot be initialized at load time due to
   user-init-file being nil.
   6. Modified user-load-dir-after-init-hook so that it only sets
   user-load-dir to its default value if it is equal to t.

The reason I made changes 5 and 6 is to allow for the possibility of this
feature being disabled by the user setting user-load-dir to nil.

Setting auto-load-files-in-user-load-dir to nil causes to not be called
automatically by the user-load-dir-after-init-hook but the files can still
be called by calling load-user-load-dir-files interactively.  Setting
user-load-dir
to nil disables load-user-load-dir-files and
byte-compile-user-load-dir-files.

[-- Attachment #1.2: Type: text/html, Size: 1912 bytes --]

[-- Attachment #2: user-load-dir.el --]
[-- Type: application/octet-stream, Size: 5588 bytes --]

;;; user-load-dir.el -- A quick and dirty implementation of a user load
;;; directory.  This file is provided as a possible answer to the
;;; "user-controlled load-path extension: load-dir" discussion on the
;;; emacs-devel list found at
;;; <http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00048.html>.

;;; This could eventually be turned into an Emacs package that can be
;;; installed via package.el.  For now, this file can be installed by
;;; placing it somewhere in your load path and add the line
;;; (require 'user-load-dir)
;;; to your .emacs or site-start.el file.

;;; Copyright (c) 2011 Ben Key

;; This file is free software: you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This file is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with the bk-emacs-tools package.  If not, see
;; <http://www.gnu.org/licenses/>.

(if (not (boundp 'directory-files-no-dot-files-regexp))
	(defconst directory-files-no-dot-files-regexp
	  "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*"
	  "Regexp matching any file name except \".\" and \"..\".")
  )

(defcustom user-load-dir
  (if (not (null user-init-file))
	  ;; If this file is loaded from site-start.el, `user-init-file'
	  ;; will be nil, this will cause `file-name-directory' to throw an
	  ;; error due to the argument not being a string.  As a result, we
	  ;; only attempt to set the default value of `user-load-dir' here
	  ;; if `user-init-file' is not nil.
	  (format "%s.emacs.d/load.d" (file-name-directory (expand-file-name user-init-file)))
	t
	)
  "A user defined directory in which the user can place .el files that
will automatically be loaded after Emacs initialization is complete."
  :type 'directory
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom load-files-in-user-load-dir-recursively nil
  "Non-nil causes `load-user-load-dir-files' to load all .el or .elc
files in the `user-load-dir' and in all subdirectories of the
`user-load-dir.'  Nil causes `load-user-load-dir-files' to load only
the files in the `user-load-dir.'

The default value is nil."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defcustom auto-load-files-in-user-load-dir t
  "Non-nil causes `load-user-load-dir-files' to be called automatically
from the `after-init-hook.'  Nil suppresses this automatic loading.
Note that since `load-user-load-dir-files' is an interactive function,
you may call it manually by using 'M-x load-user-load-dir-files' if you
choose to set this variable to nil.

The default value is t."
  :type 'boolean
  :group 'initialization
  :require 'user-load-dir
  )

(defun load-dir (directory &optional recurse)
  "Load all Emacs Lisp files in DIRECTORY.
If RECURSE is non-nil, recursively load all such files in all
subdirectories.

This function is based on one written by Evans Winner.  See the message
<http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00239.html>
for details."
  (interactive "D")
  (let (this-file loaded-files-list)
	(dolist 
		(file 
		 (directory-files
		  (expand-file-name directory) 
		  t directory-files-no-dot-files-regexp) nil)
	  (cond
	   ((and recurse (file-directory-p file))
		(when recurse (load-dir file))
		)
	   ((string-match "\\.el$\\|\\.elc$" file)
		(setq this-file (file-name-sans-extension file))
		(if (not (member this-file loaded-files-list))
			(progn
			  (setq loaded-files-list (add-to-list 'loaded-files-list this-file))
			  (ignore-errors
				(load this-file))
			  )
		  )
		)
	   )
	  )
	)
  )

(defun load-user-load-dir-files ()
  "Loads all .el files found in the `user-load-dir.'"
  (interactive)
  (if (not (null user-load-dir))
	  (load-dir user-load-dir load-files-in-user-load-dir-recursively)
	)
  )

(defun byte-compile-dir (directory &optional recurse)
  "Byte compile all Emacs Lisp files in DIRECTORY.  If RECURSE is
non-nil, recursively byte compile all such files in all
subdirectories."
  (interactive "D")
  (dolist 
	  (file 
	   (directory-files
		(expand-file-name directory) 
		t directory-files-no-dot-files-regexp) nil)
	(cond
	 ((and recurse (file-directory-p file))
	  (when recurse (byte-compile-dir file))
	  )
	 ((string-match "\\.el$" file)
	  (ignore-errors
		(byte-compile-file file))
	  )
	 )
	)
  )

(defun byte-compile-user-load-dir-files ()
  "Byte compiles all .el files found in the `user-load-dir.'"
  (interactive)
  (if (not (null user-load-dir))
	  (byte-compile-dir user-load-dir load-files-in-user-load-dir-recursively)
	)
  )

(defun user-load-dir-after-init-hook ()
  "An `after-init-hook' function that is used to conditionally call
`load-user-load-dir-files' depending on the value of
`auto-load-files-in-user-load-dir'."
  (if (equal user-load-dir t)
	  ;; If this file is loaded from site-start.el, `user-load-dir' may
	  ;; be nil at this point.  See the comments for `user-load-dir'
	  ;; above. If this happens, use the default value here.
	  (setq user-load-dir
			(format "%s.emacs.d/load.d" (file-name-directory (expand-file-name user-init-file))))
	)
  (if auto-load-files-in-user-load-dir
	  (load-user-load-dir-files)
	)
  )

(add-hook 'after-init-hook 'user-load-dir-after-init-hook)

(provide 'user-load-dir)

Re: user-controlled load-path extension: load-dir

[Jan D.]

Hello.

What is wrong with (expand-file-name "~/emacs.d/load.d")?  I don't think 
user-init-file can be nil either.

It is much better to explicitly check for "." and ".." than use 
directory-files-no-dot-files-regexp.  That regexp is really really slow.

	Jan D.


Ben Key skrev 2011-03-09 07:50:
> Hello,
>
> I have attached to this message version 4 of user-load-dir.el.
>
> Several changes have been made to this version.
>
>    1. The error handling in load-dir actually works as expected.  If one
>       of the files in the user-load-dir generates an error, it is
>       silently ignored and load-dir continues to load all the other
>       files in the user-load-dir.
>    2. Added the function byte-compile-dir to user-load-dir.el.  This
>       function can be used to byte compile all files in the directory
>       specified by the directory parameter.  If the optional parameter
>       recurs is non-nil, this is done recursively.
>    3. Added the function byte-compile-user-load-dir-files.  This
>       interactive function may be used to byte compile all files in the
>       user-load-dir.
>    4. The function load-user-load-dir-files does nothing if
>       user-load-dir is nil.
>    5. Modified the user-load-dir defcustom so that it is set to t
>       instead of nil in the case that it cannot be initialized at load
>       time due to user-init-file being nil.
>    6. Modified user-load-dir-after-init-hook so that it only sets
>       user-load-dir to its default value if it is equal to t.
>
> The reason I made changes 5 and 6 is to allow for the possibility of
> this feature being disabled by the user setting user-load-dir to nil.
>
> Setting auto-load-files-in-user-load-dir to nil causes to not be called
> automatically by the user-load-dir-after-init-hook but the files can
> still be called by calling load-user-load-dir-files interactively.
> Setting user-load-dir to nil disables load-user-load-dir-files and
> byte-compile-user-load-dir-files.
>

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Chad Brown <yandros@MIT.EDU> writes:
> I guess I can see your complaint, since I also don't like software munging
> my .emacs file, but I find it hard to believe that there are many (any?)
> users who need your simplified method and yet don't want code messing with
> .emacs automatically.

It's not that much about simplicity that it's about having the computer
do all the automatic work on its own.  `user-load-dir' would help with
that.

It could be that custom.el would help too, but I don't really see how.

The idea we're talking about here is to have a simpler way to enable a
piece of elisp code that you fetch from somewhere (mail attachment,
emacswiki, some blog, an automatic installer, etc).  I don't see how
much simpler we can go than "save the content in a <file>.el in
~/.emacs.d/load.d, then either restart Emacs or M-x reload-user-dir".
And for automatic installers, the location is known to be `user-load-dir'.

I see people that want the feature too, some have already written some
version of it, some are sending new implementation, so I think there's a
need to cover here.  That you don't share the need is fine, you just
won't use the feature, and maybe even explicitly

  (setq user-load-dir nil)

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 9 Mar 2011 00:50:23 -0600 Ben Key <bkey76@gmail.com> wrote: 

BK> ;;; user-load-dir.el -- A quick and dirty implementation of a user load
BK> ;;; directory.

I agree with Jan that `directory-files-no-dot-files-regexp' is not
necessary.

`user-load-dir' should be `user-load-dirs' and customizable as a list of
directory names, not a single directory.

The variables and functions in user-load-dir.el should start with
"user-load-dir".  For example `load-files-in-user-load-dir-recursively'
is not a good name.  If this is in the core the variable names could be
different but in a library they shouldn't be.  I suggest several name
fixes below but it needs to be fixed everywhere.

`load-files-in-user-load-dir-recursively' would be better named
`user-load-dir-recursive'.

`auto-load-files-in-user-load-dir' is not needed.  If `user-load-dirs'
is not empty that implies you want to load the things in it.

`byte-compile-dir' should be named `user-load-dir-byte-compile'.
Similarly `byte-compile-user-load-dir-files' should be
`user-load-dir-byte-compile-files'.

It would also be good to make sure the code works with Emacs 23.1
through 23.3 so users can take it there as well.

Ted

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 09 Mar 2011 10:36:59 +0100 Dimitri Fontaine <dim@tapoueh.org> wrote: 

DF> The idea we're talking about here is to have a simpler way to enable a
DF> piece of elisp code that you fetch from somewhere (mail attachment,
DF> emacswiki, some blog, an automatic installer, etc).  I don't see how
DF> much simpler we can go than "save the content in a <file>.el in
DF> ~/.emacs.d/load.d, then either restart Emacs or M-x reload-user-dir".
DF> And for automatic installers, the location is known to be `user-load-dir'.

DF> I see people that want the feature too, some have already written some
DF> version of it, some are sending new implementation, so I think there's a
DF> need to cover here.  That you don't share the need is fine, you just
DF> won't use the feature, and maybe even explicitly

DF>   (setq user-load-dir nil)

On Wed, 09 Mar 2011 11:01:38 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> I can make an load-dir feature in .emacs too.  It is having this in
JD> emacs core, working without extra user work that is the point.

I think it's clear there's quite a few users who want the load-dir
feature for various reasons.  The URLs I posted show that it's been
needed for a while now although no one thought to add it to Emacs.
package.el and el-get will not do what we're asking for.  As proposed
it's disabled by default so it won't matter to the users who don't want it.

I'd like to know if the maintainers have a reason NOT to put
user-load-dir in the core.  If we can proceed in the core, I'll propose
a specific patch and we can discuss that.  Otherwise I'll make it a
package in the GNU ELPA which is not as convenient but still usable.

Thanks
Ted

Re: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Wed, Mar 9, 2011 at 1:29 AM, Jan D. <jan.h.d@swipnet.se> wrote:

> What is wrong with (expand-file-name "~/emacs.d/load.d")?
> I don't think user-init-file can be nil either.

As I said in my comments for the user-load-dir defcustom, "If this file is
loaded from site-start.el, `user-init-file' will be nil."  Apparently
site-start.el is loaded before the code in lread.c that initializes the
Vuser_init_file variable.  I was surprised myself when I made the change to
load user-load-dir.el from my site-start.el and I got an error on the
defcustom line.

As for expanding "~/emacs.d/load.d," it may have the same problem with being
called from site-start.el.  If it does not, I will use it.

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

Re: user-controlled load-path extension: load-dir

[Chong Yidong]

Ben Key <bkey76@gmail.com> writes:

> What is the general consensus on this?  Should we build this feature
> in as Ted Zlatanov has requested or should we simply continue the
> development of the package I have started that implements this feature
> and perhaps make it available on ELPA?

I still don't understand what "this" is.  Why do you need a full-blown
package to implement

(dolist (f (directory-files dir t "\\.el$"))
  (load foo))

Re: user-controlled load-path extension: load-dir

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

To begin with using

(dolist (f (directory-files dir t "\\.el$"))
 (load foo))

does not support error handling so that Emacs will barf if one of the .el
files has an error in it.  Also, it does not support loading of files
recursively or loading byte-compiled files (it will load from source even if
byte compiled files are present).

Also, while this problem could be solved by adding those few lines to
,emacs, users would need to define dir themselves.  This package is intended
partially to allow someone who is not familiar with ELisp to just drop a
file they downloaded into a directory and have Emacs load it.

The benefit of providing a package to implement this functionality is that
the user of the package does not need to figure out how to define dir
themselves, it provides error handling so that Emacs initialization will not
be interrupted while loading the files in the load dir, it optionally
supports loading files recursively, and supports loading of byte compiled
files.  To support all of that your two lines quickly grows to be
considerably more.  My current implementation has about 100 lines if you
strip out the comments.  That is why a package is required, to provide
features your quick and dirty two line solution does not.

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 09 Mar 2011 14:51:22 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ben Key <bkey76@gmail.com> writes:
>> What is the general consensus on this?  Should we build this feature
>> in as Ted Zlatanov has requested or should we simply continue the
>> development of the package I have started that implements this feature
>> and perhaps make it available on ELPA?

CY> I still don't understand what "this" is.  Why do you need a full-blown
CY> package to implement

CY> (dolist (f (directory-files dir t "\\.el$"))
CY>   (load foo))

That's essentially it, but we want to be able to turn it on by
customizing a variable to be a LIST of directories (defaulting to nil),
not adding code to .emacs.  All the other improvements in Ben Key's
package, including byte-compilation and recursion, are nice-to-have but
not essential to our purpose.

Ted

Re: user-controlled load-path extension: load-dir

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> That's essentially it, but we want to be able to turn it on by
> customizing a variable to be a LIST of directories (defaulting to
> nil), not adding code to .emacs.  All the other improvements in Ben
> Key's package, including byte-compilation and recursion, are
> nice-to-have but not essential to our purpose.

OK, I guess there's nothing wrong with adding a function to load
everything in a directory.  But what's the difference between having a
variable that defaults to nil and just letting users add

  (load-directory "~/.emacs.d/my-stuff")

to their init file?

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 09 Mar 2011 15:32:08 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That's essentially it, but we want to be able to turn it on by
>> customizing a variable to be a LIST of directories (defaulting to
>> nil), not adding code to .emacs.  All the other improvements in Ben
>> Key's package, including byte-compilation and recursion, are
>> nice-to-have but not essential to our purpose.

CY> OK, I guess there's nothing wrong with adding a function to load
CY> everything in a directory.  But what's the difference between having a
CY> variable that defaults to nil and just letting users add

CY>   (load-directory "~/.emacs.d/my-stuff")

CY> to their init file?

The former is easier to customize and requires no extra code to be
written.  For the el-get installer in particular it is easier and less
intrusive to customize a variable than to insert code in the .emacs.
But I am not strongly opposed to the latter.

Ted

Re: user-controlled load-path extension: load-dir

[Stefan Monnier]

> (dolist (f (directory-files dir t "\\.el$"))
                                         ^^^
                                         \\'

-- Stefan

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Chong Yidong <cyd@stupidchicken.com> writes:
> OK, I guess there's nothing wrong with adding a function to load
> everything in a directory.  But what's the difference between having a
> variable that defaults to nil and just letting users add
>
>   (load-directory "~/.emacs.d/my-stuff")
>
> to their init file?

The difference is that I'm after a solution where it's possible to
achieve that with *no* editing of the user-init-file.  At all.  So that
my el-get installer will just drop a file in `user-load-dir`.

The alternative is editing user-init-file to change the load-path and
(require 'el-get), or to explicitly (load "path/to/el-get/el-get.el"),
and that's not user friendly.

Please note that my requirement would not be fulfilled at all should the
load-directory be in a package.  What I need is to determine from code
where to place some file that will be loaded at emacs startup
automatically.  If the feature is not in code, that means I depend on
manual actions from users before to be able to have a working solution.

That would only be moving the problem, not solving it.

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Tom Tromey]

>>>>> "Dimitri" == Dimitri Fontaine <dim@tapoueh.org> writes:

Dimitri> The difference is that I'm after a solution where it's possible to
Dimitri> achieve that with *no* editing of the user-init-file.  At all.  So that
Dimitri> my el-get installer will just drop a file in `user-load-dir`.

Your use case is completely solved by package.el.  First, package el-get
as a package (trivial).  Second, have an autoload cookie in el-get that
loads the code from some directory.

Why do you think you need anything more?

Tom

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Tom Tromey <tromey@redhat.com> writes:
> Your use case is completely solved by package.el.  First, package el-get
> as a package (trivial).  Second, have an autoload cookie in el-get that
> loads the code from some directory.
>
> Why do you think you need anything more?

I'm thinking I need much less than all that.

Then I've been trying to follow your advice and turn el-get into a
proper Emacs package, as that's easy enough, right?  Turns out not to
be.

Given the following (or some variations, all based upon reading (info
"(elisp) Packaging Basics") and (info "(elisp) Library Headers"), then
the describe-function of `version-to-list' and helpers):

;; Version: 1.2~dev
;; Package-Version: 1.2+alpha1

All I get from `package-install-from-buffer' is: Package does not define
a usable "Version" or "Package-Version" header.

It seem to me that the function `package-strip-rcs-id' is buggy from
failing to use `version-to-list' and instead invents its own regexp to
match the version identifier, then returns nil which gets into an error.

I'm still thinking that a simple directory where to put files to be
loaded would be a good feature, independently of how I will fix the
el-get-installer automatic bootstrap.

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Tom Tromey]

>>>>> "Dimitri" == Dimitri Fontaine <dim@tapoueh.org> writes:

Dimitri> Given the following (or some variations, all based upon reading (info
Dimitri> "(elisp) Packaging Basics") and (info "(elisp) Library Headers"), then
Dimitri> the describe-function of `version-to-list' and helpers):

Dimitri> ;; Version: 1.2~dev
Dimitri> ;; Package-Version: 1.2+alpha1

Weird version number.

Dimitri> It seem to me that the function `package-strip-rcs-id' is buggy
Dimitri> from failing to use `version-to-list' and instead invents its
Dimitri> own regexp to match the version identifier, then returns nil
Dimitri> which gets into an error.

If version-to-list accepts that version but package.el still gives an
error, then it is a bug.  Please report it to the bug tracker, thanks.

Tom

Re: user-controlled load-path extension: load-dir

[Chong Yidong]

Tom Tromey <tromey@redhat.com> writes:

> Dimitri> ;; Version: 1.2~dev
> Dimitri> ;; Package-Version: 1.2+alpha1
>
> Weird version number.

Indeed, neither of these version strings are acceptable to
`version-to-list' (see its docstring).

Re: user-controlled load-path extension: load-dir

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 10 Mar 2011 13:56:55 -0500
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Dimitri Fontaine <dim@tapoueh.org>,
> 	emacs-devel@gnu.org
> 
> Tom Tromey <tromey@redhat.com> writes:
> 
> > Dimitri> ;; Version: 1.2~dev
> > Dimitri> ;; Package-Version: 1.2+alpha1
> >
> > Weird version number.
> 
> Indeed, neither of these version strings are acceptable to
> `version-to-list' (see its docstring).

??

  (version-to-list "1.2+alpha1") => (1 2 -3 1)

This is in Emacs 23.3.

Re: user-controlled load-path extension: load-dir

[Jambunathan K]

> If version-to-list accepts that version but package.el still gives an
> error, then it is a bug.  Please report it to the bug tracker, thanks.

This is out of thread ...

In package-tar-file-info, the following regexp is used for validating
the package name.

  (unless (string-match "^\\(.+\\)-\\([0-9.]+\\)\\.tar$" file)
    (error "Invalid package name `%s'" file))

The above regexp wouldn't catch files with the following version strings
1.0pre2 1.0.7.5 22.8beta3 0.9alpha1 6.9.30Beta.

Furthermore, if I do build a org-7.5pre1.tar, then list-packages gets
very confused about the name.

I believe some sort of auditing around numeric <-> stringified versions
of package files could be taken up.

Jambunathan K.

>
> Tom

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Chong Yidong <cyd@stupidchicken.com> writes:

> Tom Tromey <tromey@redhat.com> writes:
>
>> Dimitri> ;; Version: 1.2~dev
>> Dimitri> ;; Package-Version: 1.2+alpha1
>>
>> Weird version number.
>
> Indeed, neither of these version strings are acceptable to
> `version-to-list' (see its docstring).

ELISP> (version-to-list "1.2~dev")
*** Eval error ***  Invalid version syntax: '1.2~dev'

ELISP> (version-to-list "1.2+alpha")
(1 2 -3)

ELISP> (version-to-list "1.2+alpha1")
(1 2 -3 1)

ELISP> (version-to-list "1.2+alpha1")
(1 2 -3 1)

-- 
dim

Re: user-controlled load-path extension: load-dir

[Chong Yidong]

Dimitri Fontaine <dim@tapoueh.org> writes:

>> Indeed, neither of these version strings are acceptable to
>> `version-to-list' (see its docstring).
>
> ELISP> (version-to-list "1.2+alpha")
> (1 2 -3)

My mistake.  This is, indeed, a bug in package-strip-rcs-id.  I've just
committed a fix, thanks.

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

Chong Yidong <cyd@stupidchicken.com> writes:
>> ELISP> (version-to-list "1.2+alpha")
>> (1 2 -3)
>
> My mistake.  This is, indeed, a bug in package-strip-rcs-id.  I've just
> committed a fix, thanks.

Thanks, will test later this week-end!
-- 
dim

Re: user-controlled load-path extension: load-dir

[chad]

On Mar 10, 2011, at 6:30 AM, Dimitri Fontaine wrote:
> 
> The difference is that I'm after a solution where it's possible to
> achieve that with *no* editing of the user-init-file.  At all.  So that
> my el-get installer will just drop a file in `user-load-dir`.

I don't understand your resistance to having the installer do the editing
instead of the user. This seems like a more general solution that avoids
some potential problems and would be useful in situations where a
magic directory would not (for example, where *some* configuration
is required but easily answered by the user).

The end result seems at least as user-friendly, except perhaps in a few
degenerate cases. What am I missing?

*Chad

Re: user-controlled load-path extension: load-dir

[Dimitri Fontaine]

chad <yandros@gmail.com> writes:
> I don't understand your resistance to having the installer do the editing
> instead of the user. This seems like a more general solution that avoids
> some potential problems and would be useful in situations where a
> magic directory would not (for example, where *some* configuration
> is required but easily answered by the user).

I just frown at the idea that a *user* file is edited by anyone else
than the user, explicitly.

> The end result seems at least as user-friendly, except perhaps in a few
> degenerate cases. What am I missing?

It's not user friendly to go edit the user file from a program in my
book.  Like not at all.

Regards,
-- 
dim

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Fri, 11 Mar 2011 10:00:14 -0500 chad <yandros@gmail.com> wrote: 

c> a magic directory

There's nothing magic about the load-dir.  It's a list of directory
names, just like the load path.  Any .el files in those directories get
loaded on startup and when the user requests it explicitly.

There may be some extra rules to do with .elc files and recursion, but
both the idea and the implementation fit in a paragraph and are so
simple that calling them "magic" is misleading.

Ted

Re: user-controlled load-path extension: load-dir

[chad]

On Mar 11, 2011, at 12:41 PM, Dimitri Fontaine wrote:

> chad <yandros@gmail.com> writes:
>> I don't understand your resistance to having the installer do the editing
>> instead of the user. This seems like a more general solution that avoids
>> some potential problems and would be useful in situations where a
>> magic directory would not (for example, where *some* configuration
>> is required but easily answered by the user).
> 
> I just frown at the idea that a *user* file is edited by anyone else
> than the user, explicitly.

Emacs' configuration file has been edited automatically by emacs since 
at least version 18.43 (the first version I used regularly).  Start emacs 
without a .emacs file and hit `C-x n n y' and see what happens.

>> The end result seems at least as user-friendly, except perhaps in a few
>> degenerate cases. What am I missing?
> 
> It's not user friendly to go edit the user file from a program in my
> book.  Like not at all.

Have you ever run any Gnome or KDE programs? I think your expectations 
of `user friendly' might not match either new or experienced emacs users.

This conversation is becoming difficult for me to continue (I'm traveling),
and it doesn't seem like it's going anywhere, so I'm going to bow out now.
Thanks for working on el-get, and I hope that it all works out in the end.

*Chad

Re: user-controlled load-path extension: load-dir

[Jan Djärv]

12 mar 2011 kl. 06:51 skrev chad <yandros@gmail.com>:

> On Mar 11, 2011, at 12:41 PM, Dimitri Fontaine wrote:
> 
>> 
>> It's not user friendly to go edit the user file from a program in my
>> book.  Like not at all.
> 
> Have you ever run any Gnome or KDE programs? I think your expectations 
> of `user friendly' might not match either new or experienced emacs users.
> 

No Gnome or KDE program I know of edits user configuration files. They edit the programs private configuration file, but these aren't user configuration files
that the user is supposed to edit.

The user configures the program with a GUI interface. This is not the same as with Emacs where the user is explicitly told to edit .emacs.

     Jan D.

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 09 Mar 2011 15:32:08 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> That's essentially it, but we want to be able to turn it on by
>> customizing a variable to be a LIST of directories (defaulting to
>> nil), not adding code to .emacs.  All the other improvements in Ben
>> Key's package, including byte-compilation and recursion, are
>> nice-to-have but not essential to our purpose.

CY> OK, I guess there's nothing wrong with adding a function to load
CY> everything in a directory.  But what's the difference between having a
CY> variable that defaults to nil and just letting users add

CY>   (load-directory "~/.emacs.d/my-stuff")

CY> to their init file?

Chong, Stefan, can I take this and the lack of new posts in this thread
to mean it's OK to commit an experimental implementation of the load-dir
idea?  I don't know if Ben Key's paperwork is in progress but as you
observed it's not terribly complicated code so I can implement it in a
functionally similar way quickly (adding his work once we have his
copyright assignment).

Thanks
Ted

Re: user-controlled load-path extension: load-dir

[Stefan Monnier]

> Chong, Stefan, can I take this and the lack of new posts in this thread
> to mean it's OK to commit an experimental implementation of the load-dir
> idea?

Adding a load-directory function is OK, yes.  But please send the
corresponding patch for review first.


        Stefan

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Wed, 16 Mar 2011 11:43:09 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Chong, Stefan, can I take this and the lack of new posts in this thread
>> to mean it's OK to commit an experimental implementation of the load-dir
>> idea?

SM> Adding a load-directory function is OK, yes.  But please send the
SM> corresponding patch for review first.

First, the library.  I'm not sure about the name (`user-load-dirs-load'
sounds terrible) and I've omitted the byte-compilation stuff that was in
Ben Key's code.  It's a full rewrite of his code, which makes copyright
assignments unnecessary so we can speed up the process.

Do we want to support loading byte-compiled files?

Is the messaging too intrusive?

Also I don't trap errors.  I think that's the right approach.  These are
not packages, they are like a part of your .emacs and should be treated
accordingly.  This is also why I'm sort of avoiding the byte compilation
support, although it's pretty easy to add.

Thanks
Ted


[-- Attachment #2: user-load-dirs.el --]
[-- Type: application/emacs-lisp, Size: 3439 bytes --]

Re: user-controlled load-path extension: load-dir

[Evans Winner]

,------ Ted Zlatanov wrote ------
|    Chong, Stefan, can I take this and the lack of new
|    posts in this thread to mean it's OK to commit an
|    experimental implementation of the load-dir idea?  I
|    don't know if Ben Key's paperwork is in progress but as
|    you observed it's not terribly complicated code so I
|    can implement it in a functionally similar way quickly
|    (adding his work once we have his copyright
|    assignment).

Is it normal to scoop people like this?  It seems like a
good incentive for people not to bother trying to contribute
to a project.

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 16 Mar 2011 14:11:59 -0600 Evans Winner <ego111@gmail.com> wrote: 

EW> ,------ Ted Zlatanov wrote ------
EW> |    Chong, Stefan, can I take this and the lack of new
EW> |    posts in this thread to mean it's OK to commit an
EW> |    experimental implementation of the load-dir idea?  I
EW> |    don't know if Ben Key's paperwork is in progress but as
EW> |    you observed it's not terribly complicated code so I
EW> |    can implement it in a functionally similar way quickly
EW> |    (adding his work once we have his copyright
EW> |    assignment).

EW> Is it normal to scoop people like this?  It seems like a
EW> good incentive for people not to bother trying to contribute
EW> to a project.

I rewrote the code entirely and credited you and Ben in the headers.
The code is pretty trivial, especially after I cut out the
byte-compilation and the error trapping.  I think calling it "scooping"
is a big stretch since I proposed the idea too.

Ben's original code had naming and other issues which I didn't see
corrected.  Once it's corrected we can discuss what parts of it we need
incorporated.  But he hasn't said that he's willing to do the assignment
paperwork... and I was impatient enough to do the rewrite.

Ted

Re: user-controlled load-path extension: load-dir

[Stefan Monnier]

>>> Chong, Stefan, can I take this and the lack of new posts in this thread
>>> to mean it's OK to commit an experimental implementation of the load-dir
>>> idea?
SM> Adding a load-directory function is OK, yes.  But please send the
SM> corresponding patch for review first.

> First, the library.

Sounds like this is a package, which I'd be happy to see in ELPA, but
in core.


        Stefan

Re: user-controlled load-path extension: load-dir

[Ted Zlatanov]

On Wed, 16 Mar 2011 22:13:24 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> Chong, Stefan, can I take this and the lack of new posts in this thread
>>>> to mean it's OK to commit an experimental implementation of the load-dir
>>>> idea?
SM> Adding a load-directory function is OK, yes.  But please send the
SM> corresponding patch for review first.

>> First, the library.

SM> Sounds like this is a package, which I'd be happy to see in ELPA, but
SM> in core.

I wrote it as a library so all we have to do in the core is call
`user-load-dirs-load' (or some alias to it) after loading the
`user-init-file'.  The central point several of us have been making is
that we want `user-load-dirs-load' called automatically, not when the
package or library are explicitly loaded, to make using this library a
simple matter of customizing a single variable (the
`user-load-dirs-list').

If you and Chong don't want that, then I'll put it in the ELPA.

Ted

Re: user-controlled load-path extension: load-dir

[PJ Weisberg]

2011/3/16 Ted Zlatanov <tzz@lifelogs.com>:
> On Wed, 16 Mar 2011 22:13:24 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>>>> Chong, Stefan, can I take this and the lack of new posts in this thread
>>>>> to mean it's OK to commit an experimental implementation of the load-dir
>>>>> idea?
> SM> Adding a load-directory function is OK, yes.  But please send the
> SM> corresponding patch for review first.
>
>>> First, the library.
>
> SM> Sounds like this is a package, which I'd be happy to see in ELPA, but
> SM> in core.
>
...
>
> If you and Chong don't want that, then I'll put it in the ELPA.

I only saw Stefan say to go ahead with a load-directory function,
which I assumed would live in files.el next to load-file and look
something like this:

(defun load-directory (dir recursive)
 "Load all Lisp files in DIR.  If RECURSIVE is non-nil,
recursively call load-directory for all subdirectories of dir."
 (interactive "DLoad Dir: \nP")
 (dolist (file (directory-files dir t ".*\\.el$"))
   ;; Cut off the .el so load will pick up the .elc version if it's there
   (setq file (substring file 0 -3))
   (load file))
 (when recursive
   (dolist (file (directory-files dir t))
     (if (and (file-directory-p file)
              (not (string-match "/\\.\\.?$" file)))
         (load-directory file recursive)))))

If I'm not mistaken that's about 90% of what you want, and makes using
your own load-dir at least as easy as using your own custom-file.

-PJ