Emacs "stuck" colours in shell modes - emacs

Sometimes if I'm working in either a shell or eshell buffer with ansi-color-for-comint-mode on, and running a program which gives colourized output and then crashes while printing coloured text, the colour gets "stuck" and all subsequent text in that buffer is in that colour. The only way I've been able to fix it is to either turn ansi-color-for-comint-modeoff, or kill the shell buffer.
Is there a nicer way to tell a comint-derived shell buffer to "reset" the ansi colour codes?

It's not the prettiest solution, but this function works - it just sends the right color code to reset the colors
(defun unstick-ansi-color-codes ()
(interactive)
(end-of-buffer)
(insert "echo -e \"\033[m\"")
(comint-send-input nil t))

Related

how to empty or clear the emacs minibuffer?

Sometime the content of the minibuffer shows the output of a command (emacs 24). This is not too much of an inconvenience when the output is just one line. It's more annoying when the command is multiple lines long and the minibuffer uses many lines of display that could be used for something else.
Is there a way to clear the content of the minibuffer ?
Note: When I M-! echo usage: foo ; echo the minibuffer content changes to usage: foo.
Note: I'm not in recursive edit, the minibuffer is not active, using C-g, M-x C-g , (message nil), M-x delete-minibuffer-contents, M-: (kill-buffer " Echo Area 0") does not clear the minibuffer
Normally, C-g works just fine in those cases. It'll print "Quit" in the minibufer, which is just one line and unobtrusive enough.
If you need to clear the minibuffer programmatically, call (message nil).
If, for some reason, C-g does not work for you, make a new command and a keybinding for clearing the minibuffer
(defun my-clear-message ()
(interactive)
(message nil))
(global-set-key (kbd "C-c c") 'my-clear-message)
My guess, from your description ("the minibuffer is not active") and your replies to other answers, is that it is not the minibuffer that needs clearing - it is the echo area.
This is the same physical space, but the echo area is for output (e.g. message), whereas the minibuffer is primarily for input.
To clear the echo area, use (message nil), as suggested. Or use the minibuffer, followed by C-g - e.g., M-x C-g. That usually takes care of the job (but see below, about killing the echo-area buffer, if you really need to clear it).
If it really is the minibuffer input that you want to clear, then:
C-g (repeated, if necessary) quits the minibuffer.
You can use any text-clearing keys to clear the input without exiting. E.g., C-x DEL will clear quite a bit (it is backward-kill-sentence). I bind M-k (normally kill-sentence) to a command that deletes all of the minibuffer input (this is the case in Icicles, for instance). Command delete-minibuffer-contents wipes it all out.
(You can also kill the echo-area buffer, if it should ever get polluted with some text you want to get rid of. The buffer will be re-created automatically. With vanilla Emacs it is a bit problematic to do this interactively, but you can at least do it using M-: (kill-buffer " *Echo Area 0*") (note the SPC char prefix).)
Although I do not understand why following clears the minibuffer: M-! echo ; echo
This output is normally cleared as soon as you do anything else in Emacs. But sometimes Emacs gets confused and the message keeps reappearing in the echo area.
Deleting the buffer named *Shell Command Output* would solve the problem, but when this happens to me Emacs refuses to delete this buffer. Deleting the contents of this buffer solves the problem, but output reappears in the buffer the next time you do a shell command.
You can prevent that problem by renaming the buffer. One way to do that is to make that buffer current (e.g., with C-x b or M-x switch-to-buffer) and do M-x rename-uniquely. If you do that and delete the contents of the buffer, the problem is avoided.
I have no idea why sometimes Emacs refuses to kill this buffer, but fortunately it allows renaming it so it will no longer be reused for command output.
Try pressing C-g, this will clear the echo area.

Emacs switch to buffer in different frame

I'm currently programming away in emacs. I have a function defined in my .emacs that saves all my work and executes the interpreter to run my work in the currently open shell buffer. Typically I'll be editing in one or more frames and have the shell open in a separate frame. The problem I have is when I run my save and execute function, everything is saved but the shell buffer then gets displayed in the frame I'm currently editing. So I have two frames showing the shell buffer and I can't see the source code I was just editing. Quite often when I'm programming, I'd immediately like to compare the output of the code with the code I've just written. It's a bit annoying to have to switch back to my code buffer and then go to the end of the other shell buffer to look at the output while referencing the just written code.
(defun execute-script ()
"Switch to shell buffer and re-execute the last command."
(interactive)
(save-some-buffers)
(switch-to-buffer "*shell*")
(end-of-buffer)
(comint-previous-input 0)
(comint-send-input))
As you can see my function is rather primitive at the moment, just re-executing the most recently used command in the shell.
I know that Emacs has the functionality to switch to a buffer in a different frame, as the ido buffer switcher code does this. Does anybody have any pointers as to what I need to replace my call to switch-to-buffer with to get the desired effect?
Regards Giles.
Exchange
(switch-to-buffer "*shell*")
for
(switch-to-buffer-other-window "*shell*")
This will enforce a two window layout with your previous buffer on the left side and the shell buffer on the right side.
Edit: If you're using a multiple frame layout and not a multiple window layout you can use
(switch-to-buffer-other-frame "*shell*")
You can also use pop-to-buffer which will later let you customize exactly how that behaves, e.g. via display-buffer-reuse-frame, or display-buffer-alist, or special-display-regexp.

Different results when elisp function is run different ways; why?

EDIT: Perhaps (in original post) I used the term "transient" incorrectly (I'm not familiar enough with the jargon yet). What I really mean is that the highlighted region will disappear immediately when the user presses a navigation keys eg. arrow-keys... (2nd EDIT: I've removed the word "transient")
The particular issue of selecting a region so the user gets "cursor-key movement will make highlighting disappear" has been the bane of my existance recently. I get differnt results depending on how I run the following script.
Why does it give different results, and more specifically, is there a way to make it produce "cursor-keys make highlighting disappear" regardless of which mode is running, or whether it is being evaluated while testing? .. CUA mode has this behaviour, but I really need that non CUA mode does it too (and eval, if possible)...
Here are the results, followed by the code. (GNU Emacs 23.1.1)
CUA mode enabled
Evaluate via C-x C-e — both (call-trans-hi) and (trans-hi)
NO-GO: Both set mark and move point to EOL, but nothing is highlighted.
Execute M-x call-trans-hi
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
Via key binding C-f1
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
no CUA mode (pretty much std emacs)
Evaluate via C-x C-e
NO-GO: Same as 1. when CUA is enabled.
Execute M-x call-trans-hi
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
Via key binding C-f1
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
;test (trans-hi) EOL
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(activate-mark))
;test (call-trans-hi) EOL
(defun call-trans-hi ()
"call transient highlight"
(interactive)
(trans-hi))
(global-set-key [C-f1] 'call-trans-hi)
When you look at the source of activate-mark, you can see that it's just setting some variables. I suppose that's why you don't see the mark in both 1., because the actual highlighting happens in some stuff that's done when executing functions interactively instead of just calling them.
In the other cases of no CUA-mode, that just how transient highlighting works outside of CUA-mode. If you want the CUA-mode behaviour, use CUA-mode resp. that part of it.
EDIT:
Does this change (the addition of the setq line) to trans-hi make the highlighting work the way you want?
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(setq transient-mark-mode (cons 'only transient-mark-mode))
(activate-mark))
If you want to see the region highlighted when you mark it, you need
to activate the minor mode transient-mark-mode.
When a region is highlighted and a character insterted the default is
to disable the highlighting and insert the character at the cursor.
If you wish you can delete the selected region by activating the minor
mode delete-selection-mode.

emacs shell command output not showing ANSI colors but the code

When I do M-! in my emacs 21.4 the ANSI codes gets literal. Eg: ls --color
^[[0m^[[0m05420273.pdf^[[0m
^[[0m100829_Baño1.pdf^[[0m
Is there a way of having it with color and UTF8?
The same question has been answered in SO before but with not totally satisfactory results (the solution given was to open a shell-mode). I know how to have colors in a shell. I only want to know how I can have color with M! (shell-command) or if it is not possible at all.
A shell mode is too intrusive when you want only to show something quick and don't want to move to this buffer and you would like to have it disappear automatically without C-x-k. Obviously there are situations where a shell buffer is more convenient but thanks to the other question I found how to put color to the shell-mode.
[note] emacs in use
GNU Emacs 21.4.1 (x86_64-redhat-linux-gnu, X toolkit, Xaw3d scroll bars) of 2008-06-15 on builder6.centos.org
ansi-color.el contains the functions to process ANSI color codes. Unfortunately, there's not really a good way to hook it into shell-command. This is something of a hack, but it works:
(require 'ansi-color)
(defadvice display-message-or-buffer (before ansi-color activate)
"Process ANSI color codes in shell output."
(let ((buf (ad-get-arg 0)))
(and (bufferp buf)
(string= (buffer-name buf) "*Shell Command Output*")
(with-current-buffer buf
(ansi-color-apply-on-region (point-min) (point-max))))))
About UTF-8:
To specify a coding system for
converting non-ASCII characters in the
shell command output, use C-x RET c
before this command.
Noninteractive callers can specify
coding systems by binding
coding-system-for-read' and
coding-system-for-write'.
This is from the documentation of shell-command.

How to create buffer similar to *compilation* in Emacs?

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.