edebug: Step-by-step debugging of Elisp code.
checkdoc: Learn about style errors in your comments and docs.
elint: Linter for Emacs Lisp.
paredit: Manipulate lisp code as trees instead of lines. Never have unbalanced parentheses.
lispy: vi-like alternative / superset of paredit. Additionally includes shortcuts
for outlines, narrowing, edebug, ...
Local packages are put in extensions.el instead of packages.el. There are two lists in an extensions.el file:
<layer>-pre-extensions which are loaded before packages.el
<layer>-post-extensions which are loaded after packages.el
Local packages are put in the folder extensions within a sub-folder whose name is the name you put in one of the two ...
First, you should never modify the code in master branch, Spacemacs is designed to be hackable while keeping the master branch read-only, also not that force pushes to master branch may happen!. If you really want to modify the code you should use the develop branch and keep it up to date manually. Develop branch is never forced push.
EDIT: actually you ...
The package-load-list variable can be used to specify precisely which packages and versions to load:
List of packages for `package-initialize' to load.
Each element in this list should be a list (NAME VERSION), or the
symbol `all'. The symbol `all' says to load the latest installed
versions of all packages not specified by other elements.
For an element (...
To chime in with a slightly different work flow for loading different versions of packages, here's a couple of variations of what I do, both of which use the load-path to control which version I'm using (changing the name of the package is a bad idea if there are dependencies). I have the current version of "nice-package" installed in ~/.emacs.d/elpa using M-...
Emacs 25.1 now has this feature. From the NEWS file:
** package-install-from-buffer and package-install-file work on directories. This follows the same rules as installing from a .tar file, except the -pkg.el file is optional.
There are no new commands to remember. Just issue package-install-from-buffer from a dired buffer, or invoke package-install-file ...
The correct solution (IMO) is to use a package manager which has explicit support for this use case. This would be straight.el, which I wrote for this purpose.
You can read verbose documentation, including comparisons to other package managers, in the README, so I'll stick to how you can use straight.el to solve your specific problem.
Place your repository ...
I believe this is a great question considering elisp seems to be a language that's geared to be easy to learn, yet not a language many people manage to master (as in, learning how to do anything in it the best/most appropriate way possible).
You can ask for feedback on specific issues on the #emacs IRC channel on the Freenode network. Perhaps the chats on ...
An option that would work well in contexts where the developers working on reproducing the bug may not already have (or want) those dependencies installed is to use the try package (https://melpa.org/#/try). Others can load a packages from package management without modifying their local installation.
To add to what @Malabarba said, I think the problem here is that smartparens should provide an API that does not rely on a macro.
The "normal" way this works with usual packages is that the major mode can just do something like:
(when (boundp 'smartparens-thingies)
(push mythingies smartparens-thingies))
(setq smartparens-extra-thingies ...
I think the answer is that you're looking at the wrong place: try to solve the more general problem where the user installs your package maybe by hand, or via some other package system, or via ELPA but in a 100% automated way (so he won't see any message that may show up at that point).
IOW do it with code within your package, which tries to recognize the ...
Good question! The answer is that until now, there was no good answer, since none of the existing package managers were designed for this use case (except for Borg, but Borg does not attempt to handle other common package management operations like dependency handling).
But now, there is straight.el, a next-generation package manager for Emacs that ...
This use case is a terrible deficiency of package.el, so don't use package.el. Instead, use a package manager like straight.el (I'm the author), which was specifically designed to support this use case.
For verbose documentation on straight.el, including comparisons to other package managers, see the README. Below, I've quoted the section that is relevant ...
There's no "best practices" for that, no. Nor any kind of existing support for it. I think if it's installed specifically for package Foo, then the place to install it would be within the directory of package Foo.
As for how to do it, asuming your Elisp package is installed via ELPA, then you might want to try to add in your main Elisp file something ...
You might also get some useful feedback by creating a page on Emacs Wiki about your package (and explicitly encouraging feedback!). You can also post the code itself to the wiki, in its Elisp Area. I, for one, have received lots of useful feedback for code I've posted to the wiki.
Is there a way to include this kind of "maybe evaluation" in a byte-compiled file, without confusing the byte-compiler? For example, is it possible to tell the compiler "do not compile this form"?
Yes, you can quote it and then eval it: (eval '(sp-whatever ...)). This will not be seen by the compiler and will only be expanded at runtime.
Or what would be ...
I do the following on Linux:
I setup a local melpa repository by cloning melpa.
I modify the recipes I want to point to my local packages. The following is local-melpa/recipies/ace-window
Then from local-mepla type make all or make recipies/ace-window to build the package(s) ...
You can maintain your own package archive locally. It's not much more than a directory containing your packages. You just need to make sure you have an entry for it in your package-archives variable.
The easiest way is to use a library called package-x which will help you maintain such a local archive. The preliminary steps are :
Load the library: (require ...
An MIT license is clearly fine, since it is compatible with the GPLv3+.
What is less clear is whether it would be legal to release an Elisp package with a license that is not compatible with the GPLv3+ (e.g. a proprietary license).
I believe it wouldn't be legal unless you can show that this package also works with some other non-GPL'd implementation of ...
It was on MELPA. It's not on MELPA anymore because MELPA doesn't want to pull from Emacs Wiki anymore. It's on Emacs Wiki because that's where I prefer to upload it. And it is a "package" - a single library.
If you want to use it, just (1) download it from the wiki, (2) put it in a directory that's in your load-path, and (3) do (require 'hl-line+).
This is just an idea (I've never seen it done), but you can push it to a Github repo, open an issue requesting feedback, and then post a bounty on the issue.
If you do that, you'll want to be very descriptive of what you're looking for in your bounty and probably announce it somewhere like r/emacs, our chat room, and/or #emacs IRC channel.
I don't think there's a good answer to that yet (I expect you can get a partial solution with Cask, tho I'm not sufficient familiar with it to give you a good answer using it; hopefully someone else will), but here's what I do (I rarely use a Elisp package without making local changes to it, so it's really my "normal" way):
cd ~/src; git clone ..../elpa.git
These are all good questions!
Emacs works on a memory-image model, where loading new code alters the memory image of the running instance. Defining new functions and variables is easily undone, if you keep a list of them, but there are a lot of side effects a module might have that you would want to undo. It looks like unload-feature does make a pretty good ...
The other answers to this question, including my other answer, talk about patching an Emacs package by making changes to its code. But people finding this question via Google might be thinking of something else when they say "patch an Emacs package" -- namely, overriding its behavior without having to modify its source code.
Mechanisms for doing this ...