Better control over where windows with cscope buffers in Emacs - emacs

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.

Related

Editing a lisp file in emacs with SBCL

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.

Emacs (Multi)Term vs Xterm vs Console & TMUX

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)).

How do I get SLIME + Emacs set up?

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 tabs more vim-like

I'm currently trying emacs coming from vim. There is only one thing I desperately miss : tabs (in a GUI sense). I know TabBarMode but it doesn't keep the division of windows (with C-x 3 for example) from tab to tab while Vim does it. Is there any plugin for emacs that handle tabs in a more vim-like way?
Check out elscreen.
Emacs users know that tabs of all types are evil. :-) This must explain why this particularly useful metaphor has not caught fire among Emacs users. We're still waiting for a good, easy, implementation of GUI tabs, IMHO.
There is some promising (but young) development work (see Gtk tabs in emacs, new branch.) going on to do GTK tabs in Emacs. And you'll be happy to know that there is some competent enthusiasm currently at play in the wide new land of distributed Emacs development. However, even though Emacs development is proceeding at quite a pace (by comparison with recent history, it's breakneck!), it may be a while before GUI tabs 'just work.'

What are the compelling reasons to upgrade to emacs 23.1?

I saw the the news that emacs 23.1 was released.
For a programmer, What are the big reasons to upgrade? I'm currently on 22.2.
None of the features listed really seem like must-haves for me. The most immediately interesting bit is that nXML is now integrated. I already have it though.
But I have to admit I don't know what is really behind "smarter minibuffer completion" or "per buffer text scaling".
Anyone have any tips or examples of what these things are?
For me, the biggest reason is the support for anti-aliased fonts. And the --daemon support is nice.
Emacs-fu has a nice write-up of some of the features.
M-x butterfly
No one said anything about multi-tty support? I have one long (LONG!) emacs session opened somewhere, and I ssh'ed into that machine remotely and use that particular emacs session (with all the temporary buffers, everything setup the way I liked, groups of buffers opened, etc.). The benefit of course, is that I don't need to worry about saving temporary buffers (you do use those as scratch pad, don't you?), etc. when switching machines (from school to home, for example).
Also, with multi-tty support, you can open emacs with emacsclient -nw to substitute your occasional needs for vi for quick terminal edits. emacsclient -nw will open even faster than vi, and you will have access to your opened emacs session as a bonus. (Before emacs 23, emacsclient cannot run from the terminal).
"Improved Unicode support (the internal character representation is now based on UTF-8)."
is a critical reason for me, but it no doubt depends on your work flow.
Some of the terms you are asking about were discussed in Set Emacs defaut font face per-buffer/mode and are also in the emacs wiki, e.g. http://www.emacswiki.org/emacs/SetFonts (under Changing Font Size - Buffer Text Resizing ).
While I was using the pre-releases, the most noticeable feature has been the improved font support. and some small things about smarter window splitting.
for me its font support and gnupg integration.
also its nice to read pdf's from within emacs.