I followed along this thread(Makaze's answer) to change the padding of my Ubuntu terminal.
And now that I have successfully done that, I can't seem to work from cygwin, as, compared to my ubuntu terminal now it seems awkward.
Is there any way I can change(i.e increase) the padding in cygwin?
There is no .config folder to begin with.
Related
I have looked at duplicate questions. Nothing has worked.
I use Gitbash, and when using Cygwin, I source the gitbash prompt (/Git/etc/bash.bashrc) to display the same prompt. In Gitbash, the prompt works. In cygwin, the output line wraps. For example:
[ "$python_version" ] && python_version='\[\033[95;38;5;227m\]🐍'"${python_version##* } "
This line causes a wrap (only in cygwin) when appended to PS1. The minttyrc and color settings are exactly the same. Removing the color, which I think is the problem, fixes the wrap. However, I believe everything is escaped correctly, and as it doesn't wrap in gitbash, I don't know what the problem is.
The color here seems to be the issue, as removing it fixes it. But why? What is so different about the terminals? I also wonder if it could be an issue with an early escape, but PyCharm's shellcheck says it's all fine.
Wrapping example:
Cygwin:
⬢14.7.0p/new 🐍3.8.3 (venv) ❯
GitBash (ideal output):
~/Desktop/new 🐍3.8.3 ⬢14.7.0 (venv) ❯
It only occurs within the prompt (PS1 variable, aka PROMPT_COMMAND); not when actually typing out commands in the terminal.
Answer: Cygwin is trash (excuse the exaggeration). It has so many utilities but many have encountered bugs like this, and it is really a shame. I uninstalled it, removed its variables from PATH, and with C:\Program Files\Git\bin added to such, I could now ssh in using ssh -t user#host bin "bash -l". This gave me a correct prompt, in ssh or not, with no wrapping; I was able to install other utilities, such as g++, using MinGW. I hope Cygwin gets things sorted out soon, as I debugged in every single way; changed no code, uninstalled it, and then had a successful output.
I recently switched from bash to zsh and now the tabstops in my Ultisnips-snippets aren't working properly anymore.
I didn't change anything in my snippet files and after I encountered the problem for the first time, I went back to bash, started vim from there and the snippets worked as intended again.
I have these to snippets
snippet ( iA
($1)$0
endsnippet
snippet mk wA
$$1$$0
endsnippet
If I run vim from bash and type mk, it will expand to
$Cursor$
(I will denote the cursor position by Cursor). Then I can type f( and it will expand to
$f(Cursor)$
If I press x and then tab it will take me to
$f(x)Cursor$
(I will call this previous step S). Pressing tab again I will arrive at
$f(x)$Cursor
Running vim from zsh however, I can still do the steps until S but if I then press tab, it will stay at
$f(x)Cursor$
and start inserting tabs after that. If I only do mk however and type something else without brackets, for example ab
$abCursor$
and then press tab, it will work as expected and get me to
$ab$Cursor
Does anybody have an idea what's going on here? What can I do if I want to keep using zsh and Ultisnips? If I run bash -c 'vim file.txt', vim will work really slowly and lag a lot, so that is not really an option.
Any help would be appreciated.
Edit: Apparently the problem has something to do with what version of vim I'm using. I use macOS and the problem I described happens when I use the default vim version. If I use a custom-compiled version of vim, it works as expected. And as it turns out I have some config file that tells bash to use the custom-compiled version, whereas zsh still uses the default one. I also tried it on my PC (running Ubuntu) and with the vim version installed there, it also worked. So I guess, I'll use my custom-compiled vim to avoid this problem...
But does anybody know, what vim setting could be responsible for this? If I'm not mistaken my custom-compiled version is just the huge-feature version of vim.
I have been spending some time looking for the solution. I have reinstalled Vim on my mac for several times using MacPorts. The vim --version command show that +clipboard and +xterm_clipboard, so I should be good to go. However, when I type "+yy or "*yy inside vim, the :reg command show that the register changed to the current line, but when I do paste outside vim, the content still did not change. Everything in vim I can tolerate to trade off its super flexibility, however, this copy/paste which is frequently used but extremely difficult in vim really driving me crazy...
I've found that if I add set clipboard=unnamed to my .vimrc, then pasting outside of vim will paste the contents of the * register. For + you might try set clipboard=unnamedplus.
Problem solved. I am always using system vim, which is /opt/local/bin/vim. I think there was some glitch going on there. So I installed MacVim, and link vim to MacVim by adding the following code to my bash profile (~/.bash_profile)
alias vim='/Applications/MacVim.app/Contents/MacOS/Vim'
Registers work perfectly with MacVim. Even though vim --version reveals that it is +clipboard but -xterm_clipboard.
For me, it was a matter of updating the vim that ships with OS X (7.3) via homebrew to 7.4.
this is the situation:
I have a virtual machine with vagrant, it has ubuntu precise32, I have been installed byobu on it, and byobu tunned the promp.
I have in my host machine macosx, the regular macosx terminal emulator, and have been installed oh my zsh, which changed the shell from bash to zsh, and tunned the colors to a very fancy theme.
well, when i connect to vagrant via ssh, all color configuration disappear, and i suppose it loads the configuration from the ~/.bashrc file in the virtual machine.
how can i change the bright purple colors ? is there any bash theme palette cool to install that you would recommend ?
this is the my terminal
thanks.
NOTE: I don't know too much about byobu, but I guess it's similar to tmux.
The simplest thing to do is to install zsh and oh-my-zsh within the vagrant box (suppose you change the default shell by using chsh from bash to zsh). Then when you vagrant ssh to the VM, you'll be using zsh and see all the fancy stuff.
Not sure how purple is set, whether it is byobu customization or settings in .bashrc.
Anyways, if you want to use bash, enable 256 color terminal by setting TERM=xterm-256color, set the prompt colour as you wish, example Gist if you want to use Bash.
I have managed to get colors and a lot of additional features by installing bash-it.
It's straightforward to install. The installation takes backup of the current ~.bashrc and you can always switch back without any risk.
I'm trying to get 256 colors in the fantastic ConEmu-Maximus5 console.
Update: Now it only shows 8 colors. I know because '$tput colors' output is '8'
I have followed the instructions and activated:
TrueMod (24-bit color) support
Inject ConEmuHk
ANSI x3.64 / xterm 256 colors
I don't understand what to do with 'check off whether the buffer / slide.'
I'm in windows 7.
I start ConEmu with a custom direct link, so it loads cygwin bash file.
"C:\Program Files\ConEmu\ConEmu64.exe" /cmd ""C:\cygwin\bin\bash.exe" --login -i"
In my bashrc profile I have -> export TERM=cygwin
This is my custom command prompt:
function prompt {
local RED="\[\033[0;31m\]"
local GREEN="\[\033[0;32m\]"
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
PS1="$COOLRED\u#\h $LIGHT_COOLGREEN\$PWD \[\e[0m\] > "
}
prompt
The value of ConEmuANSI in ON, by the way.
I have some screen shots:
As you can see the command prompt looks very extravagant because it doesn't like the 256 color settings. If i substitute the variables COOLRED and COOLGREEN with RED and GREEN, then it looks ok, but it's not 256 colors.
More screenshots of the settings:
And the last sceen shot it's cygwin's mintty. Everything is ok there. Full 256 color supported. It's a shame mintty doesn't have tabs. That's mostly the reason why I'm trying to move to ConEmu.
Thank you very much for helping!!!
Bash does not send ANSI sequences to console. It tries to process them itself. And, because *nix terminal is generally only 8-color (not taking into account 256-color mode), bash uses 8-color palette instead of 16-color palette which is common to Windows terminal.
I think, 256-colors works in mintty because _isatty returns zero in that terminal. But it returns non zero value under ConEmu. May be in future builds I solve this puzzle (how to create real terminal with PTY features for some applications).
As for the question
You have no need in 256-colors In fact. To redefine prompt palette you may use "Extend foreground colors with background" feature. In breaf - set up colors 16, 17, etc. in ConEmu, set prompt background in bash to #5 (configurable in ConEmu), and voila.
There was a small bug in ConEmu "Extend..." processing. Use build 121016 or later.
PS1="\e[30;45m\u#\h \e[34;45m$PWD \[\e[0m\] > "
Following info does not match the question, but may be useful
Current version does not support 256-color mode in 'whole' console buffer (limitation, yes, removing it in plans).
So, you can go 2 ways
totally disable scrollback buffer (many ways, for example "cmd -cur_console:h0")
work in the bottom of the scroll-buffer.
I also couldn't get 256 color support to work (the colors would show up, but they looked the same as the 16-color palette). I switched to the "xterm" color scheme and now it works in native Windows executables (such as Python) but not in anything that uses Cygwin. Cygwin appears to have terminal-escape-sequence processing that you can't turn off, which defeats the ConEmuHk injection.
This is documented on the ConEmu wiki, here.
I had this weird problem and the weird solution and somehow it works. and don't know if this is with others too, just some info-sharing in case this shall be helpful.
I like colouring my consoles and like to utilize the full real 256 bits of RGB colouring.
After confuguring as in the conemu/CMDer (i used the forked one) instruction. my 256bit coloring test looked like this.. After mucking around a bit and testing with my bash 256bit capability. i.e running this command:
for i in {1..16384}; do echo -en "\e[38;5;${i}mTest";done
*note supposed to be {1..256}, but i had to force it for a longer colour prints, so just took a longer random number..
giving the result:
But running some 2-3 times, i saw this clean gray shade suddenly
and it worked then on..
weird but i got this working. Could it be that CMDer is somehow not using the full 256 bit because of optimizing reason and it get triggered when it is kicked in??,
PS: my CMDer cmd for the console:
-cur_console:fp -cur_console:d:"C:\WS":P:"<Cobalt>":t:"test":C:"C:\Arbeit\tools\Iconka-Buddy-Ninja.ico" set "PATH=%ConEmuDrive%\Program Files\Git\usr\bin;%PATH%" & "%ConEmuDrive%\Program Files\Git\git-bash.exe" --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe /usr/bin/bash.exe -l -i
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
Those \es are probably from an e.g. C printf string. You don't want them in a shell script. Stick with the original \033 notation. Also you are missing the closing \]. These lines should now read
local COOLRED="\[\033[38;5;173m\]"
local COOLGREEN="\[\033[38;5;113m\]"