I encounter a problem when using sr-speedbar mode in Emacs. c-x-f or godef-jump (maybe some actions like these two) doesn't open the buffer in the main window, but split the window.
So is there a variable to control this manner? How to force them in the main window?
Related
One small thing that has been bugging me with emacs
When opening a shell within a buffer i do:
M-x shell
So far so good
But if I want to open another shell, I switch to another buffer and:
C-u M-x shell
but this always opens in another window - not the one I am currently in
this is annoying does anyone know how to fix it?
EDIT
I should have added that i have multiple buffers open in multiple split windows, e.g. my frame is split into 3 sections - what i want is the new shell to open in the same section that currently has focus, i.e. the one i am typing in and not an alternate one
I think what happens when I do C-u M-x shell is that the new shell buffer opens in the next window, i.e. the one you would shift to if you hit C-x o. I want it to open in the same window
Emacs runs interactive shells in dedicated buffers. It cannot run a shell in, say, TeX buffer.
M-x shell creates a new shell if there isn't one already, and C-u M-x shell asks you for the name of a new buffer. You can also rename the shell buffer to facilitate multiple shells, see the link above.
EDIT: the new shell buffer is displayed using pop-to-buffer-same-window (in Emacs24).
Your best venue is to add *Shell* to display-buffer-alist - but it is not necessary there.
In Emacs23 the display of the *Shell* buffer is controlled by special-display-function (since *Shell* has a match in special-display-buffer-names or special-display-regexps). Set special-display-function to display-buffer-same-window (or something similar) and you should be golden.
However, the ultimate solution is to upgrade Emacs to v24; since you are on a linux system, it should be straightforward.
You can use following codes to force the "*shell*" buffers display in the same window.
(add-to-list 'display-buffer-alist
'("^\\*shell\\*" . (display-buffer-same-window . nil)))
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
For example, let's say I have three tabs open in vim:
1: nice_program.c
2: something_fun.h
3: super_script.sh
So if I hit some magic modifier key, and then type 'n' and hit enter I change tab to tab 1. Likewise, typing 'su' instead will navigate me to tab 3 instead.
Is such behavior possible? There are so many vim extensions, and I dont really get the whole vim extension lingo.
BTW, I am using gVim on XP and MacVim on OS X. Preferably the solution will work on both...
EDIT:
Note that I only want the incremental search to search across the names of the open tabs. That is, it's not supposed to actually search inside the tabs themselves.
Also, I never use buffers, it's tabs that I want this working for.
From the wording of the question it seems that you take the idea of tabs in
Vim not the way it is supposed to be taken by design of this feature. A Vim
tab page is not a form of a buffer or a window, it is a window layout
container, instead. No wonder there is no built-in way for switching to a tab
by the name of a buffer that is active (or the only one in its tab page, or
special in some other way). Semantically, that is switching to a buffer, not
a tab (but tab could be switched in order to show a buffer, if it is
necessary).
To switch to a buffer by its name use the :sbuffer command (:sb, for
short). It is not necessary to type the whole buffer name each time, since
the command has auto-completion. Usually one have to type only few letters of
a name to uniquely identify a buffer (the same way as you described
incremental search in the question).
By default, Vim open the requested buffer displacing one in the current
window. This behavior is governed by the switchbuf option. One of the
choices (called usetab) provided by that option allows to switch to a window
in another tab page if that window contains the buffer to edit. This is
exactly what suits your manner of work with tab pages.
To summarize, change the switching behavior as follows
:set switchbuf=usetab
and use the :sb command to open a buffer by typing a few letters of its name
and using Tab-completion.
I use this snippet I picked up in vim wiki to switch between open buffers (mapped to F5):
" switch between numbered buffers
:nnoremap <F5> :buffers<CR>:buffer<Space>
(put in your .vimrc file or whichever dotfile you use).
As for incremental search across open buffers, whenever I look up something using either /[something] or with */# on current word, it's automagically also highlighted in other buffers/tabs. Then I can switch buffers and hit n or N to move between matches in the currently viewed buffer. That's already baked into Vim.
Hope that helps.
The :set switchbuf=usetab solution given by ib never worked for me for whatever reason (even without loading plugins or my .vimrc) but :tab drop name-of-file works just the way you want (I found it on the Vim wiki).
Make it a custom mapping to save a few keystrokes with nnoremap <leader>t :tab drop.
Also I second ib's comment on the right and wrong way to use tabs in Vim.
When I cut or paste, and possibly other times, my xcode will suddenly pop open that upper window above my code display, the window that lists the file names and roles and code size. This only started happening today, so I'm wondering if I accidentally triggered some setting. It's really annoying as I drag the horizontal window bar up to cover it so I can maximize my code window view and it comes back down minutes later after some editing action (cut, paste, something). I don't know if this possibly has to do with my having a split window view (two code windows one above the other) perhaps.
Does anyone know how to stop this from happening?
It could be a bug related to split views. I do not have a solution, but I do have a workaround. Select the file you are editing and press enter. Then create a split view and open the next file the same way. You will now have a separate editor window with the two files. Since this window does not have the file lists, it cannot show them.
I finally figured out how to split panes in Xcode, and I even finally found out that if I hold option when I split panes, I can do a vertical split too.
But I seem to have run into a bug. When I spawn a separate text editor and split panes within it, I can split panes horizontally, or vertically, but not both. Has anyone else run into this?
However, if I split within the main project window, which includes Groups & Files pane, I can split both ways.
What's the deal?
Oh how I wish I could just do Cocoa in emacs. C-x 0,2,3, and my favorite C-x C-f.
While I'm at it, how do I jump down a block, like I would do with ctrl-down in emacs?
That certainly seems to be a bug; you should file it with Apple.
Oh how I wish I could just do cocoa in emacs
What's stopping you? Cocoa code is just made up of text files like anything else. I've certainly never had any problems editing Objective-C in vi.