I would like to attach screen or tmux inside emacs, in shell mode. I often find myself running emacs with inferior processes inside screen on remote servers; it would be nice if I could shift the workflow to local emacs + TRAMP; ability to reattach persistent sessions is a must, however. (Such workflow is particularly useful for analysis in R [1])
Shell-mode is rather desirable because I keep encountering miscellaneous glitches and even crashes when using the combination of M-x term or M-x ansi-term + screen + R. However, I can't seem to get rid of ansi colored rendered as escape codes in screen when run under M-x shell. When I use ansi-color-for-comint-mode-on, they are fine -- but as soon as screen comes on, it becomes a horrible mess.
Has anyone figured out the set of conditions for proper interpretation of ansi color with shell + screen or tmux? What about getting rid of color altogether?.. Are there any other alternatives in terms of running persistent remote processes and attaching them to local emacs?..
[1] http://blog.nguyenvq.com/2010/07/11/using-r-ess-remote-with-screen-in-emacs/
As far as I can tell, Screen requires features of your terminal that Emacs' shell mode simply does not and cannot provide, simply because it is not a traditional character terminal like VT100. So the issue is not about getting rid of or trying to interpret color codes -- there are more terminal capabilities that Screen requires to function correctly.
By default Screen does not even start in Emacs' shell mode, as far as I can tell (it errors out saying it needs clear screen capability). Some posts around the web seem to suggest setting TERM=xterm to work around this, but it is just fooling Screen into thinking the terminal has the capabilities of XTerm, which it doesn't have.
The term and ansi-term modes of Emacs would provide the terminal capabilities required by Screen, but unfortunately you seem to have had troubles with those modes.
What I would suggest instead would be to have a look at the "emacsclient -t" command (part of Emacs), which allows you to open a local frame connected to an existing Emacs instance in a similar way as Screen allows you to reconnect to a previously created Screen instance. That way you could perhaps configure a emacsclient on you local computer to reconnect over TCP to a persistent remote Emacs instance.
I don't use screen, but maybe you can fix this from your .bashrc. I've got a bunch of conditional code in there, turning color on for xterm windows, but leaving it off for other terminals that don't support it. M-x shell sets the TERM variable to dumb, so you can test for that and set the color accordingly.
case "$TERM" in
dumb)
## non-color settings here
;;
xterm)
## color settings here
;;
*)
## default (maybe you want non-color here?)
;;
esac
Related
I've been opening emacs from the terminal but every time I want to compile my c program, i have to quit emacs first, compile it on terminal, then re-open emacs afterward again to edit some more.
Is there a simpler way to do this so I can keep emacs open while also compiling stuff on terminal?
I know this has something to do with entering shell mode but I'm not too familiar with that or editing the init file as im really new to emacs and still trying to get the hang of it
Any help is appreciated, thanks!
To compile your program while inside Emacs, type M-x compile and enter the compilation command. As a bonus, any errors or warnings in the output become links to the corresponding line in the source code.
Once your program is compiled, there are a few different ways to run it. If it's a non-interactive program, you may find that M-! (for running a shell command, waiting for it to finish, and displaying its output in a buffer) is sufficient. Otherwise, you may want to run a shell inside Emacs. You can do that with M-x eshell. (Some people prefer M-x shell; try both and see what you like.)
Alternatively, if you want to temporarily leave Emacs and go back to the terminal, you can type C-z to put Emacs in the background. To go back from the shell to Emacs, type % or fg (for "foreground"). To check whether Emacs is currently running in the background, type jobs.
Alternatively, it's straight-forward to run M-x ansi-term to have a functioning terminal inside of an Emacs buffer. It's nice having a working, interactive terminal in Emacs but also to be able to navigate that terminal output using your normal Emacs key bindings.
I use this this package to make sure all my environment variables are loaded.
Some operational notes:
When I'm editing something in Emacs and in need of a terminal, my usual procedure is to split vertically 'C-x 2' or horizontally 'C-x 3' in order to be able to open a terminal emulator (either 'M-x eshell' or 'M-x shell') side by side with the actual window. From here it is possible go forward and backward with 'C-x o' or 'C-u C-x o' as needed. This allows to continue editing while something is running visibly on the near window.
In rare cases where these emulators dont work exactly as the real OS terminal, we can split and use the native thing without layer or emulation 'C-x term RET RET' . Unfortunatly, in the later case, it is not possible to cycle between the framed windows (with 'C-x o') . Here, the exit command is required to be able to operate normally with emacs.
It has been like one year or so since I started to learn Emacs, and I do like its power and flexibility as a general text editor. When I had tried its Auctex mode for LaTeX/TeX, I knew I will never go back to read which TeX editor I should use. When I had tried its Pyhon mode, I knew I will never be bothered to choose a Python editor/IDE. Well, the same feeling for the VHDL mode of Emacs.
I do not intend to implement Emacs as a whole FPGA design solution (although I tried that). Instead, I prefer to use Emacs just as an external editor (Xilinx ISE in my case) and follow the design sequence according to the ventor's specific IDE. So according to this Editor Options, I set the editor options in my ISE {C:\Program Files (x86)\emacs\bin\emacsclient.exe} +$2 $1. However if I use runemacs.exe as suggested by Xilinx, everytime I clicked a file in ISE a new Emacs will be started. With the emacsclient.exe it helps a bit.
When I clicked a file in ISE now, its corresponding buffer will be opened in Emacs. But the buffer remains invisible and I have to C-x b to it by my self.
Also if I clicked the error information in ISE's console, the file containing the error will be opened in the background of Emacs with the cursor in the error position.
While it is not a big deal if I compare the benefits and drawbacks brought by Emacs VHDL mode, I do like Emacs can change the file I opened in ISE to the current buffer. So the question is how to set Emacs or Xilinx ISE to change Emacs's current buffer to the one I opened or clicked in ISE?
I suppose it should be some configuration related to Emacs rather than settings in ISE (obvious there is not too much choice in ISE's options). It maybe a simple question but it's beyond my current knowledge of Emacs configuration. I really appreciate if someone here could help me on this issue. Thank you guys in advance:)
P.S. Sorry for my poor English expression. Hopefully you can understand my quesition.
With some configuration it's possible to tell Emacs to switch to the related buffer. However, you might want to consider opening a new window (frame in Emacs term) when you call the editor in ISE.
The command line parameter -c tells Emacs client to open a new frame
{C:\Program Files (x86)\emacs\bin\emacsclient.exe} -c +$2 $1
I recently switched to using GNU Emacs 24 from 23, and I notice that whenever I enter gud the *input/output* buffer is open. I have close it manually with C-x 0 everytime I debug. Can anyone point me to the correct variable which needs to be configured in order to stop displaying this buffer by default?
There is a 'gud-gdb' in new emacs releases that implement 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
I have this problem as well. After a quick look at the source code, the problem appears to be that GUD dedicates most of its windows (that is, it calls set-window-dedicated-p on them). A dedicated window is one that cannot be switched away from. I guess more and more young guns are using GUD in many windows mode and want GUD to manage their window layout, and those of us that like to do that manually are in the minority. There doesn't seem to be anything obvious in gdb-mi.el that disables this behavior (for example, gdb-set-window-buffer seems to always do a set-window-dedicated-p to t for all windows it manages).
For now, this solution is more or less the one I'm using -- I manually deactivate the window dedication. This seems suboptimal, though. There ought to be some way to get GUD to let you manually manage the window layout. This question is related.
You can disable window dedication altogether like this: (in Emacs 24.4+)
(defun set-window-undedicated-p (window flag)
"Never set window dedicated."
flag)
(advice-add 'set-window-dedicated-p :override #'set-window-undedicated-p)
Note that this doesn't affect already dedicated windows.
How do I customize which window GUD will use when i issue commands - 'up', 'down', etc ? It seems to use an arbitrary window, sometimes even the window with gdb in it - I want to be able to specify a specific window to be used.
Have you considered borrowing the key bindings mentioned in the following question?
Emacs, switch to previous window
This question implies that GUD steps on some things if you don't add a parameter. Maybe your command bindings are being affected similiarly.
Using gdb in Emacs 23
I asked a buddy of mine about this issue and here is what he said.
Well, we used xemacs and so it's not exactly apples to apples here. I
do have gnu-emacs installed on cygwin and I can't replicate his
problem. I think he definitely needs to list a version # for emacs
and the version # for all his installed packages.
When you press up/down it calls 'previous-line' and 'next-line'
respectively which both move the cursor in the default buffer. The
only thing I can think is that he has something running that switches
buffers (lisp 'set-buffer') temporarily and maybe doesn't set it back
or errors b/f restoring the buffer? Better to use
'with-current-buffer' (or one of the other with-* forms) that saves
the current state of the ui runs your lisp code and restores the ui
state.
I've been using a copy of emacs (in a Debian VM I ssh to with putty) at work for a couple of months now, and up until now everything has been working brilliantly... but this morning I'm trying to edit a file in shell-script-mode, and am seeing some weird behavior with text around the cursor.
Basically, when I type the following ( [ ] represents my cursor):
export DATABASE[]
After I've typed the first few characters of the variable name the export statement disappears and the variable name aligns to the left margin, and all I end up seeing is (with the cursor out in the wilderness):
DATABASE []
If I then hit CTRL-L, the screen refreshes, and I see the text as it should be displayed... until I start typing, and then the buffer start acting strangly again (characters disappearing, moving, cursor ending up in the wrong place, etc)
I've not, to my knowledge, added anything to my .emacs file since this last worked as I expect it to, so I'm at a loss as to what could be happening here. It doesn't seem specific to sh-mode either - I've tested a few other file types and observed similar strange behavior. Are there any emacs afficianados out there who might be able to point me in the right direction to figure out what's wrong here?
Thanks in advance
I'm not sure what to suggest, but this sounds awfully like an issue with the terminal: I suspect that Emacs redraws the current line whenever it changes and I guess it tries to do so incrementally. If something's got out of whack with your terminal, then it seems quite plausible that the current word would get written at the start of the line (all Emacs sent) and your cursor would get abandoned "out in the wilderness" :-)
Obviously, this is a new change. Since it doesn't sound like the sort of issue that would be caused by Elisp configurations in your .emacs, you should check whether you've recently upgraded one of
PuTTY
Emacs version
SSH version (unlikely...)
Then maybe the relevant tool will have something in the changelog (which maybe you can disable via a config?)
One thing you could check: you say this isn't just SH-mode. Is it "any mode with syntax highlighting"? Maybe Emacs just sends over the wire the text with the current colour?
I had a similar problem of disappearing text using PuTTY / Emacs / Remote AWS Ubuntu when running ABCL LISP in a shell window.
The solution was: I had changed my foreground and background font colors (essentially reversed) in PuTTY but had neglected to change the bold fonts, so they were disappearing into the background.