I'm running Emacs 24.4 for Windows (installed through Chocolatey) and trying to install CIDER.
When I run M-x package-install [RET] cider [RET], I get [No match]. When I run M-x package-refresh-contents [RET], it hangs on Contacting host: elpa.gnu.org:80.
~/.emacs.d is populated with the GitHub repo recommended by braveclojure.com (here). I've reinstalled Emacs and I'm still getting the same problem.
I had this same problem on emacs ELPA wiki they say to set un ELPA you have to modify the emacs init file located at ~/.emacs or _emacs or ~/.emacs.d/init.el for me it was ~/.emacs-live.el since I have this version.
I just updated that file with the following:
(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")
("melpa" . "http://melpa.org/packages/")))
Seems that I needed the configuration from where ELPA is going to look for packages.
After that i just ran M-x package-refresh-contents [RET] and M-x package-install [RET] cider [RET] that installed cider.
This guide fixed it for me: http://www.lonecpluspluscoder.com/2015/08/adding-tls-support-to-emacs-24-5-on-windows/
Basically go to: http://sourceforge.net/projects/ezwinports/files/, grab the gnutls library and just uncompress the archive at the root of your Emacs directory.
Afterwards, doing list-packages became near-instant for me. Using Emacs 24.5.1.
I had the same problem with Emacs 24 in Ubuntu 16.04 and nothing seemed to solve the problem. Finally, installing Emacs 25 solved the problem.
New Emacs packages are available here
sudo add-apt-repository ppa:kelleyk/emacs
sudo apt-get update
apt-get install emacs27
The problem is that the ELPA package signing key has expired. A new Emacs version will include a new key. Note that currently (2020 Oct) there is Emacs 27 available for Ubuntu 16.04.
Also make sure that you use https urls (and not plain http).
Another possibility may be to install new keys to an older Emacs version.
Windows binaries may also be available somewhere.
Other than setting up your package archives, like a previous answer mentions (FWIW I'm using HTTPS directly)
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
("marmalade" . "https://marmalade-repo.org/packages/")
("melpa" . "https://melpa.org/packages/")))
one might encounter another problem but with the same symptom of getting stuck at "Contacting host" due to running gpg in batch mode to verify the packages, but needing some input. You can disable that via
(setq package-check-signature nil)
Stack Overflow sometimes deletes chats. Fortunately it seems like I've still got access to a read-only version of the transcript.
From my perspective we didn't get a satisfactory answer. Here are the highlights:
We determined that the variable package-archives contained only GNU ELPA.
After discovering this, the OP wrote
I edited the package.el file. It works!
I suggested that editing a core Emacs Lisp file is not a good solution, but didn't hear anything back from the OP.
Since the referenced init.el file tries to add MELPA, I think there's something else going on. Perhaps the .emacs.d/ directory is in the wrong location, for example.
Editing package.el is certainly not a good solution. Doing more work to determine why the config isn't being properly loaded would be a good approach.
I have faced this issue on Emacs 24.5.1.
I searched here in SO and outside SO, nothing worked for me. I had to circumvent the problem by installing a newer version of Emacs: emacs25.
Related
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
I'm aware a lot is involved in getting autocomplete to work in emacs, including:
auto-complete
company
flymake
I am not sure which components are responsible for which aspects. What is the package that when I start typing...
fmt.P
Would finish with
fmt.Println
?
I believe I have company as my auto-complete, and at present, if I start:
fm
It finishes fmt, but
fmt.
Produces nothing, and
fmt.P
Produces
fmt.package
Which is entirely wrong. What package should I investigate to understand what is going on?
Autocomplete, company-mode, flymake, oh my. I recommend you uninstall all of the above and use Emacs' native completion instead:
install gocode and make sure the binary is in Emacs' PATH;
install the go-complete package in Emacs (I got it from melpa, but you may prefer to install it manually);
add the following to your .emacs:
(add-hook 'completion-at-point-functions 'go-complete-at-point)
press M-TAB in a go-mode buffer.
Since the original answer was written, the original gocode has ceased being maintained. While there exist forks of gocode that work well with recent versions of Go, the recommended replacement is golsp
Install the eglot pakage from ELPA (not necessary if you are running Emacs 29 or later, which includes eglot out of the box).
Install golsp and make sure it is in your path.
Add the following to your .emacs:
(add-hook 'go-mode-hook #'eglot-ensure)
Press M-TAB in a go-mode buffer.
rlwrap is a good program handling arrow keys in REPL loop. In most cases it works. For example rlwrap sbcl, rlwrap sml, and so on. But when it comes to rlwrap coqtop, it fails. The error information is below.
rlwrap: error: Couldn't read completions from /usr/local/Cellar/rlwrap/0.41/share/rlwrap/completions/coqtop: No such file or directory
I downloaded coqide from coq website, and installed rlwrap using homebrew. The file /usr/local/Cellar/rlwrap/0.41/share/rlwrap/completions/coqtop is at the right place. So, is there any clue how to fix this? Or is there a replacement software out there?
This is a bug that has been fixed for the upcoming rlwrap 0.42.
If you don't want to wait for an upcoming release, you can always get the newest source from github (https://github.com/hanslub42/rlwrap)
What I'd like is to be able to use emacs and auctex successfully.
Some system information:
ProductName: Mac OS X
ProductVersion: 10.8.5
BuildVersion: 12F45
Emacs
Version 24.3 (9.0)
AUCTeX-version is a variable defined in `tex-site.el'.
Its value is "11.87"
There's two things that I've tried. First, installing auctex interactively from within emacs as recommended:
M-x package-list-packages RET
On the surface things seem to be working as expected:
\documentclass{article}
\bein{document}
Hello world
\section{Here lies a section}
Hello people.
\end{doument}
You can't see it in the code, but on my emacs screen the syntax highlighting is working, and the auctex icons are visible. Also environment completion commands work expected (like filling in \begin and \figure stuff). Now issuing the compile command:
C-c C-c
I get the following message:
LaTeX: problems after [0] pages
looking at the source there is two mistakes that are not picked up, furthermore it seems like the document is not even compiled even if there are no mistakes, there is no dvi or pdf or aux files created. Also testing the viewing functional, nothing happens. So it seems like something isn't configured properly.
Second, without uninstalling or removing auctex (which I suspect could have to do with something but I'm not sure as we'll see later) I found the webpage: http://algorithmicallyrandom.blogspot.com/2012/08/getting-auctex-working-on-mac-os-x.html That recommends building from source:
*) ./configure --with-emacs=/Applications/Emacs.app/Contents/MacOS/Emacs --disable-preview --with-lispdir=/Applications/Emacs.app/Contents/Resources/site-lisp/
*) make
*) sudo make install
Then add these lines to your .emacs file
(load "auctex.el" nil t t)
(setq TeX-auto-save t)
(setq TeX-parse-self t)
(setq-default TeX-master nil)
(add-hook 'LaTeX-mode-hook 'visual-line-mode)
(add-hook 'LaTeX-mode-hook 'flyspell-mode)
(add-hook 'LaTeX-mode-hook 'LaTeX-math-mode)
(add-hook 'LaTeX-mode-hook 'turn-on-reftex)
(setq reftex-plug-into-AUCTeX t)
Something that makes me think this installation was successful is the source I downloaded is for version 11.87 and thats the version of auctex that I'm currently running. However, the same behavior continues, basically none of the compiling or viewing functionality seems to be working.
Another thing, from reading around it seems like you also need the preview-latex.el package, when including it in my .emacs file
(load "preview-latex.el" nil t t)
I get an error so I'm pretty sure that package isn't installed properly. So my question is mainly, what am I missing here? How can I successfully run emacs and auctex (and maybe the preview-latex.el package also) together?
Maybe this includes removing auctex completely and installing it again. How do I remove an emacs package when I installed it interactively (try one)? How do I remove the emacs package when I installed it from source (try two)?
Also its possible that I haven't installed ghost script but I'm not sure how to check.
Man, I know this is a lot, I'm trying to provide any information that is required. If you've waded through this and can help me I'd be so grateful.
You may need to configure emacs to recognize shell path. To do that, simply install exec-path-from-shell package. There is some help from the following link.
PATH and exec-path set, but emacs does not find executable
A comment from #lawlist helped me:
Do you have texbin in your $PATH? If not, you could add this inside
your .emacs or init.el file:
(setenv "PATH" (concat (getenv "PATH") ":/usr/texbin"))
I know Emacs has some sort of integration with gdb (though I never used it) to jump through files as you debug a program. I'd like to do the same with Ruby programs.
As erenon said, use ruby debug, which provides a library for emacs that lets you use it just as gdb.
Install rdebug by issuing this command on your terminal(the sudo is optional, depending on your system):
<sudo> gem install ruby-debug
You then need to download the ruby-debug-extra file from rubyforge, and install it in the standard way.
sh ./configure
make
make test # optional, but a good idea
sudo make install
This gives you the elisp files for the interaction with rdebug, plus documentation for ruby-debug that can be viewed from within emacs.
AJ
There is another emacs to ruby-debug interface. See https://github.com/rocky/emacs-dbgr/wiki .
More generally, it works with other ruby debuggers and other debuggers in general.
You may want use rdebug.
I am getting "Cannot open load file: gdb-ui" in GNU Emacs 23.1.50.1 (x86_64-apple-darwin10.0.0, NS apple-appkit-1038.11) of 2009-10-31
I was stuck with same problem with gdb-ui, but I found the solution: I downloaded gdb-ui.el from here and put it into ruby-debug-extra/emacs dir... then I've adjusted Makefiles to point to this file before any other rdebug*.el files. After this step you'll get make working. Since I'm using emacs-snapshot and gdb mode is available already in my emacs environment, this issue is only about to build rdebug mode. After this I've installed it with "sudo make install" and it works perfectly :) Don't forget to add (require 'rdebug) to your ~/.emacs or whatever else you use to bootstrap your config.
The chosen strategy can be made to work, although texi2html and texinfo were not enough on my system, but I stopped pursuing this strategy without installing the extra packages.
Here's what I did: download ruby-debug-extra-0.10.4.tar.gz from http://rubyforge.org/frs/?group_id=1900&release_id=28306, untar it, but DON'T do the whole configure/make/blah/blah thing. Instead, I simply copied the 'emacs' directory to ~/.emacs.d/rdebug, and then added to my ~/.emacs.d/init.el file (you can also use your ~/.emacs file):
(add-to-list 'load-path "~/.emacs.d/rdebug")
(autoload 'rdebug "rdebug" "ruby-debug interface" t)
This won't byte-compile it, I didn't care. I prefer this solution because I got really annoyed that the packages forces you to install the docs.