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.
Related
I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.
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.
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.
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.
Is it possible to remove built-in Emacs packages like "tetris"? They can't be marked to be deleted in package list as of 24.1. It would be nice to have a minimal installation of Emacs - even though barely useful - by deleting some or all built-in packages. Is it possible to do somehow, and will this ability added in future?
Emacs should start and be useable even if the whole lisp directory is empty (note that we rarely/never test it, so I don't guarantee that it'll work, but at least in principle it should and if it doesn't you should report it with M-x report-emacs-bug). So feel free to remove any and all packages in there you don't find useful, in order to create a trimmed-down version of Emacs.
You could just remove the elc files of all of the packages you want.
For example, in the version of emacs located in the ubuntu repository the tetris package is located in:
/usr/share/emacs/23.3/lisp/play/tetris.elc
If you move or remove it, emacs will continue to work, but you won't be able to play tetris anymore.
You might want to inspect the package--builtins variable. That said - there is little sense in removing any packages installed via package.el since package.el extracts and loads automatically only a package's autoloads - therefore having many installed packages doesn't result in any significant overhead. I'm quite certain that removing built-in packages will never be a feature of package.el.