Cmder wrong colors using Windows Terminal - windows

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.

Related

URxvt uses dark colors for prompt instead of light (which xterm uses)

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.

Updating the tab/file status after saving in a Sublime Text Plugin

This may be an old bug; I found this report. I'm using Sublime 3 but I think this code also works on 2.
When I call self.view.run_command('save') within a plugin, the save does happen -- I can type the file in a console window and see the results. The dirty flag seems to get cleared. But the tab for the file contains a dot rather than an x, indicating the file hasn't been saved. And sure enough, if you try to close it, it asks if you want to save the file.
Is there any way to refresh the file window so it recognizes that the file has been saved?
Here's my plugin code: (This is my first plugin so please excuse obvious style issues)
# Sublime Text plugin to insert output in the OUTPUT_SHOULD_BE comment
# Bind to key with:
# { "keys": ["f12"], "command": "insert_output" },
import sublime, sublime_plugin, pprint, os, re
class InsertOutputCommand(sublime_plugin.TextCommand):
def run(self, edit):
outfile = self.view.file_name().rsplit('.')[0] + ".out"
if not os.path.exists(outfile):
sublime.error_message("Not Found: " + outfile)
return
out_data = open(outfile).read().strip()
region = self.view.find(r"/\* OUTPUT_SHOULD_BE\n", 0)
if region:
self.view.insert(edit, region.end(), out_data)
self.view.run_command('save')
self.view.window().focus_view(self.view)
else:
sublime.error_message("Not Found: OUTPUT_SHOULD_BE")
I'm sure this is probably a terrible hack, but it works:
self.view.run_command("save")
# Refresh the buffer and clear the dirty flag:
sublime.set_timeout(lambda: self.view.run_command("revert"), 10)
The revert command, which must be delayed in order to work, simply brings back whatever is stored in the file. Since the file was successfully saved on disk, this is just the same file that we already see on the screen. In the process, the dirty flag is cleared and the dot on the file tab becomes an x.
Feels very hacky to me and I'd love a more proper solution. But at least it works, ugly or not.

Vim slow with ruby syntax highlighting

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.

.Rprofile: How to set option "browser" correctly (to Chrome) so that help.start() works?

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.

Uncaught Throw generated by JLink or UseFrontEnd

This example routine generates two Throw::nocatch warning messages in the kernel window. Can they be handled somehow?
The example consists of this code in a file "test.m" created in C:\Temp:
Needs["JLink`"];
$FrontEndLaunchCommand = "Mathematica.exe";
UseFrontEnd[NotebookWrite[CreateDocument[], "Testing"]];
Then these commands pasted and run at the Windows Command Prompt:
PATH = C:\Program Files\Wolfram Research\Mathematica\8.0\;%PATH%
start MathKernel -noprompt -initfile "C:\Temp\test.m"
Addendum
The reason for using UseFrontEnd as opposed to UsingFrontEnd is that an interactive front end may be required to preserve output and messages from notebooks that are usually run interactively. For example, with C:\Temp\test.m modified like so:
Needs["JLink`"];
$FrontEndLaunchCommand="Mathematica.exe";
UseFrontEnd[
nb = NotebookOpen["C:\\Temp\\run.nb"];
SelectionMove[nb, Next, Cell];
SelectionEvaluate[nb];
];
Pause[10];
CloseFrontEnd[];
and a notebook C:\Temp\run.nb created with a single cell containing:
x1 = 0; While[x1 < 1000000,
If[Mod[x1, 100000] == 0,
Print["x1=" <> ToString[x1]]]; x1++];
NotebookSave[EvaluationNotebook[]];
NotebookClose[EvaluationNotebook[]];
this code, launched from a Windows Command Prompt, will run interactively and save its output. This is not possible to achieve using UsingFrontEnd or MathKernel -script "C:\Temp\test.m".
During the initialization, the kernel code is in a mode which prevents aborts.
Throw/Catch are implemented with Abort, therefore they do not work during initialization.
A simple example that shows the problem is to put this in your test.m file:
Catch[Throw[test]];
Similarly, functions like TimeConstrained, MemoryConstrained, Break, the Trace family, Abort and those that depend upon it (like certain data paclets) will have problems like this during initialization.
A possible solution to your problem might be to consider the -script option:
math.exe -script test.m
Also, note that in version 8 there is a documented function called UsingFrontEnd, which does what UseFrontEnd did, but is auto-configured, so this:
Needs["JLink`"];
UsingFrontEnd[NotebookWrite[CreateDocument[], "Testing"]];
should be all you need in your test.m file.
See also: Mathematica Scripts
Addendum
One possible solution to use the -script and UsingFrontEnd is to use the 'run.m script
included below. This does require setting up a 'Test' kernel in the kernel configuration options (basically a clone of the 'Local' kernel settings).
The script includes two utility functions, NotebookEvaluatingQ and NotebookPauseForEvaluation, which help the script to wait for the client notebook to finish evaluating before saving it. The upside of this approach is that all the evaluation control code is in the 'run.m' script, so the client notebook does not need to have a NotebookSave[EvaluationNotebook[]] statement at the end.
NotebookPauseForEvaluation[nb_] := Module[{},While[NotebookEvaluatingQ[nb],Pause[.25]]]
NotebookEvaluatingQ[nb_]:=Module[{},
SelectionMove[nb,All,Notebook];
Or##Map["Evaluating"/.#&,Developer`CellInformation[nb]]
]
UsingFrontEnd[
nb = NotebookOpen["c:\\users\\arnoudb\\run.nb"];
SetOptions[nb,Evaluator->"Test"];
SelectionMove[nb,All,Notebook];
SelectionEvaluate[nb];
NotebookPauseForEvaluation[nb];
NotebookSave[nb];
]
I hope this is useful in some way to you. It could use a few more improvements like resetting the notebook's kernel to its original and closing the notebook after saving it,
but this code should work for this particular purpose.
On a side note, I tried one other approach, using this:
UsingFrontEnd[ NotebookEvaluate[ "c:\\users\\arnoudb\\run.nb", InsertResults->True ] ]
But this is kicking the kernel terminal session into a dialog mode, which seems like a bug
to me (I'll check into this and get this reported if this is a valid issue).

Resources