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.
Related
See further below for the original question.
I've used gdb for over a couple of decades, and after an update gdb started defeating c-x-b and preventing windows from being used to view things I wanted to see, while forcing bindings to buffers I didn't care to see. The fix seems to have broken tab completion for shells.
Ah, so how can I to stop gdb from taking control of the buffers/windows/frames layout without breaking something else?
;; fix 'feature' of broken gdb where it takes control of an
;; emacs window, and locks the user out from switching from it
;;
(defun set-window-undedicated-p (window flag)
"Never set window dedicated."
flag)
(advice-add 'set-window-dedicated-p :override #'set-window-undedicated-p)
--- problem in the original post --->
about a year back, after an update, file name completion windows in the shell stopped closing after the completion. I figured this behavior would go away on the next release .. but it never has.
hitting tab -- all good
after completion, then another ls with tab
I can repeat this process until my shell panel is all but crowded out, and emacs fills with completion panels that all contain additional views of the shell.
Is this some kind of new feature that can be turned off? Or is it, as seems more likely, a bug? (How can it have lived for so long!?). Is there a simple way without taking one's hands off the keyboard to, in general, close the completion window so that the screen looks like it did before hitting tab?
[I had to take out the more detailed descriptions of the images because with them, stack exchange complained of unformatted code and wouldn't take the post... there was not even a hint of code in them. Anyway, this should be good enough.]
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
When calling ediff, run-python and some other commands, emacs will open a new frame, but I want emacs to open new window instead, is that possible?
Dunno why someone voted you down. Perhaps s?he thought you should have looked first in the Ediff manual (which I too recommend).
a. Command ediff-toggle-multiframe toggles between using multiple frames and a single frame (multiple windows).
b. The Ediff manual says also: "See ediff-window-setup-function for details on how to make
either of these modes the default one."
You will need to check whether Python mode similarly provides options or commands to control the window/frame behavior.
If Emacs is always opening a new frame for everything, then make sure you do not have a non-nil value for option pop-up-frames.
I am using GDB with emacs and sometimes use GDB with DDD.
Starting version 22 (???) Emacs provides a tool-bar-mode, where you can do
the most important commands like run, next, step, up/down of stack frames in the emacs UI.
As such , I have moved away from DDD, since anyways I run most commands through command line and the sometime through the limited UI given in the tool-bar-mode.
However, the ability to hover your mouse over a variable and make the value to pop-up still seems to be missing. Does anyone know about some mode in emacs or some .el file that would allow Emacs to do the same.
This kinda goes against emacs not being a gui-ide. I can still use watchpoints/local variable buffer; but I really would like the ability to hover my mouse over some variable and see the value. Any help would be much appreciated.
gud-tooltip-mode is supposed to give you just that, I think.
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.