I am trying to run htop in ansi-term in a graphical (X session) emacs, and htop won't resize. Whatever size the window/frame is when I start htop is the size it continues to try rendering at forever.
Things I've tried:
Running ansi-term on htop directly and inside an ansi-term running zsh.
Manually sending a SIGWINCH w/ kill -28 $pid to the htop process. Also to the parent zsh process when there was one.
Telling emacs to send the signal with emacsclient eval'ing (signal-process nil 28) and with (signal-process (get-buffer-process (get-buffer "mybuffername")) 28). I know the signal gets through because sending signal 29 kills the process.
Interestingly plain ol' top does resize, but only when the frame containing its buffer has X input focus. Htop still doesn't resize regardless of focus though. Also interestingly emacs itself running in console mode in ansi-term does resize, but only when given input. So you have to press up or down or write a character first or something.
Ideally all 3 would always resize immediately when the window does. Emacs has a hook for detecting this, I just need to know what to tell the hook to do.
Any ideas?
Related
When I accidentally make an infinite loop by evaluating a form in emacs with geiser + racket, after a minute or so of waiting, eventually emacs will start to respond again. Unfortunately, every eval after that takes at least a minute. Usually, after the second or third eval, emacs will stop responding at all, and the fastest thing to do at that point it to restart the Ubuntu machine.
Is there some setting to prevent this in geiser, or a way to tell emacs to kill geiser?
Here's what I do when something hangs up.
Over the years, I don't recall Emacs being stuck in an unrecoverable state.
Use C-g. Repeatedly if needed. It calls keyboard-quit.
This should break any stuck loop and give you the ability to enter commands.
Now if geiser or any other process is misbehaving, just kill the buffers
that correspond to this process.
C-x C-b will give you the list of all buffers.
If you don't recognize the one that belongs to geiser, just restart Emacs
and open only geiser and see the buffer list again.
Now mark the misbehaving buffers with d.
Execute the deletion with x. That's it. You can
now restart geiser or whatever else. This approach is completely generic.
By the way, restarting the Ubuntu machine is too drastic.
When nothing works to stop the application with a window, but X still works,
use xkill utility. I've bound it to Ctrl-Alt-F12 for instance.
Then you just click on a window you don't like and it's gone.
If xkill doesn't work, switch to a virtual terminal with
Ctrl-Alt-F1 and use htop to kill the application.
According to the REPL documentation, you should be able to use C-c C-q to kill the REPL. From the link to the REPL documentation, go to the First Aids section; it's near the bottom of it.
Geiser hangs on loops here also. In emacs 24.3.1 running on Debian 7 updated two days ago; M-x run-geiser; Then one gets a window with a REPL prompt. All is good, but then say > (define f (* f (- n 1))), then > (f 3) and the process in the buffer is locked up. C-c C-c and C-c C-q do nothing. Killing the buffer, answering yes to the query of killing subprocesses, and then restarting does get one to a REPL prompt with all definitions gone.
I like running shell programs using Emacs ansi-term mode, but I wonder how to set the maximum buffer size in ansi-term mode so I won't lose command history even when there are lot of lines? (Google doesn't seem to give a obvious answer.)
The variable term-buffer-maximum-size controls this value. Setting it to 0 should buffer everything (haven't used it but that is what the doc says). I'd be tempted to use a large value instead so a runaway program doesn't cause serious issues. It defaults to 2048 lines.
(setq term-buffer-maximum-size 0)
in your term-mode-hook function should do it.
I am unable to yank text into a terminal running in Emacs.
This is my procedure:
I killed the string "date" from one buffer and yanked it into the terminal in another buffer and hit return.
The terminal behaves as if I typed nothing. It just returns the prompt back.
I am using OS X 10.5.8 and Emacs 23.1. I have tried this procedure on Aquamacs, Carbon Emacs, and the release from http://emacsformacosx.com/. They all show this weird behaviour even in their default configurations with my .emacs file empty. What could possibly be causing this?
By "in a terminal" I assume you mean you're running Emacs's built-in terminal emulator. Ordinarily, the terminal emulator transmits most keys exactly as typed to the shell process. Type C-c C-j in the terminal buffer to put it into a state where ordinary Emacs key bindings are available. You'll see the mode line change from (Term: char run) to (Term: line run).
Addendum:
Yanking text without leaving char mode is a little tricky; the relevant function, however, is term-paste (not yank, which merely inserts the text into the terminal buffer without sending it to the inferior process). term-paste will immediately send the most recent kill to the inferior process, but doesn't provide the fancy yank functionality you're probably used to (like M-y to cycle through prior kills). You could run term-paste as an extended command: C-c M-x term-paste RET.
Probably the easiest solution is just to temporarily go into line mode (C-c C-j) when you have something to paste, and then immediately go back into char mode (C-c C-k). Or even easier, just stay in line mode all the time. I often do this when I have a terminal logged into an Oracle SQL*Plus session. I rarely notice the difference, but I get all sorts of convenient Emacs functionality, like being able to type M-p to cycle through a long, previously-typed SQL statement.
I would have assumed that you could always start off in line mode like this:
(add-hook 'term-mode-hook 'term-line-mode)
...but it doesn't work for me. Don't know why.
In the buffer with the terminal running, put the terminal into line mode with C-c C-j. To paste in your text, now press S-Insert (that's Shift-Insert). If you need the terminal to go back to char mode afterwards, it's C-c C-k.
When all else fails I just highlight the text and click Edit->Copy then right click in the other emacs buffer and click paste.
I have an asynchronous process in Emacs, which creates a TAGS file.
This process creates a process buffer called *ctags*. If the process result is "finished\n", I kill the buffer.
If the process result is anything else I want to display the process buffer similar to the *compilation* status output when running M-x compile.
I.e. I want to vertically split the screen and show the *ctags* buffer at the bottom. Pressing q would preferably kill the bottom buffer and just show my original buffer.
I tried using this in my process sentinel callback:
(split-window-vertically)
(set-window-buffer (selected-window) (get-buffer "*ctags*"))
but aside from the fact that it puts the *ctags* buffer on top, the buffer does not have the same characteristics as the *compilation* output, e.g. pressing q inserts q.
How do I create a buffer like *compilation*?
EDIT:
Inspired by Trey Jackson's answer below, this does exactly what I want:
(pop-to-buffer (get-buffer "*ctags*"))
(compilation-mode)
It selects the *ctags* buffer, puts it into compilation mode and q will quit the window.
EDIT2:
Using (compilation-mode) (major mode instead of minor mode) since Emacs somehow doesn't like reapplying the minor mode to an exisiting buffer.
The Error message I get is:
Toggling compilation-minor-mode off; better pass explicit argument.
To get the behavior of the *compilation* buffer, add this to your script:
(compilation-mode)
It's better to derive your own mode from compilation-mode, and define error regex, etc.
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.