I've got 129 packets from marmalade-repo.org , many of which list Marmalade package entries, in my Wireshark log. I'm not behind a proxy and HTTP_PROXY is unset. And ELPA (at 'http://tromey.com/elpa/') works fine.
But I get:
Failed to download `marmalade' archive
every time.
I'm on Max OS X Mavericks, all-up-to-date, with Aquamacs, and using the package.el (byte-compiled) as described here: http://marmalade-repo.org/ (since I am on < Emacs 24).
M-x version:
GNU Emacs 23.4.1 (x86_64-apple-darwin12.3.0, NS apple-appkit-1187.37) of 2013-06-13 on acs-trailblazer.ist.psu.edu - Aquamacs Distribution 2.5
What are the next troubleshooting steps I should take?
I've taken Aaron Miller's suggestion and fully migrated to the OS X port of Emacs 24.3 .
I do miss being able to use the 'command' key to go to the top of the current file, and the slightly smoother gui of Aquamacs, but it's no doubt a great port. Due to the issue with Marmalade, Emacs 23.4 won't work with some of the packages I now need (unless they were hand-built).
Related
I have an init.el file which only consists of a single line
(require 'package)
I am running emacs 23.1 on Red Hat Enterprise Linux Server Release 6.10 (Santiago)
Execution of emacs --debug-init returns the following screen:
I have absolutely no clue as to what this means.
This was actually a very preliminary step to following the instructions on setting up elpy as IDE for python... After I had no success in using the standard mode with python3 instead of just python
Could it be that these machines cannot access the internet?
package.el is not part of Emacs 23. You can obtain it here, I believe. (That's
https://github.com/technomancy/package.el.)
No idea whether that version of the library is compatible out of the box with Emacs 23.
But you get the idea - search for package.el online, download it, and put it in your load-path. Then your require should pick it up.
After I have updated my Emacs from 24.3 to 24.5 version, my 1.1 version of cedet (highlight, auto completion and summary function) has stopped working for c mode. When I trying to load these semantic mode individually, I got the following messages:
Buffer myfile.cpp was not set up for parsing
I think someone has asked a similar question in the past:
cedet-semantic error "Idle Service Error semantic-idle-summary-idle-function - Arithmetic error" when parsing linux kernel file "jiffies.h"
However, I am not sure which snapshot version he has downloaded & how to install a snapshot CEDET version. Can someone please help me with that?
After struggled for a while, I figured out something trivial but hard to see. Hopefully this answer will help others who has experienced the same problem.
When I started to use emacs version 24.3 I didn't know the Cedet version 2.0 was already a built-in package at that time. I downloaded Cedet 1.1 version from
Cedet SourceForge website.
And configured that according to some tutorial online by loading my downloaded 1.1 cedet.el file.
Surprisingly this Cedet 1.1 package is still compatible with emacs 24.3 version. Unfortunately this is not the case for emacs 24.5 version, the semantic mode encountered some problem with c mode. Therefore the best solution is to switch back to the built-in Cedet 2.0 version.
If you have used the older version of Cedet, it's possible that the old saved .semanticdb files are not compatible with latest Cedet semanticdb. You can do
rm -rf ~/.semanticdb/
So the new version semanticdb can create and use the new version of semanticdb (my friend helped me with that subtle problem so I can get the built-in Cedet 2.0 up and running).
Can someone help me make sense of list-buffer (aka Ctrlx - Ctrlb) behavior in emacs 25?
The behavior I'm used to seeing is that it opens the buffer list in another Emacs window (virtual Emacs window), splitting out a second window to do so, if necessary. In some versions it hasn't always been very deterministic which other window it used (if I had more than 2 up), but I could at least count on it not using the one the cursor was in.
I recently installed 25.0.50.1 to get around a remote file open bug (worked!), and now it isn't always doing this. Very often it opens the buffer list in the same window my cursor was in. Often it works the way it used to. I can't figure out any rhyme or reason behind which it choses to do.
Can someone enlighten me as to the algorithm it is using now? It makes managing multiple emacs Windows for reference viewing nearly impossible when I can't predict which window gets replaced.
I would guess your primary concern is to have a convenient way to switch buffer, not to understand the emacs' source code, so I would strongly recommend to check helm package out: http://tuhdo.github.io/helm-intro.html
It will take about 10 to 20 minutes to install and follow the tutorial, and it is well worth. I promise.
After installing helm and enabling it, the key sequence for you is Ctrl-x b: Shows open buffers, recently opened files
You will get a power pack of many other tools to work in emacs. I had the same problem with switching buffers, and seemingly 'chaotic' buffer popup. After helm installation, the problem is minimized to invisible because it is so easy to switch to the buffers you want.
Update:
To deal package installation errors and package compatibility:
M-x list-load-path-shadows to see if there is any conflicting packages. And since you may not have many external packages, I suggest backup ~/.emacs.d and have a new empty one. Also, most of the case when install packages, I try to use emacs package manager. Benefits of using package manger:
help check dependencies
avoid to manual download and unpack.
can do batch update of installed packages
Following is a workflow of enabling melpa repo and installing packages
M-x customize-group RET package
# Click or move cursor to and enter: Package Archives
# Insert the melpa repository.
Archive name: melpa
URL or directory name: http://stable.melpa.org/packages/
#Save above settings and then you can use the following to install packages:
M-x list-packages RET
f to filer package names
i to mark for installation
x for execution of installation
u for unmark package at cursor.
# to avoid using load-path repeatedly,
# I have this in my .emacs before any 'require' command:
; Set path recursively to one folder
(let ((default-directory "~/.emacs.d/elpa/"))(normal-top-level-add-subdirs-to-load-path))
I'm pretty new to emacs and I'm currently trying to configure it properly for my needs, but I can't make it load web-mode at all.
So, this is what I've done:
Downloaded web-mode.el from GitHub
Made sure the file is located in the correct directory: ~/.emacs.d/web-mode.el
Used the installation instructions from the official page
My .emacs file now looks like this
Issue:
When I'm trying to edit any of the file types specified in the .emacs file, it only runs the default modes. PHP Abbrev for PHP etc... I'm not receiving any error messages and when I'm running --debug-init it does not give any output.
Emacs version: GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.18.9) of 2012-03-01 on sl6.fnal.gov
OS: Scientific Linux
Does anyone know how I can troubleshoot this further, or have solved similar issues?
You should let el-get install it for you. El-get is a package manager for emacs. It can install packages from github, emacswiki, elpa, an url, … http://wikemacs.org/index.php/El-get
It's very handy, you can update scripts easily, it manages dependencies, it lets you discover many stuff, you can easily share your config accross machines, etc.
Emacs 24 has package.el or ELPA by default. One can install it on emacs 23, but my experience isn't conclusive so I'd advise sticking with el-get, which is great.
I quite satisfied of how GNU tools run in my Cygwin on Windows Seven. I think it's easier just to use GNU/Linux, but my company here has the policy of using Windows Seven for the Programmer programming environment. So, the solution is Cygwin. And I use Emacs intensively for my programming purpose.
But, it seems that Emacs running in Cygwin create a consistent (phrew) crash dump that printed on the console. I had to refresh it using C-l, but that makes me wonder : what is the problem anyway?
Does anyone has the same problem here? And what is the solution.
This is my example of running org-googlecl.
Process googlecl-list finished
* List of blogs with in the * List of blogs with in the title :gblog:
12719501 [main] emacs-X11 1168 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12720164 [main] emacs-X11 1168 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
12889237 [main] emacs-X11 764 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12889852 [main] emacs-X11 764 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
And it always create emacs-X11.exe.stackdump. It always happen when I run another process from within emacs, that is if I run a batch file from Emacs.
Thank you
I recently ran into this issue when upgrading my version of Cygwin to 1.7.9-1. pserice's solution looked promising but did not work for me. The solution that worked for me was to run rebaseall:
Close ALL Cygwin processes (use Process Explorer to make sure that nothing has cygwin1.dll loaded in it)
Start > Run > Cmd.exe
cd \cygwin\bin
ash
PATH=.
rebaseall -v
After that, emacs stopped crashing every time it tried to run a subprocess.
Win7 aborts processes that overwrite parts of the stack. If you trust cygwin executables, you can selectively exclude them as follows:
Computer -> Properties
-> Advanced System Settings
-> Performance
-> Settings...
-> Data Execution Prevention
I excluded the following:
C:\cygwin\bin\bash.exe
C:\cygwin\bin\emacs.exe
C:\cygwin\bin\emacs-nox.exe
C:\cygwin\bin\emacs-X11.exe
C:\cygwin\bin\startxwin.exe
I have had this same problem in running console emacs through cygwin on Windows 7.
My solution to this was to install the native GNU Emacs Windows client: http://ftp.gnu.org/gnu/emacs/windows/ and set cygwin's bash.exe as my shell.
You can see my emacs.d/init.el at https://github.com/tildedave/init.el/blob/master/init.el: here is the part relevant to making sure that the Windows 7 Emacs plays well with cygwin --
(if is-windows
(progn
(add-hook 'comint-output-filter-functions
'shell-strip-ctrl-m nil t)
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt nil t)
(setq explicit-shell-file-name "bash.exe")
(setq shell-file-name explicit-shell-file-name)))
For light-weight in-console editing I use nano, which does not core dump.
I can't help with the specific issue, but as a possible alternative you could look at running Emacs in a Linux VM hosted on your Windows box. You can use Cygwin's X.org server as the display, so the end result is largely the same as using Cygwin's Emacs.
It means jumping through a few more hoops, but I find it a good solution, and it will hopefully avoid the crashes.
I'm using VirtualBox to host my VM.