Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have used Emacs for almost 40 years and little has been as frustrating as the repeatedly broken cider packages in melpa-stable.
I have only two entries in my package list
package-archives is a variable defined in ‘package.el’.
Its value is
(("gnu" . "http://elpa.gnu.org/packages/")
("melpa-stable" . "http://melpa.milkbox.net/packages/"))
For some time before today I had been using cider-0.17.0-SNAPSHOT with the corresponding nrepl version number. But I did an update in the Emacs package manager which loaded a cider-0.17-0-SNAPSHOT with yesterdays date (22 Jan 2018).
Now starting cider with cider-jack-in in every project (10+) which was working yesterday yields a "ERROR: Unhandled REPL handler exception processing message" and a huge stack trace.
Interestingly if you replace the nrepl dependency in project.clj with an older version, e.g. [[cider/cider-nrepl "0.16.0"], cider-jack-in starts but gives the warning that cider and cider-nrepl versions differ and "things will break"
So, after many hours of work, I have gone from what was a working cider-0.17.0-SNAPSHOT system (until the melpa-stable Jan 22 update to cider-0.17.0-SNAPSHOT) to once again working cider-0.16.0 system.
So where is the corruption happening? The melpa-stable tag on GitHub is 0.16.0, yet somehow with only melpa-stable (+ gnu) in my package list the broken 0.17.0-SNAPSHOT is getting loaded.
Without perhaps a lot of Git pain I really don't need I can't find the diffs between the pre-Jan22 cider-0.17.0-SNAPSHOT and the Jan22 SNAPSHOT.
So the only option is to go back to manually installing cider-0.16.0 and going back to the corresponding nrepl version. But it was all working very well with cider-0.17.0-SNAPSHOT before someone corrupted melpa-stable with a broken SNAPSHOT.
Broken shit does not belong in melpa-stable.
How do we fix melpa-stable to be stable?
For a very long time now, CIDER hasn't needed any clojure-side configuration if you run cider-jack-in. Get rid of anything related to nrepl, and cider in your project.clj and lein profiles.clj and CIDER should start working out of the box.
Also, if you want melpa-stable then you probably also want to use the full release of CIDER, not some snaphot. CIDER 0.16.0 is what is on melpa stable now and it works fine for me.
UPDATE: I see you're actually using the straight-up melpa, which is not melpa-stable (that has "http://stable.melpa.org/packages/" as the url)
What you do wrong here is you specify Cider's version directly in you project file. Please do not do that. Every single project may require its own Cider version whereas in Emacs you may have only one version installed at once. So switching between them dynamically would be a mess.
The solution is to specify Cider package not in project.clj but in ~/.lein/profiles.clj file. Here is mine:
~> cat ~/.lein/profiles.clj
{:user {:signing {:gpg-key "........."}
:plugins [[cider/cider-nrepl "0.15.1"]]}}
In my Emacs, I've got the version 0.15.1 installed manually from the releases Git page.
This file does not affect your Git history at all. Lein tool merges it to the project.clj content automatically when it starts. Moreover, now you can work with the only one Cider installed across all of your projects. Please remove all the Cider package declarations from your project.clj files.
Once you have time, please read the official Lein profile manual.
Related
I use emacs org-mode heavily, but don't usually use emacs otherwise. I am still using emacs 25.3 but also have 26.3 installed. This evening, after a Windows Update (likely cause of the problem?), when I restarted emacs (runemacs) under 25.3 I received the following error message.
error: Required feature ‘ht’ was not provided
I have also tried running it under emacs 26.3 and receive a slightly more helpful error message "c:etc. etc. /AppData/Roaming/.emacs.d/elpa/ht-20190924.704/ht.elc failed to provide feature ‘ht’"
I have not changed or updated any of the packages in several weeks. So, it is unlikely to be a change in org-mode or emacs.
I have experimented around with a variety of different approaches but without any luck. Among other things I restored the elpa files and my customization files from a back-up of a couple of days ago without getting a different results.
package-list-package with emacs 25.3 works with the error message, and I can upgrade the packages (2) that can be upgraded. However that also makes no difference to the error message I receive when I restart emacs. This does imply that ht.elc is working since, without it, you can't install packages since the new package needs to have its hash code checked. If I delete the ht package and try to update packages without it, updates fail on the hash code check.
package-list-package with emacs 26.3 is a whole other problem which might be why I'm not using it. TLS connections fail, and it can't connect to melpa, orgmode.org, etc.
In any case, I can't load my customization files and can't use org-mode at this point. Anyone have any ideas, questions or suggestions?
Thanks in advance.
This is a solution, without being an answer.
Using package-list-packages, and looking at the details for the ht package, it showed an "alternative" version being available from melpa; same release number. So, I chose to install it and a refreshed list of packages then showed that I had the same version installed twice.
I then closed emacs and restarted it. It started with a similar error message, but this time referring to the dash package. Repeated the duplicate install process as described above.
I again closed emacs and restarted it, and now it loads and runs correctly.
I had tried previously to just delete the ht package from the elpa directory, but doing that and attempting to install a fresh package resulted in a shower of errors. I don't remember all of them but at least one of them was that emacs was unable to read the package signature.
So, problem solved, but I still have no idea why it occurred in the first place, since it had been weeks since I had updated any packages, nor why the restore of the directories from several days ago didn't solve the problem.
And before anyone yells at me about moving to the current emacs, I have now installed the missing dependencies and am running on 26.3.
After updating all installed packages via M-x list-packages, U, x, how can I easily do any or all of the following:
see a list of the packages (and their repository URLs) that were just updated
view the changelog of each updated package since the previously installed version
see a diff of the current package elisp code vs. the previous one
Only the first question can be asked easily with existing emacs packages (to my knowledge). I use pallet that uses cask to keep track of packages. Normally I just run M-x pallet-update, but to get a preview of pending updates I cd ~/.emacs.d and run cask outdated.
Pallet code might provide a good starting point to start writing code to answer the other two questions.
An other, more desperate, approach would be to try to parse the text that updating adds to emacs Messages buffer, but is not a good way to do anything.
You can't. The features aren't there. Write a feature request, or something.
I maintain a fairly well-used emacs package (ido-ubiquitous), and in the next version I plan to drop support for Emacs 23 and below. People who use Emacs 23 and below will be able to continue using the current version of my package.
However, I don't want to have Emacs 23 users upgrading via ELPA or git or something else and ending up with the new version that isn't compatible with their emacs. Is there a generally accepted way of handling this gracefully? Do I have any choice short of renaming the new version to "ido-ubiquitous-ng" or something?
ELPA/package.el
To prevent updates via package.el, add the special dependency (emacs "24.1") to the Package-Requires list. See Library Headers in the Emacs Lisp Manual, in the description of the Package-Requires: header:
[…] The package code automatically defines a package named ‘emacs’ with the version number of the currently running Emacs. This can be used to require a minimal version of Emacs for a package.
The package.el which is distributed independently for Emacs 23 and below does not provide this special package. Thus, any attempt to install your package on Emacs 23 will fail with a message complaining about “emacs” being unavailable for installation, leaving the old, compatible version in place.
However, when using this, be prepared to handle complaints from users of Emacs 24. Many users apparently do not delete their old package.el when upgrading to Emacs 24. Thus the old package.el overrides the new built-in one, leading to spurious errors on installation.
ELGet
I do not know Elget. Probably ask its author for help in this matter.
Git submodules, Tarballs and other legacy methods
I do not think, that you can really prevent updates, if users install your package in a legacy way (e.g. Git submodules, distribution packages, etc.). You can only complain after your package was updated, which is arguably too late, because the incompatible code is now already there.
You may choose to add an explicit version check, with a detailed error. I consider this superfluous, though. If you really go for Emacs 24, you will be using incompatible functions, so your package won't load successfully, whether you explicitly prevent it or not. So save yourself of superfluous code :)
TL;DR (+ personal experience)
First of all, please do not rename your package. Few users can follow the news on each and every installed package. Thus many users will not immediately realize that the package was renamed, and continue to use an outdated version without notice or warning. Effectively, you would sort of punish Emacs 24 users of your package.
Add the special dependency to prevent accidental updates via package.el. Add prominent documentation, that your package requires Emacs 24, like in the first section of your Github Readme. Then, let the matter rest. Anything else is likely more hassle that it is worth.
In my personal experience, Emacs users are not stupid (well, at least the majority isn't). They read documentation. They understand documentation.
Users of Emacs 23 know that their Emacs is outdated. Many of them expect incompatibilities and breakage. If the package suddenly breaks for them, they will seek advice on Github, realize that the package is not available for Emacs 23 anymore, and either go back to the last working release, or (hopefully) upgrade their Emacs.
I have a working Clojure-1.4.0 / emacs24 / leiningen-2.0 tool chain working on Mac OSX 10.8. I got it going very quickly by following the instructions at the following URLs:
http://clojure.org/getting_started
https://github.com/technomancy/leiningen
http://clojure-doc.org/articles/tutorials/emacs.html
One way I check that it works is I go to a project directory and type
lein test
and it runs all the unit tests in my project directory. I can also do C-c , in clojure-mode in emacs, and it does the same thing. Great! Now the question: all this runs the clojure installation I have in ~/clojure-1.4.0, which I see by typing
lein repl
in a project directory. I have a new installation of clojure in ~/clojure-1.5.0 now, and I would like to make leiningen and emacs point to that new version. However, during the setup of leiningen and the emacs mode, I never manually told them where to find the clojure version. They found that magically and opaquely -- in fact, the whole process was very magic, and that was great at that time. I suppose I could tear everything down and build it up again from scratch, but that seems brute-forcedly inefficient. I could also hack-replace the files in the 1.4 directory with the files from the 1.5 directory. That might work one time, but it's so obviously wrong I really don't want to think about it. I need to do this the right way so that when the next version updates come along, I can keep the toolchain going as smoothly as possible.
I am just starting with all this, so I am far from mastery of any of these tools and I'll be grateful for noob-level advice on keeping it all going.
Just change clojure version in ./project.clj in your project directory:
:dependencies [... [org.clojure/clojure "1.5.0"] ...]
test:
$ lein repl
user=> *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier nil}
Edit:
They found that magically and opaquely
Default clojure version is built into lein's project.clj template which renders to your <name>/project.clj file when you do lein new <name>.
For a couple of years I used to use the sierotki.el package (NonbreakableSpace) in Emacs for my LaTeX writing. It worked very well in my configuration (Ubuntu 12.04, emacs 23 or emacs 24 (24.2.1)). Some time ago I've installed the emacs-snapshot (emacs 24.3.50.1) (from ppa:cassou/emacs ppa) and sierotki.el doesn't work anymore (without any errors).
Anybody knows what is wrong?
For the sake of completeness, the package just inserts ~ (nonbreakable space in LaTeX) after one-letter words (like I, a in English, or many others in my native language).
The reason is that sierotki.el used to use the variable last-command-char, which was changed to last-command-event in more recent Emacsen. You might want either to upgrade sierotki.el (I contacted the author some time ago with this fix, and he applied it), or fix it yourself.