I use a layout with avoidStruts so that I can bind key
((myModMask, xK_b), sendMessage ToggleStruts)
to hide the xmobar toolbar.
Now I have a strange behaviour:
When restarting XMonad with "mod-q", XMobar in a GNOME
session gets hidden behind the background window
and doesnt come up again. ToggleStruts still seems to
works though, only that only the background is visible where
the XMobar should be.
Here are my config files:
https://github.com/eiselekd/dotfiles/blob/master/.xmonad/xmonad.hs
Is there any easy workaround? Maybe send the background window behind the XMobar again...
I know that there are the XMobar options
overrideRedirect = False
lowerOnStart = False
however whilst XMobar is visible on startup when these
options are added, the XMobar window is suddenly not hidden by ToggleStruts
any more. So I dont want to use these.
Another possibility that I tried and that is working is to spawn in the StartupHook
xdotool windowraise `xdotool search --all --name xmobar`
to raise XMobar via xdotool, however I would like to know a
XMonad/Haskell command instead.
Related
I decided to try Xmonad today and installed it on VM with Arch linux. Without spacing it works perfectly, but when I am adding it, Xmonad only show one newest window on screen (if I open new window, old one just disappear).
There is my simple configuration I made using information from there:
import XMonad
import Xmonad.Layout.Spacing
main :: IO ()
main = xmonad $ def
{ layoutHook = spacingWithEdge 10 $ Full
}
Sorry if I am being dumb. This is my first time using Xmonad and Haskell.
Your configuration replaces the default layoutHook with one that only makes the Full layout available. Changing the relevant line to...
{ layoutHook = spacingWithEdge 10 $ layoutHook def
... should add the spacing while keeping all the default layouts available. Note that:
You can switch between the available layouts, with the default key binding being Alt + Space; and
You can switch the focused window, even while using the Full layout, with the default key binding being Alt + Tab.
Basically re-asking "How do you configure Msys's default size, color, and font?" after 11 years when all the answers are not applicable any more.
So, git-bash / msys2 start under mintty. How to configure mintty's default background color? I want to change it from pure black to a certain grey.
Also, I found that for the mintty under msys2, the vertical scrollbar is not working. I.e. I am unable to scroll back at all. Mouse scrolling only scroll the command line, not the window. That's a mis-configuration that I want to fix as well.
UPDATE:
So with the icon in the upper left of the MinTTY, I got my color right, but scrollbar was still not working:
until I got out of tmux and realized it was a tmux problem.
So all good now.
You can click on the icon in the upper left of the window and then select "Options" to open the MinTTY Options. There are options for colors and whether to have a scrollbar.
I've just recently begun experimenting with urxvt as a terminal emulator rather than xterm. I'm a heavy tmux user, so having both work seamlessly together is a must.
I've noticed that when running tmux inside urxvt, there is some odd behavior when selecting text. I hold shift, use the mouse to select text, and the text is highlighted in yellow (as if tmux is still handling it) but then blinks and flashes to a black background -- almost as if urxvt and tmux are competing for control of the selection. Does that make sense?
I've test this with zero (except enabling the mouse in tmux) personal configuration options in both tmux and urxvt.
In xterm, when I would hold shift and select text I would notice that it would highlight in reverse colors (as opposed to tmux's yellow background). In urxvt, the selected text still seems to be controlled by tmux.
Any ideas on how to fix this weird behavior?
I'd even be interested in some tips or keywords on how to uncover the problem here. Any developers familiar with the codebase that understand why mouse-selection works fine in xterm, but not with urxvt term?
Thanks to nicm from this issue in the tmux's github repository, the problem you described was solved for me (for tmux 2.1 and urxvt 9.21):
You can disable tmux entering copy mode when dragging by unbinding the
MouseDrag1Pane key binding.
In .tmux.conf, add:
unbind -n MouseDrag1Pane
I just upgraded my Ubuntu laptop from 12.04 to 12.10.
In 12.04, running emacs -nw opened emacs in terminal mode using the terminal color scheme (background, foreground, ..., especially it keeped my transparent terminal background).
Now in 12.10, running the same command results in emacs opened in the terminal with an other color scheme (with a gray background). How can I tell emacs to keep my terminal color scheme ?
Thanks to https://stackoverflow.com/users/774691/john-k-doe's comment, I finally get the reason why my emacs -nw appeared like that.
I edited the font size (for the default face) in an emacs window (launched without the -nw option) and then saved this new setting using the menu entry Options -> Save Options. This action modified my ~/.xemacs/custom.el file loaded by default in my ~/.emacs file. The modification included background and foreground properties for the default face with the value used in "Window" mode.
To solve the issue, I just removed this custom entry from the custom.el file.
I'm not sure that there is a sensible answer to this. After all, a gnome terminal colour theme lists three "colours": (1) Text, (2) Background (3) Bold.
The way Emacs works is that every bit of text is given a "face". A colour theme is a mapping of faces to colours. There are more than three faces...
I've been trying to get colourschemes to work properly in VIM when using it over ssh with PuTTy as a client but unfortunately I haven't had much success. I can only get 8bit colours working with PuTTY even though I've enabled 256 colors in putty and set t_Co=256 in VIM. They don't turn out as they should. I've been trying to replicate this setup http://www.interworksinc.com/blogs/ckaukis/2009/06/03/vim-color-schemes-putty but as I say it's been in vain so far.
Has anyone here had success with colourschemes working with VIM in PuTTy? I'd appreciate any advice
Thanks,
Patrick
[EDIT] Turns out I've found the source of the problem. I was using vim in a screen which was breaking the colours. Updated question I guess is, is it possible to have working colors in a screen session? [/EDIT]
As well as compiled support, it may be necessary to add some config to screenrc (I needed to).
http://www.frexx.de/xterm-256-notes/ has a good guide. The relevant part to screen:
By default, screen is not aware that it is running in a 256 color capable xterm. To make programs in screen recognize this feature, you need to set three things in your ~/.screenrc:
# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"
Yes, you can do 256 colours with screen, however, this option usually isn't compiled in. Simply compile screen yourself with:
--enable-colors256
Alternatively, you could get a tabbed PuTTy. It has the advantage of ctrl-a going to the beginning of the line, and saves you from many termcap headaches. However, if you like to reconnect to your screen sessions from multiple terminals, there really isn't anything better than screen for the job.
NB. This question probably belongs on Superuser.
I had same problem on Mac Os, tried some solutions but all tests show that 256 colors not displayed. After that I'm installed screen from brew and all works great. Maybe it's because Mac Os default screen from /usr/bin/ compiled without --enable-colors256 flag.
Solution for mac os: brew install screen
I had trouble with black background in Putty: blue characters on a black background with default colours are hard to read:
My solution for a better contrast was to enable "system colors" checkbox unter
"Settings / Window / Colours / Use system colors"
This displays the Putty screen with black characters on a white background. Not hip but readable :-)