Ok so i am trying to get started with lisp and slime and i am running into some problems. I have correctly installed emacs and slime and SBCL but i run into problems when trying to edit files. I am doing this all on mac osx lion though i dont think that makes a difference. So this maybe stupid but when i first enter the terminal i enter
$ emacs <myfile.lisp>
and then it opens up my file but then slime is not running so i do..
M-x: slime
but when i do that is now gone and all i see is the "REPL" (i think) anyway it just shows me
*
and then i can enter things like
*15
15
but now i can't get back to my file so that i can compile it. Could somone please hlep me through this? Thank you!
Try C-x← and C-x→, that switches the current window's buffer to the previous or next buffer.
For a more interactive approach, split the screen vertically C-x2 (or horizontally C-x3), so you may see your code and try something out on the REPL. You may switch windows with C-xo (remember, O as in Other). You may close a window (not the buffer) with C-x0.
However, you'd better search for an Emacs tutorial, as all of this is very basic. I also recommend you start with a graphical Emacs, such as Emacs for Mac OS X. Some people prefer other versions, which integrate better with Mac OS X but also have lots of different keybindings and come with extra packages. I personally prefer having similar installations and keybindings in whatever OS I'm using.
Related
I do use Emacs for years, and in particular the Cygwin Emacs version (under Windows 10) for months.
Since 2 days, M-x combo key is not working anymore, well ESC x but I don't want to be forced to use Emacs à la Vi ;-)
First, I thought that the keyboard of my laptop could have a trouble, but the same effect is observed with an external keyboard connected by USB.
Second, I though it could be due to some changes I did in my own Emacs init file, or changes inherited from MELPA. To test that, I came back into time with Git, but that wasn't it: problem still observed; to test for MELPA packages, I used a minimal Emacs (emacs -q) and, once again, the problem still persists.
(And ESC x displays that M-x, translated from <escape> x, runs the command
execute-extended-command -- which is expected.)
Finally, what's weird, is that the key x alone is working, and so does C-x. On the other hand, M (meta) is working: M-c, M-w do work like expected.
So, to sum up, only the particular combination M-x is not working, and I really have no idea why.
Any smart test I could do to debug this (on Win 10)?
To sum up the answer in the comments:
If your key combination does not do what you expect - use C-h k to find out if it's a wrong mapping inside emacs, or something is grabbing this combination before emacs has a chance. If C-h k doesn't do anything in response to Alt-X - then you can be certain emacs doesn't see it at all.
If you want to confirm a key combination has been hijacked try to use some other application with it. Alt-X isn't used by regular Windows applications, but if you happen to have anything else that can have customized key bindings then try to map Alt-X to anything inside it. Eclipse, IntelliJ, Visual Studio, gvim. But seeing what happens with C-h k is a sufficient proof.
To find out what is stealing your Alt-X check what was installed or reconfigured lately. Disable startup programs if you can't recall. Additionally, from my experience a couple of nasty offenders: Intel video driver, and Windows language bar. (Not with Alt-X, with other key combinations.) Windows language bar is especially annoying when it steals C-S-) which I use for slurp.
Last thing. If you are running in a VM, your key combination may be stolen at either host or guest level (or both, as I've seen with the language bar.) So you may need to look around in both places.
I encountered the same problem. But I found that the problem was come up with the conflict of hotkey. On my Win10 OS, M-w is conflicted with the Tencent QQ software. So when I closed the QQ or changed the QQ's hotkey, the Emacs worked well.
I don't know why, but the problem is with Growl for windows v2.0.8. Close it and emacs will run normally.
Anyways, any new program setup could create conflicts. Stop all new (since the bug) process and check it.
(I don't want to change the keys configuration)
I recently upgraded to emacs 24.3.1 in order to use a new mode for programming in D. I seem to have introduced some problem with my other modes now (Java, C++ C I'm just using whatever comes with emacs). When I scroll up/down in a buffer, the text displayed is totally messed up. As in lines mixed together, indentation screwy, cursor not modifying where it looks like it is. If I hit ctrl-l the screen refreshes and all is good. I noticed this problem every once in a while with my previous version when editing C .h files. But now it's happening on every single buffer. I can't work with it. Every time I move up/down I have to refresh the screen. I can't find anything similar to my problem with a google search. Might end up being an issue with some incompatible version of a dependency. Here's my system stats.
CentOS release 5.4 (Final)
linux 2.6.18-164.el5
emacs 24.3.1
I don't even know what other libs emacs might depend on. I'll be happy to post versions of anything that might be relevant.
Thanks
Since you say that this happens also with emacs -Q, i.e., without your init file, consider filing a bug report: M-x report-emacs-bug. For that, try to give a short, reprocible recipe, starting with emacs -Q. Emacs Dev will take a look and let you know whether they think there is a bug.
Using report-emacs-bug also automatically gathers info about your Emacs version etc., and includes it with your bug description.
I'm an Emacs user trying to learn a software tool that is best run from a terminal. The default set-up to get the most out of that tool is to use xterm for interaction and call Vim for editing. One could simply replace Vim with Emacs in this setup, but then one would spend most of the time working outside of Emacs in an Xterm.
I figured out there is (Multi)Term-mode in Emacs, but it is really hard to find out about its pros and cons. So I have the following questions:
[Without X11]: Why or when would anybody use Emacs (Mutli)Term instead of Console & TMUX (or GNU Screen)?
[With X11] How does Emacs (Multi)Term compare to Xterm?
Obviously speed is one criteria for comparison, but I'm sure there are other.
You'd use Emacs term over tmux/screen if you're more familiar with Emacs and already use it for many other things and/or if you spend more time in Emacs than in the terminal.
Emacs's Term is much less sophisticated and much less reliable than xterm. But it works within Emacs so if you live in Emacs, it might be a good option.
Note that you may also prefer to use Emacs's M-x shell functionality, which gives you a command line without giving you an actual terminal emulator. That means that the commands are edited in Emacs before being sent to the underlying command-line program, so all the usual Emacs editing can be used there (and the history manipulation as well as command completion is performed by Emacs as well, which can be great, or can be disappointing (e.g. if the completion needs info which Emacs does not have)).
According to this answer, Emacs + Slime already has much advanced functionality. So how can I get syntax coloring, auto-completion, and perhaps even version control management, set up and running in my copy of Lispbox?
If it's of any help, I have installed Lispbox on Mac OS Lion.
Syntax highlighting should already be working as soon as you load a lisp file in Emacs, regardless of whether you've got SLIME installed or not. If it's not, try doing M-x font-lock-mode and see if that turns it on.
Version control isn't provided by Emacs or SLIME, but Emacs can integrate with pretty much any version control system you care to use. I recommend Mercurial or Git. Emacs should start vc-mode automatically when you open a file that is in one of the supported version control systems. The manual includes extensive documentation, do M-: (info "(emacs)Version Control") to jump right to it.
Auto-completion is more complicated. There is more than one way to skin this cat, but for Lisp SLIME's default method should be good enough. Use M-TAB to complete the symbol at point.
Emacs is my editor of choice, and I use the cscope intergration xcscope.el provides. Recently I had a flirt with Vim. I decided to stay with Emacs, but one of the things I really liked in Vim was how I could control where my cscope windows should appear. Using cscope_maps.vim (http://cscope.sourceforge.net/cscope_maps.vim) I get shortcuts that let Vim open search results in the same buffer, a new horizontal or a new vertical split.
In Emacs a the cscope buffer just pops up in a window somewhere, according to some rules I don't know. My guess: A new window is opened if I have only one. If I have more, the one I've been away from for the longest time is used.
Pin Emacs buffers to windows (for cscope) is the only related topic I've found that helps a bit, but that doesn't make it near as flexible as the key bindings in Vim.
Anyone got a better cscope setup in Emacs than what xcscope.el provides? I don't know lisp, so I have no idea how hard it would be to make this work the way it does in Vim.
Emacs 24 (not yet released) changes radically how it is decided which buffers are displayed in which windows. In principle it should give you more fine-grained control. In any case, how you solve the problem for Emacs 24 will be different from how you solve it for older versions.
Consider filing an Emacs enhancement request to specifically get behavior more like what you had with Vim. To do that, use M-x report-emacs-bug.