One of the design choices in package.el was to try and make things "simple". Part of this is that package-initialize searches for all the packages that are installed, then tries to figure out which ones of those should be activated (according to pinning, and recency of versions in case where multiple versions of the same package are available), then loads ...
So when you read this warning message:
Warning (initialization): Your `load-path' seems to contain
your `.emacs.d' directory: ~/.emacs.d/
This is likely to cause problems...
and note that you have the following in your init file:
(add-to-list 'load-path "~/.emacs.d/")
hopefully you can recognise that this is exactly what the warning was referring to?
github.com/altercation/solarized.git is the repository for the Solarized theme for vim.
For emacs, the repo is https://github.com/bbatsov/solarized-emacs.
The recommended approach to install the theme is via the emacs-inbuilt package manager.
Ensure that you have the below in your emacs setup (~/.emacs.d/init.el by default):
;; Add ...
The problem you describe about package-initialize taking so much time to load is a well known problem. It is also one of the problems that some emacs frameworks try to solve by loading the autoloads manually.
I see two solutions to your problem.
Write (or extract from a framework) the functionality to set the paths and load the autoloads of the packages ...
By default the .elc would be loaded rather than the .el, as noted in the other answers/comments.
A few things can affect this behavior, however:
Set load-prefer-newer to t if you want to load whichever file is newer. In that case the .el will be loaded if it has been modified more recently than the corresponding .elc file.
See the variable load-suffixes, ...
Adding to the load-path does not actually load any files. Instead, it only tells Emacs where to look for files when you ask it to load them. As the docstring indicates:
List of directories to search for files to load.
Each element is a string (directory name) or nil (try default directory).
Initialized based on EMACSLOADPATH ...
What you are looking for is
(add-to-list 'load-path "~/Projects/modules-test")
The best thing you can do is C-h v load-path RET and follow links in the *Help* buffer.
But if I do a load-file on calctest.el, then do (require 'calctest) it "sees" it and "loads" it (again?).
No, the key point is that it doesn't load it.
When you load-file your calctest.el library, the (provide 'calctest) form is evaluated and remembered, which in turn satisfies any subsequent call to (require 'calctest) -- regardless of whether or not it ...
I had a similar problem with my installation, but I'm using the command org-babel-load-file to load an org file as init file.
What I believe it was causing the problem (might not be it) is that org was not initialized when I need it to compile the pointed org file. Therefore, I called it!
;; This is my init.el localed on .emacs.d/
You are right in assuming that the location is wrong. Emacs does not know about your niranjan directory. You assume that ~/.emacs.d/elpa/ is a special location and that emacs automatically knows how to add packages installed in there.
If you look at the contents of the variable load-path, you'll see that is not the case. Every package that has been ...
The version that works best for me is on MELPA at
In your packages install, you can install it through MELPA using this command:
M-x package-install solarized-theme
If you can't find solarized-theme, then make sure MELPA is installed properly.
Repeating my response at S.O. -
Put (setq debug-on-error t) at the beginning of your init file. Or better yet, append --debug-init to the command line you use to invoke Emacs. That will open the debugger when the error occurs. But it seems that the file that has (provide 'autocomplete) in it, or that file's directory, is not in your load-path. When the ...
When I tried setting load-path in a let to the current directory, it wouldn't load any of the files.
Make sure that load-path is still a list, and not just a directory path string.
(let ((load-path (list "/path/to/directory")))
and never this:
(let ((load-path "/path/to/directory"))
In addition, remember that libraries very ...
Evaluating lisp expressions in the minibuffer (or in the scratch buffer, or with C-x C-e in an emacs-lisp buffer, or loading lisp libraries by hand with M-x load-file or ....) only affects the current session of emacs. The moment you kill this emacs session everything that is not part of the initial emacs state is lost irretrievably. So even if you (add-to-...
Global variable load-history records the files you've loaded (no matter how), and the definitions they contain.
Assuming you know the file name of the file that provides the feature, you can use this, where FILENAME is the file name as a string.
(load-history-filename-element (load-history-regexp FILENAME))
C-h f load-history-regexp:
load-history-regexp is ...
the error message Searching for program: No such file or directory, rcs,
This means Emacs can't find the executable called rcs. You need to install it through your OS package manager, or build it from source: https://www.gnu.org/software/rcs/rcs.html
You don't need the rcs.el package, as Emacs' builtin vc-rcs will already handle it.
exec-path is where subprocesses find executable files. so your emacs should be able to find the executable. However, require is looking not for the executable, but for hindent.el (or the coresponding compiled file hindent.elc) which is the emacs lisp interface to hindent. You have to modify load-path for that (or put hindent.el in one of the directories that ...
The solution to this issue was not in the flycheck load path. Instead, the variable warnings were showing up because the contents of the (require 'my-dcls) were not providing declarations that the byte-compiler liked.
I thought that the following syntax would work, as was suggested in this earlier thread:
;; a reference declaration, so no value was set
AFAIK, there is no 'proper' way of doing this. What I use in such cases is not load but require. Every private layer that has such configurations files (features / packages) has a folder named extra. And I just add that folder to load path using add-to-load-path. After that I use require to load configurations inside of :config just like you use load.
Why will a require not simply load my calctest? What am I missing here?
Perhaps the path and a restart. require works only if the package is in the load-path. require also does some filename guessing based on the feature name. Restart Emacs may be required to trigger the re-loading.
You can re-add /usr/share/emacs/24.5/lisp/ to the start of the load-path by doing something like this
(push "/usr/share/emacs/24.5/lisp" load-path)
While this will work, this is system/installation dependent, I found one installation independent way to get path to lisp startup.el
(expand-file-name "../lisp" data-directory)
Combining these together the ...
(defconst additional-lisp-dir (expand-file-name "plugins" user-emacs-directory))
(add-to-list 'load-path additional-lisp-dir)
;; Add subdirs to load-path
(let ((default-directory additional-lisp-dir))
This way you'll add only the top level directory and subdirs will be added automatically
It's alright if package installs a different helm version.
The important part is which version gets require'd first.
So if you put your (require 'helm-config) earlier than package does,
Just to make sure that you have to correct one:
(add-to-list 'load-path "git-helm-path")
It seems from your comments is that your ...