I am using emacs 24.3
One strange thing I noticed about emacs shell (eshell) when recentered(using C-l), goes to bottom after any command is executed.
Is there any way to avoid this?
Related
I use ansi-term for my normal terminal sessions. I tend to use unicode characters in my prompt to do things like set the trailing character based on the type of source control I'm using.
I use the character "±" as my prompt for git repositories.
In Emacs' ansi-term, my prompt isn't rendered as unicode, and shows as "\302\261". Displaying the current coding system shows that it defaults to utf-8-unix for input to the process, but I get raw binary as the decoding output. I can hit C-c RET p to change the encoding and decoding coding systems. I'm drawing a blank as to how to set this automatically when I start a terminal? I've tried adding to term-mode-hook to set the buffer's coding system to no avail. I think I've found what I'm looking for in term.el, but I don't care to tweak the distribution elisp, and it appears the raw binary was added to fix a bug somewhere else.
EDIT: This was unclear originally. I'm having issues setting the default process coding system for ansi-term running under Cocoa-ized Emacs 23.3 on MacOS. Emacs itself isn't running in a terminal, my terminal is running in Emacs.
The following worked for me:
(add-hook 'term-exec-hook
(function
(lambda ()
(set-buffer-process-coding-system 'utf-8-unix 'utf-8-unix))))
ansi-term seems to ignore the default-process-coding-system variable, so I had to set it buffer-locally after it executes my shell.
After getting a better understanding of term.el, the following works:
(defadvice ansi-term (after advise-ansi-term-coding-system)
(set-buffer-process-coding-system 'utf-8-unix 'utf-8-unix))
(ad-activate 'ansi-term)
Trying this with term-mode-hook is broken because in term.el, term-mode-hook is called before switching to the terminal buffer, so set-buffer-process-coding-system breaks due to the lack of a process associated with the buffer.
Try
(set-terminal-coding-system 'utf-8-unix)
That's C-x RET t not C-x RET p.
So C-x RET p helps?
Unless C-h v default-process-coding-system is (utf-8-unix . utf-8-unix) try
(setq default-process-coding-system '(utf-8-unix . utf-8-unix))
Update
What's happening is that whenever I kill some text, it gets added to the kill-ring followed by an extra "". Then C-y just inserts the "". So the question is where is the extra "" coming from?
Original Question
I'm running emacs under tmux, and I can't get C-y (or even M-x yank) to insert content from the kill-ring. I do see Mark set in the minibuffer, which is normal behavior for yank; I just don't see anything getting yanked. I also see that "" gets added to the kill-ring each time I hit C-y.
I know that C-y is getting received by emacs by looking at the output of M-x view-lossage, and I know that C-y is bound to yank by looking at the keybindings with C-h b. Moreover, running M-x yank directly gives the exact same results.
When I repeat the experiment outside of tmux, it works as expected. For what it's worth, if I repeat the experiment with screen instead of tmux, C-y works as expected.
Some more details are that within tmux, I have tried running emacs with TERM=xterm-256color and TERM=screen-256color with the same result. Setting xterm-keys on or xterm-keys off in tmux doesn't seem to matter either. I've been closing every tmux session between each permutation I try, to make sure that my .tmux.conf is getting re-processed (And I know it is because other changes in my .tmux.conf do have an effect.)
In fact, I can even comment out my entire .tmux.conf, with the same result.
Also, I've tried it in both iTerm2 and Terminal.app (I'm on a mac), again with the same result.
So, I feel like I am at a dead-end here. Any ideas on how to better debug this problem?
I finally tracked it down to some code I had copied into my emacs init.el to allow copy-and-paste from my OSX clipboard. If I remove that code from my init.el, C-y works fine under tmux. (The code is here -- it worked great until I decided to try out tmux!) I'm still not sure exactly what the problem is, but it's easy to believe that it would affect the behavior of C-y.
I am trying to set [Ctrl]-[;] as a keybinding in my .emacs like this
(global-set-key "\C-;" 'comment-or-uncomment-region)
however it doesn't work when I try (i don't get any error messages, it just has no effect). It will work though if i try a normal character (such as setting it to "\C-p").
I have also tried
(global-set-key (kbd "C-;") 'comment-or-uncomment-region)
but I don't like this option because for me it doesn't work when i run "emacs -nw". Any thoughts on how I can do this?
EDIT:
When I run C-hcC-; in emacs -nw I get the output:
; runs the command self-insert-command
which is exactly the same as when I run C-hc; in emacs -nw
So I believe phils is right, that it is a terminal problem, because emacs never actually sees C-;, it only sees ;
Indeed C-; is typically not something your terminal is able to send to an underlying application like Emacs (so it works under a GUI but not in a terminal). But I wonder: why do you need such a binding anyway, given that M-; is already bound to comment-dwim which does comment/uncomment the region when the region is selected, so it provides a superset of comment-or-uncomment-region.
Using (kbd "C-;") is absolutely fine and correct.
I suspect when you type C-; when running emacs -nw, your terminal is not actually sending anything to Emacs.
So your problem is more likely to be a question of how to get your terminal to send C-; to Emacs (or alternatively how to get Emacs to recognise the sequence which is sent).
If you run emacs -Q -nw and type C-hcC-;, do you get a "C-; is undefined" message?
Assuming that it is a terminal issue, here are some related Q&As which may point you in the right direction, but it's going to depend upon the particular terminal you are using.
Binding M-<up> / M-<down> in Emacs 23.1.1
Send "C-(" to Emacs in VT100/xterm terminal (Mac OS X's Terminal)?
How does one send S-RET to Emacs in a terminal?
emacs -nw issues with cscope and terminals
I load GNU emacs in it's own window by typing emacs in the terminal.
I like to use the keybindings from pc-selection-mode, which allows you to highlight characters using shift-right or shift-left, or entire lines by pressing shift-up or shift-down.
The problem is that when I run emacs in the terminal by typing emacs -nw, the latter 2 keybindings don't work. I can highlight characters using shift-left and shift-right, but pressing shift-up and shift-down doesn't do anything. The cursor stays where it is.
How do I fix this problem? Why is it even occurring? I'm using GNU Emacs 23.1.1, and I've confirmed that the same version is being used both when emacs is in it's own window and when emacs is running inside the terminal.
Thanks for any help
A lot of times the bindings just aren't listed, or are mapped wrong. You can try M-x show-lossage (or C-h l) to see if the escape sequences reach emacs or not. If they do, you might want to try xterm-extras -- it's always worked even as I migrate between different versions of linux and solaris, and as I ssh between them (which is often a source of problems).
I'm using pdb to debug Python programs and am unhappy with it's behaviour.
I have the screen divided into multiple emacs windows, and when I execute pdb, it (randomly?) replaces one of the windows with the output of the *gud* debugger.
Also, when a breakpoint is encountered, even if the debugging buffer is already visible in a window, it usually puts this buffer into another window, and replaces another of my windows with the contents of the source file. (incidentally I like that it jumps to the correct line in the source file)
How can I disable gud/pdb from managing my windows for me? Is it possible in emacs to prevent all programattic manipulation of windows & screen layout?
Edit: I found the answer that partially solves this in another post: toggle dedicated windows
I tried all these approaches without success on Emacs 24.
If you are still interested I reverted to the old gdb behavior using 'gud-gdb' which implements the old behavior of gdb/emacs interaction (no dedicated-windows and no I/O buffer). If you don't want to call M-x gud-gdb when you use it, you can define an alias for M-x gdb
Look into sticky windows.
I have a solution that prevents the gdb from stealing windows. It works with Emacs 24.4 (2014-07-18 snapshot) and does not require dedicating buffers. The benefit over other answers is you won't have to bother dedicating and undedicating buffers whenever you change buffers, which quickly becomes tedious.
Place this advice in your .emacs:
(defadvice gdb-inferior-filter
(around gdb-inferior-filter-without-stealing)
(with-current-buffer (gdb-get-buffer-create 'gdb-inferior-io)
(comint-output-filter proc string)))
(ad-activate 'gdb-inferior-filter)
This effectively replaces this function as defined in gdb-mi.el and removes the branch that calls gdb-display-buffer, which is the cause of the window thievery.
You should use Sticky Windows to make your windows and buffers stick where they are but Sticky Windows won't stop gud/pdb from trying to steal your windows. When gud/pdb can't steal your source code window, it opens a new Emacs Frame even if there is another window on the current frame.
This comes from the fact that the function that tries to jump to the gud-pdb buffer (py-pdbtrack-track-stack-file) calls function pop-to-buffer with argument OTHER-WINDOW set to t.
To circumvent this behavior for all libraries that calls pop-to-buffer, you could cancel the role of OTHER-WINDOW by defining an advice on pop-to-buffer (in your .emacs) :
(defadvice pop-to-buffer (before cancel-other-window first)
(ad-set-arg 1 nil))
(ad-activate 'pop-to-buffer)
You should also customize variable pop-up-windows to nil in order to force display-buffer (the low-level routine used to display a particular buffer on windows and frames) to not create a new window.