I am using iterm on my macbook and want to split it into multiple panes (both horizontally and vertically) like conemu. My end goal is to be able to type different git commands in each pane (conemu example). Is iterm capable of doing this?
If it's not possible with iterm, what are my other options?
I know you can "cmd + d" to split but then I only get the same terminal in 2 different panes.
Are you sue you are using iTerm? Any way I'll sugest to forget about it and use Terminal, for a macOS experience. iTerm remembers me of Linux, you have all the options but you'll spend all day configuring it and when finally is ok then some bug will hit and take your peace of mind How to exit alternate screen scrolling on iTerm2 Vim?.
This might help https://apple.stackexchange.com/questions/6504/how-do-split-panes-in-terminal-work. And #BennyPowers answer at https://superuser.com/questions/55459/how-to-get-vertical-split-of-terminal-in-mac-to-execute-different-actions.
I use the macOS native way to split vertically and GNU Screen (which came with macOS) to split horizontally. Execute screen then C-a S (to split into two regions), C-a TAB (to swith to the other region) and C-a c (to open bash).
You can even resize it with C-a : then type resize 10 i.e. and for more man screen.
When its done you exit andC-a k to destroy the window.
For completeness. A lot of people say tmux https://github.com/tmux/tmux/wiki is a better alternative to GNU Screen. I never tried afraid of the same experience I had with iTerm 2.
Related
Looking for a way to control text/cursor highlighting colors when in vi-mode in tmux. I can not seem to find many answers from googling around. I love tmux and use this feature quite a bit, and I have been living with this flaw for some time and still have not been able to find a solution. You can view my dotfiles here. Keep in mind that my master branch is my OSX setup, and I have an "arch" branch for my Arch linux setup. The issues occurs on both systems. Though the colors are slightly different, but not by much.
Here is current symptoms: (both systems) I am in a tmux session, I want to enter into vi-mode for either searching or copying some text. When copying text (hitting v while in vi-mode for visual) the highlighted text and background are both black. So I can't see the text I am highlighting. Or while searching (hit "/" while in vi-mode for searching) my background and text on the entire line where my prompt is for typing the text I want to search is all black. So I have no idea what text is actually in the search. If I mis-type something due to fat fingers and nothing returns in my search, it can be frustrating. One last symptom (which is a minor one, but would be nice to solve) When I do search, I get absolutely no highlighting over than my normal cursor. Not like my vim set up where it highlights currently found, and all other matches.
Here is what the desired fix would look like: Searches would highlight in some shade of yellow or orange on all matched text. Searching prompt to type in search text would be at least readable. Anything but Black on Black. Highlighting text while selecting what to copy in visual mode again anything readable, no Black on Black.
Other things to note: I typically have mouse-mode on in tmux to promote keyboard-driven approach and not allow any selection of text via mouse selection. But when I do toggle this feature off and can then select text via mouse, the highlighted text background is white and text is black. While readable, would still wish to know how to control this color as well. Also (not sure any vim settings actually carry over to tmux) but everything works as desired while actually in vim. Just in case vim settings here. Same note about branches.
Most of my tools are latest versions afaik. This includes Tmux 2.1. I do not have full list of versions of my tools as of right now. If this may play a part in debugging let me know and I'll reply with versions. For what its worth other tools that might be in conflict is my shell I use zsh with on-my-zsh. On my mac I am using iTerm2, on arch I'm using URxvt. Doubt any of my .Xresources matter since it also happens on OSX.
Any help is greatly appreciated. Thanks in advance.
Not sure if this is zsh, iterm2 or the interaction between them.
Trying to change the number of recallable lines in the terminal - not the command history, the output history.
In .zshrc I have :
HISTFILE=~/.histfile
HISTSIZE=100000
SAVEHIST=100000
This seems to be ignored =(
Not sure of the correct term to google, "Terminal output history?"
It's not immediately obvious in the iTerm2 documentation on how to change it.
open the iTerm2 preferences ⌘ + ,
select the Profiles tab
then select the Terminal subtab
Beware, changes to the Scrollback lines value take effect immediately so check Unlimited scrollback now if you don't want to delete your current buffer(s)
change the value of the Scrollback Lines to whatever you'd like
Uncheck the Unlimited scrollback option if you'd like to use your Scrollback lines value
With zsh and iTerm2 Build 3.2.5, an additional step is required: Preferences->Profiles->terminal->check UnlimitedScrollback->Check save lines to scrollback when an app status bar is present
Scrolling was breaking for me without the last one.
It's not a shell problem, it's about your terminal emulator.
You have to find the option in the configuration / options / tools / whatever, for the number of lines to remember.
Apparently you know your terminal emulator is iterm2.
Looking for iterm2 on the google will lead you to the official website, then go to 'Documentation', Ctrl+F 'number' and find
Scrollback lines
The number of lines of scrollback buffer to keep above the visible part of the screen.
This image below helped me to show all the number of lines from console.log().
Please restart the app and you will be able to see the full lines of logs.
Hope this helps!
Briefly:
I would love to add a status bar that sticks to either the bottom or top of my terminal window that provides glancible information (e.g. battery life, signal strength, email count, $PROMT_COMMAND, etc.). Essentially, this will allow the terminal to be opened up to fullscreen and have all the information I could possibly want easily glancible while letting me continue all of my necessary terminal work as normal. I use a mac primarily, but would prefer a *nix compatible solution.
More detail (and what I already tried):
I am a big terminal user and only recently (within a day or two) started using tmux, so I understand that many of you may suggest that I try to use a multiplexer like screen or tmux. While tmux is starting to get very useful to me, it has it's limitations such as a limit to a single-row status bar, which is not ideal since I would want to keep the tab's bar clean without half of it being eaten up by information. Also, I would want to add $PROMPT_COMMAND which displays the current directory, and that could easily eat up most of the status bar depending on where I am in the system.
Also, I tried screen for a bit, which let's you have a hardstatus and a caption which is close to what I want, but it's development seems to have halted. Furthermore, the patch for vertical split panes messes up the graphics of a two-row status bar (very ugly).
Therefore, I think it would be preferable to have a background process running that updates a status bar on part of the screen above my multiplexer ... unless of course tmux has a multi-row status bar implementation that I haven't figured out yet.
I would love to hear about any of your possible solutions, or even your own personal setups if you think it works well for you. Thank you all for any possible help.
A couple of options:
You could run tmux inside tmux (with different configurations; you can use -f to specify a configuration file.)
You could use the tab title, though that's probably not wide enough to include everything you want. (Even if there's only one tab, you can show the tab bar in fullscreen mode). You need to tell tmux to pass the title through; see set set-titles and set set-titles-string.
I'd suggest you use both - put the current directory in the tab title and all the other status info in a separate line maintained by tmux, that way you can just skip the second part when you're not using a full-screen terminal.
I have battery info in mine,
You can get copies of the files you'll need at
https://github.com/richo/dotfiles/blob/master/tmux.conf
and
https://github.com/richo/dotfiles/blob/master/bin/battery
(Make sure that battery is executable and in your PATH)
It'll show you battery percentage in blue (charging), red (discharging) or not at all (fully charged)
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.
Using Terminal.app on OS X 10.5, often you see the commands get garbled when you do a reverse-search with Bash. Is there some kind of termcap or perhaps a bash shopt command that can fix this? It is very annoying.
Steps to reproduce: Open Terminal.app, reverse-search to a longish command. Hit <ctrl>-E once you've found the command. The cursor goes to the end of the line, but the display doesn't update.
I'm guessing this is some kind of problem with the readline library on OS X. It's more of a problem with updating the cursor position after a search than anything else. Basically, ctrl-a and ctrl-e tend to break the search output.
os x terminal failure image http://involution.com/images/osxterminal.png
In the above, the first part of the command should be displayed, and the cursor should be at the end of the line, but it isn't. You literally can't see what you're editing when this happens.
I was able to set my TERM to xterm instead of xterm-color and it solves the problem. (export TERM=xterm).
You may want to look at this post.
bash-prompt-in-os-x-terminal-broken
I had the same problem and it had to do with the PS1 variable. Let me know if this helps.
If the prompt has colors, then this is an acknowledged bug.
See bug report msg#00019.
I've encountered this bug, and while I don't know how to solve it, you can work around it by pressing <down><up>
Not sure whether this is the problem here, but a very common cause of a messed up screen in bash (with any terminal emulator, not just Terminal.app) is the window being resized.
Bash will read the window size when it starts up, and then assume it hasn't changed. When the window is resized a signal will be sent to whatever app is currently reading from the console. If this isn't bash (because you're running a text editor at the time, perhaps), then bash won't know about it.
Solution in this case is to resize the window again so that bash gets the signal and notices the new size.
I can't reproduce this, hitting either Ctrl+E, Ctrl+A or the arrow keys updates the command line correctly. Are you running 10.5.4? Is it perhaps a bug in earlier versions?
In worst case, you could launch the X server (somewhere under utilities) and launch a real xterm.