GNU ELPA is the official GNU Emacs package repository. It's the only one enabled by default, which means that it has the greatest reach. At the same time, submitting a package there is a bit of a hassle and requires an FSF copyright assignment, which means it has a relatively limited selection of packages.
MELPA and Marmalade are both third-party package ...
There's no automatically generated manifest file that you can synchronize to achieve the desired effect.
That said, something you can do is add calls to package-install in your emacs configuration itself.
The idea is that package-install is idempotent, so if the package is already present, nothing will actually happen.
First of all, ELPA is the name of a specification, the Emacs Lisp Package Archive. There's three widely known implementations of that specification, GNU ELPA, Marmalade and MELPA.
GNU ELPA is the official GNU Emacs archive, enabled out of the box for sufficiently new Emacs installations. It is comparatively small, contributing to it requires copyright ...
The way I think of it, some repos have more overhead involved with submitting packages than others; the repos with more overhead tend to have fewer packages. In order from most to least overhead:
GNU ELPA requires all code to be GPL'd and copyright assigned to the FSF. ELPA code is essentially "owned" by the core Emacs team, so there's much less of it than ...
restclient is the most "interactive" mode.
This is a tool to manually explore and test HTTP REST webservices.
Runs queries from a plain-text query sheet, displays results as a
pretty-printed XML, JSON and even images.
You can check a workflow example at http://jakemccrary.com/blog/2014/07/04/using-emacs-to-explore-an-http-api/.
request.el - HTTP ...
I ran into this the other day. I think it was caused by an invalid package archive file. The immediate fix is to delete <user-emacs-directory>/elpa/archives/melpa/archive-contents; it will be rebuilt on the next package-initialize. Unfortunately, package.el is not very robust to this sort of failure.
I keep my .emacs.d directory in version control. Then, in my init.el and subsequent files I use use-package to define package setup. Not only does use-package lazily load your packages, it will download them on demand if they don't exist from whatever package repos you've set up.
For example, I use go-mode, but not on every machine. In my init.el I have ...
Use the option package-archive-priorities which was made for this very purpose. To prefer MELPA Stable over MELPA, add the following to your init file:
'(("GNU ELPA" . "https://elpa.gnu.org/packages/")
("MELPA Stable" . "https://stable.melpa.org/packages/")
("MELPA" . "https://melpa.org/packages/"))
There are several package repositories available.
GNU ELPA is the official package repo.
It's small, and requires copyright assignment (of all authors of a package) to the FSF to contribute to it.
Packages on GNU ELPA are really just a git repo. The advantage of being hosted here is that the core team try to update packages if Emacs itself adds ...
The built in way to do this is with registers.
For instance use C-xrwa to save the current window configuration to register a.
Then you can use the built in binding C-x1 to run delete-other-windows
after you're done looking at the single file, use C-xrja to pop back to the saved window configuration in register a.
C-xrwa (save config into ...
Add the following line to the top of your init file (.emacs.d/init.el or .emacs):
Creating more of the files which Emacs might use as the user-init-file is definitely not the right approach. Because the manual doesn't say which is preferred in case there is a conflict, at least not in the part you quoted, all ...
Old question, yes... But in the event that anyone Googles this; another option is using Org Babel and ob-http... (Can be installed from melpa.)
With org-babel, you can make an .org file containing "http" code blocks. When these blocks are evaluated, they will make the HTTP request and return the response as the result.
If these blocks have a "#+NAME:" ...
I use winner-mode. Here's my setup:
(global-set-key [f7] 'winner-undo)
(global-set-key [C-f7] 'winner-redo)
(global-set-key [f9] 'delete-other-windows)
(global-set-key [C-f9] 'delete-window)
I don't know if there's a way to bookmark a layout or something, but being able to
continuously switch back to previous layout is enough for me.
You can find information about this package on the Debian webpage, which includes this:
This package contains the architecture independent infrastructure that is not compliant with the Debian Free Software Guidelines. In particular, this includes some of the GNU Emacs info pages, as they are covered under the GFDL, and specify invariant sections.
That is ...
I think the only honest answer is "because we can".
According to history, the first entry lisp/play/studly.el for the GNU Emacs repository was created in 1986. Then over the years, a few additions were made, including yow.el by RMS in 1990.
The hacker spirit has always been very compatible with (silly) games, and using software (like Emacs) for something ...
The problem you're referring to is probably that when you upgrade a package from within an Emacs session where that package is already in use, the old version of the package will sometimes interfere during compilation of the new version, leading to miscompiled files.
There is a tentative fix for that in Emacs-25, but AFAIK the problem is still present in 24....
The following is now part of the Paradox package. Just invoke paradox-upgrade-packages.
This should do it.
(defun endless/upgrade ()
"Upgrade all packages, no questions asked."
Just check which function is called by each ...
TLDR; You have to start the http server (simple-http) and load your HTML files through it.
<!-- Include skewer.js as a script -->
The correct way to do this with use-package is as follows:
The first argument makes sure that it is the org.el file being sourced. The :ensure argument makes sure that you are getting the version with all the extras. Of course you also need to have ("org" . "http://orgmode.org/elpa/") in your package-...
With your current configuration, you've effectively disabled package.el, as you don't initialise the package manager and prevent Emacs from automatically initialising it. All you do in return is to add ELPA to the load-path, but that's just a small subset of what package.el does. I'm not sure why you do that, but it's not a setup that I'd recommend.
FWIW - I had this issue with the signature org-20140407.tar.sig. Like Sigma's package-check-signature is/was allow-unsigned.
I changed the package-check-signature value to nil and the problem was resolved.
They are different if the package is deferred, i.e. not loaded until it is needed. In that case :init will be executed at the time your emacs file is first read, but :config will be executed at the time the package is actually loaded.
In your example, the use of mode implicitly defers loading the package. You have configured the package to be loaded the ...
Some additional info, to supplement the other answers here.
Some info about MELPA and MELPA "stable" -
Start by looking at this pretty-much duplicate question, from StackOverflow, including the comments for the question itself. In particular, this comment that I posted, after exchanging email with Donald Curtis (maintainer of MELPA and MELPA stable):
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 ...
I can recommend Ruby Mode in ruby-mode.el and Python Mode in python.el, for some aspects of their implementation. The former is a particularly great source for advanced indentation and navigation code based on the new SMIE engine. However, neither uses data structures in any particularly clever or advanced way.
I would also recommend some parts of Org ...
Your problem is that the package eclim as a dependency on the package s, so when you require eclim, you need to have s in your load-path. package-initialize ensure that every installed package are in you load-path, and load them too, so:
you don't need to require eclim when you call package-initialize
you need to add s to the load path if you don't call ...
You can't directly write an Emacs package in Java. There is currently no way to extend Emacs in Java, nor is there a Java to Elisp transpiler.
It's common, though, to have Emacs run other programs to do work for it. You could write a helper program like this in Java. Whether this makes sense depends on what exactly you intend to do.
Emacs' built-in package manager, and thus use-package as well, automatically installs the latest version a package, across all repositories. Normally, that means packages are installed from MELPA, because MELPA serves the highest version numbers.
However, from Emacs 24.4 onwards you can pin individual packages to specific archives with the :pin keyword: