I've just moved from xterm to URxvt and the shell prompt with URxvt uses the dark version of the colors instead of the light. Not sure if there's something obvious I've missed in the switch.
xterm prompt:
URxvt prompt:
.Xresources with xterm:
XTerm*font: xft:Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True
! sync primary and main clipboards
XTerm*selectToClipboard: true
! double-click highlights words until blank text
XTerm*VT100.cutNewLine: false
XTerm*VT100.cutToBeginningOfLine: false
XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48
xterm*highlightSelection: true
! XTerm*font: 9x15
XTerm*faceName: Inconsolata
XTerm*faceSize: 13
XTerm*allowBoldFonts: false
XTerm*boldMode: false
XTerm*colorBDMode: true
XTerm*foreground: #c5c8c6
XTerm*background: #111111
*cursorColor: #aeafad
*color0: #000000
*color1: #912226
*color2: #727b33
*color3: #ae7b00
*color4: #1d2594
*color5: #682a9b
*color6: #2b6651
*color7: #929593
*color8: #666666
*color9: #cc6666
*color10: #b5bd68
*color11: #f0c674
*color12: #81a2be
*color13: #b294bb
*color14: #8abeb7
*color15: #ecebec
.Xresources with URxvt:
URxvt.scrollBar: false
URxvt.font: xft:Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True
URxvt.intensityStyles: false
URxvt.highlightSelection: true
! Fix ctrl moving through words
URxvt*altSendsEscape: true
URxvt.keysym.Control-Up: \033[1;5A
URxvt.keysym.Control-Down: \033[1;5B
URxvt.keysym.Control-Left: \033[1;5D
URxvt.keysym.Control-Right: \033[1;5C
! sync primary and main clipboards
URxvt.selectToClipboard: true
URxvt*background: #111111
URxvt*foreground: #c5c8c6
URxvt*cursorColor: #aeafad
URxvt*color0: #000000
URxvt*color1: #912226
URxvt*color2: #727b33
URxvt*color3: #ae7b00
URxvt*color4: #1d2594
URxvt*color5: #682a9b
URxvt*color6: #2b6651
URxvt*color7: #929593
URxvt*color8: #666666
URxvt*color9: #cc6666
URxvt*color10: #b5bd68
URxvt*color11: #f0c674
URxvt*color12: #81a2be
URxvt*color13: #b294bb
URxvt*color14: #8abeb7
URxvt*color15: #ecebec
The short answer is that xterm and urxvt do not combine bold attribute with color in the same way. In ncurses, that should be reflected in the ncv (no color video) mask (and tell ncurses to not bother trying to do that), but your shell-prompt isn't that sophisticated — and you'd probably not like it to stop doing bold, even though the result is not quite what you'd expect.
You can see the differences using tack, though Fedora seems not to have packaged that (it's been separate from ncurses for more than 10 years). Here's a screenshot comparing xterm and ncurses, using the terminal descriptions provided by Fedora (but see this page):
It was a combination of URxvt.intensityStyles being set to false, and the bold font.
I've removed URxvt.intensityStyles: false from the config and added URxvt.boldFont: Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True.
Related
I am trying to use Cmder in Windows Terminal. I tried following this guide, and I did everything as it says.
However, there is a small issue. No matter what I do, the prompt background colour does not change, it stays black.
I couldn't figure out the issue. Any suggestions?
In the comments section of the same article
I ran into this issue as well and was able to get it working. In your
"%cmder_root%\config" directory, create a file called "my_prompt.lua"
and add the following to it:
function my_prompt_filter()
cwd = clink.get_cwd()
prompt = "\x1b[1;32;49m{cwd} {git}{hg}{svn} \n\x1b[1;39;49m{lamb} \x1b[0m"
new_value = string.gsub(prompt, "{cwd}", cwd)
clink.prompt.value = string.gsub(new_value, "{lamb}", "λ")
end
clink.prompt.register_filter(my_prompt_filter, 1)
Kudos to Eric Grandt
#AMagyar 's answer is great, except that if you use conda, pyenv or other virtual environments, that information would be omitted (when it should be (base) λ, you will get λ). Instead, you can create my_prompt.lua as something like:
function my_prompt_filter()
local prompt = clink.prompt.value
prompt = string.gsub(prompt, '^\x1b%[1;32;40m', '\x1b[1;32;49m')
prompt = string.gsub(prompt, '\n\x1b%[1;39;40m', '\n\x1b[1;39;49m')
clink.prompt.value = prompt
end
clink.prompt.register_filter(my_prompt_filter, 1)
Everything is settled.
What controls the terminal text & background color?
In function set_prompt_filter in %cmder_root%\vender\clink.lua, you may read lines like:
local cmder_prompt = "\x1b[1;32;40m{cwd} {git}{hg}{svn} \n\x1b[1;39;40m{lamb} \x1b[0m"
This is the prototype of cmder prompts. The {cwd}, {git}, {lamb}, etc, are to be substituted with the actual content later on. The \x1b[1;32;40m is the ANSI escape sequence that controls the color of following text. 32 means green text color, 40 means black background color, 39 means default text color, and 49 means default background color.
Why was pyenv/conda environment omitted?
Also in function set_prompt_filter in %cmder_root%\vender\clink.lua, you may find how cmder added the information of virtual environments into {lamb} (or more specifically, prompts with () or []). So either you have to retrieve that information from the original prompt, or simply just replace the color codes, as in this answer.
I want to use wkhtmltopdf to render both pages I control (in which case I can set the window.status when done rendering) and (occasionally) pages I don't control. According to this thread on the mailing list I should be able to set --window-status to some value, and --javascript-delay as well, and rendering starts as soon as either of these conditions is met. That's not my experience; the command wkhtmltopdf --javascript-delay 10000 --window-status imdone http://www.google.com/ /tmp/google.pdf waits forever (version 0.12.3, both on OSX and linux). How can I get the behaviour as described on the mailinglist?
One workaround is to use the --run-script tag to set the window.status after some time manually -- this works both on the version that uses the patched and that that uses the unpatched QT. Note however that --run-script seems to have a small bug in escaping its parameter. Therefore the following line will give you the behaviour requested:
wkhtmltopdf --window-status imdone --run-script \
'window.setTimeout(function(){window.status="imdone";},1000);' \
http://google.com/ /tmp/google.pdf
Note that because of aforementioned bug, it doesn't work if one puts spaces in the --run-script argument, hence the following will not work
wkhtmltopdf --window-status imdone --run-script \
'window.setTimeout(function (){window.status = "imdone";}, 1000);' \
http://google.com/ /tmp/google.pdf
I'm using different bash prompt string color in my server and local computer, so that I can easily be aware of where I am.
But when I use pry in server there is only white and black.
Is there a way to colorize prompt string of pry?
As an easy way, you can just:
Pry.config.prompt_name = "\e[0;31m#{Rails.env} \e[0m" # 31 means red
Pry.config.prompt_name = "\e[0;32m#{Rails.env} \e[0m" # 32 means green
You will see something like:
[2] production (main)>
^ red or green
There's this gem called pry-theme. Have a look.
Install using gem install pry-theme
I've been using vim over ssh to work for a week or two now and all has been going great. Today I decided to add in some syntax highlighting, autocomplete, and some other general plugins. Set up vundle and went to work.
My current .vimrc can be found at https://github.com/scottopell/dotfiles/blob/master/.vimrc
I have cloned my vimrc and vim files onto my local ubuntu desktop and vim runs exactly as expected, no slowness on any files that I can find. Same plugins and same vimrc and no slowness on ruby files.
update
I can reproduce this issue with the following .vimrc
syntax on
and an empty ~/.vim folder.
However, vim on this vps is very slow with ruby/haml files. Much moreso ruby files. When I open any ruby file, startup takes about 2 seconds (timed with --startuptime). With a comparable length haml file, its about .5 seconds. This slowness isn't just on startup either, moving around and editing the file are both painfully slow.
Haml/erb(they are basically the same)
268.818 000.005: before starting main loop
848.871 580.053: first screen update
Ruby
199.613 000.004: before starting main loop
2937.859 2738.246: first screen update
Without syntax highlighting on the same ruby file as above
149.047 000.004: before starting main loop
152.912 003.865: first screen update
I have tried using mosh(http://mosh.mit.edu) and it doesn't help. not really relevant anymore
As you can see in my .vimrc file, I have tried a few different solutions to this problem.
I have tried running with all plugins disabled (I moved them all from ~/vim/bundle/PLUGINNAME to ~/vim/bundle/disabled/PLUGINNAME, is this correct?), set ruby path, set foldlevel to manual, disabled my colorscheme, nothing helps. see edit3
I can post the full startupttime log for any file if that will help.
I have tested a few other languages(php, c, python, vimL) and none experience any slowdown.
EDIT: Just to clarify, I am running an ssh session with ssh user#server then once inside the server I am doing vim file.rb.
EDIT2: I just tried accessing the server directly and the slowness persists without ssh, I have updated to reflect that this isn't a problem with ssh.
EDIT3: I can reproduce the issue with a .vimrc file that contains the single line syntax on with an empty ~/.vim folder
EDIT4 I uninstalled my compiled version of vim and any versions that I may have installed through apt, manually removed all vim stuff from my system, and I can run vim with vim -u NONE /path/to/file.rb then do :syn on and the issue will be there. The file in question is a rails controller, but like I've said, I can recreate it to some degree with most any file, but rails controllers see to be the worst.
The solution to this problem turned out to be the regex engine that vim uses.
The speculation on #vim on freenode is that the ruby syntax files use something that is slower on the new regex engine.
Any version older than and including Vim 7.3.969 has the old regex engine.
Add in set re=1 to your vimrc to force the old regex engine on any version newer (and don't forget to reload the file you're currently editing with :e).
Thanks to Houl, Dolio and dmedvinsky from #vim for help figuring it out.
I haven't had a chance to try the absolute latest version, there was a commit last night that may help with this issue. I will update this if I get the chance to try the bleeding edge version again.
You should set this tw options in your vimrc:
set ttyfast
set lazyredraw
If this is not solving your problem try to start vim without your vimrc to be sure that none of your current settings are screwing it up.
vim -u NONE
Two things that will drastically help speed up Ruby syntax highlighting are disabling cursor line and relative number for Ruby (if you use those).
I have the following in my .vimrc:
" Ruby is an oddball in the family, use special spacing/rules
if v:version >= 703
" Note: Relative number is quite slow with Ruby, so is cursorline
autocmd FileType ruby setlocal ts=2 sts=2 sw=2 norelativenumber nocursorline
else
autocmd FileType ruby setlocal ts=2 sts=2 sw=2
endif
I'm using vim 7.4.52 and none of these solutions worked for me.
According to this github comment on the issue (https://github.com/vim/vim/issues/282#issuecomment-169837021), foldmethod=syntax is responsible for the slowness.
Adding this to my .vimrc finally fixed it!
augroup ft_rb
au!
" fix the SLOOOW syntax highlighting
au FileType ruby setlocal re=1 foldmethod=manual
augroup END
Try setting your ruby path explicitly in your vimrc:
let g:ruby_path="/usr/bin/ruby"
see UPDATE at the bottom.
this may be helpful as a workaround -
i am using vim version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:40:46)
Included patches: 1-52
it is the stock version from
Linux Mint 17.1 Rebecca.
the php.vim syntax file is not version'd that i can see, but it sez last edit'd 28 aug 13.
it isn't a ruby project, but when editing a large php class file (
$ php -w test.inc | wc
2 2410 19220
) i note significant delays near the top of the class, but not above or below the class, and, notably, not toward the bottom of the class. as i attempt to insert new text near the bottom of the class, delay is minimal and seems to be proportional to the line number inside the class. "minimal" means almost instantly, "significant" means 1 to 1.5 seconds per character.
the file is approx 1800 lines with approx 500 lines of legit php and 1300 lines of comments and doc. the class begins at approx line 30 and ends at approx line 1700. it is conceded it's a bit large, but well documented :-\
if i insert
class dummy { }
in front of the original "class originalName {",
there is no delay anywhere in the file. this unsightly kluge permits vim/gvim to regain its responsiveness and could be considered a workaround. note no linefeed between the two, just
class dummy { } class originalName {
it can even be comment'd out:
/*class dummy {}*/class originalName {
additional info:
during this test, the plugins directory was moved.
with "set syntax=off", the problem completely disappears. this is NOT a fix.
setting the regular expression engine with
set regexpengine=1 (or any other number)
does not appreciably change the results.
based on these results, i would suspect the regular expression engine as well. my point is that diddling a bit with the syntax in ruby files may lead to a workaround.
UPDATE:
i have found that the issue is "caused" by setting php_folding to 1 (enabled). the vimrc i THOUGHT i was using was not, but at least some of the mystery is solved due to that mistake. a simple vimrc like this will induce the problem (for me, as least):
:syntax enable
:let php_folding = 1
this means my issue is totally unrelated to the ruby issue, but there may be a similar thing going on with the ruby.vim file. maybe not.
apologies for the deflection.
I tried most of these solutions but what ended up working for me the best was removing any plugins associated with airline.
I work on Mac OS X 10.7.3 with R version 2.14.0 (2011-10-31). My ~/.Rprofile is
options(repos=c(CRAN="http://cran.ch.r-project.org",
BioC="http://www.bioconductor.org",
Omegahat="http://www.omegahat.org/R"),
pdfviewer=path.expand("~/R/misc/shell_scripts/skim"),
browser="mybrowser")
where mybrowser is a file in /bin/ which contains open -a "/Applications/Google Chrome.app". When I open R and type help.start(), all I obtain is that Chrome becomes active, but no real output from help.start(). How can I properly set up browser in options so that help.start() works as expected?
I originally just had browser="Chrome", but R couldn't find the browser. I tried several kinds of things to solve this (e.g., browser="/Applications/Google Chrome.app" [and various variants to escape the blank]), but none worked. I guess that's because sh /Applications/Google\ Chrome.app just does not work. On the Mac, applications are opened via open -a ..., that's why I created mybrowser. That finally opened the browser, but I couldn't figure out how to get help.start to work properly.
Create a Renviron file in your home (i.e ~/.Renviron) and add this line.
R_BROWSER=google-chrome
I'm not sure about "chrome" part, i use conkeror and my setup is :
R_BROWSER=conkeror
But this should do the tricks
In the meantime, Hans-Joerg Bibiko helped out: the solution is to set browser to browser="/usr/bin/open -a 'Google Chrome'"
If you look in utils:::print.help_files_with_topic (the function that actually issues the call to browseURL()), there is this really annoying line:
if (.Platform$GUI == "AQUA" && type == "html")
browser <- get("aqua.browser", envir = as.environment("tools:RGUI"))
And since .Platform$GUI == "AQUA" on OSX, this means that you have to do some trickery to browse help files in your favorite browser. Hence, in my .Rprofile (located here path.expand('~/.Rprofile'), of course), I included these lines.
options(help_type='html')
options(browser="/usr/bin/open -a '/applications/Google Chrome.app'")
p <- .Platform
p$GUI = 'unknown'
unlockBinding('.Platform', as.environment('package:base'))
assign('.Platform', p , envir=as.environment('package:base'))
lockBinding('.Platform', as.environment('package:base'))
rm(p)
So far it doesn't seem to have any effect other than enabling use of an alternate browser, but you may want to read the section labeled "Aqua" in ?.Profile if you're worried about messing around with base.