Not too long ago, I posted this issue to the Cmder GitHub page. After two weeks, it has still gone unanswered, so I was hoping to try my luck here.
Basically, I am seeing odd behavior when resizing a window in Cmder, while running bash.
Here is the issue I posted:
To reproduce, open Cmder, and maximize the window:
While emulating a bash console (Bash on Ubuntu on Windows), shrink window size so that the command line (i.e. PS1 environment
variable), wraps to the next line.
Run the command (can be a simple Enter keystroke, as long as 1. is respected).
Maximize window size, and type a command which is longer than the previous shrunken window. Line should wrap over itself.
Can anyone reproduce this behavior? (Running Microsoft Windows
[Version 10.0.15063])
I did not observe the same behavior while emulating cmd.exe.
What's more is that I don't observe this behavior while running the application "Bash on Ubuntu on Windows".
I also tried to see if the same behavior is observed on ConEmu. When I resize the screen, I get the message: "Maximum console size ... was reached Decrease font size in the real console properties", and I'm guessing this might have to do with my high DPI screen. On top of that, I get the same behavior as in Cmder.
Any help on this is greatly appreciated :D
Related
As the title suggests, my touchpad won't move my mouse. I am therefore unable to select outputs of my commands, but I am able to take screenshots of windows. (Luckily I am used to using keyboard shortcuts)
I have no clue what caused this. I have recently updated my kernel from linux52 to linux53 and linux54. Falling back to either of those versions from linux54 hasn't helped. I have also recently been playing around with a Wacom tablet, using xsetwacom, but I believe my mouse has worked after this.
I know it's not a hardware issue, as libinput debug-events correctly detects my finger running over the trackpad:
The output of 40-libinput.conf in /usr/share/X11/xorg.conf.d/40-libinput.conf is the following. I can't see any error there.
I tried blacklisting the i2c_hid, as suggested in the following question, but to no avail. It fixed an error claiming there was a duplicate mouse, which it decided to ignore. I thought this would help.
What is surprising is that I can click. I can't scroll or move the mouse, though. My trackpad lists the following settings. To my surprise, there is no Accel Speed there, and I can't manually set it with xinput --set-prop 14 'libinput Accel Speed' 1.0, as I need to specify the type and format. I don't know what these are supposed to be, and I don't know if the acceleration is the issue. I read that having a negative value would cause the mouse to never move, though.
Do you have any suggestions as to what to do? What does libinput do with the events after receiving them?
EDIT: Removing the blacklist i2c_hid from the modprobe returns the following Xorg log:
Making a copy of /usr/share/X11/xorg.conf.d/70-synaptics.conf into my /etc/X11/xorg.conf.d/ folder, and commenting out the Option "Ignore" "on" line fixed it.
Had to sudo pkill X after changing it, of course. A reboot would also do the trick.
I cannot find how to change behavior debugger window of IntellJ IDEA 2017.1.2 on Windows 10. I like to use it in unpinned mode, meaning it comes up when build happens (I execute it manually) and when I click on the edited file it goes down. But It does not take full width. It does not go over Project window as you can see in the picture below.
It works by default as I described on Windows 7. I mean it takes full width. Unfortunately, I cannot provide a screenshot about it. That machine is my workstation.
I cannot find in the documentation how to setup this. I assume it is due to Windows 10.
It's controlled by the Widescreen tool window layout option, disable it:
I'm having issues when connecting to our google cloud containers.
The terminal gets restricted to a certain size and it is behaving odd, when using vim for example the application hangs for 10-20 sec if you press Page-Down, but that's something i'm able to work around, the real issue is the following.
When typing a command and the width goes over the width-length of the prefixed size of the terminal, you suddenly don't know where your cursor is.
The same is for editing a file in vim and you start to scroll down or write a shellscript for example and the last line of the document gets updated, only the last line of the file gets updated and the scrolling behavior is suddenly very broken.
This is what the pre-set size of the terminal looks like when editing
a file.
Setting the TERM enviroment variable to "xterm", "xterm-color" makes the colors and the "clear" function work but does not solve these issues.
If anyone else has experienced these issues and know how to fix them, sharing that knowledge would make life worth living again!
Updating your glcoud components to the latest version solved this problem, now i'm able to run fullscreen vim and life is wonderful!
gcloud components update
I started a putty window, changed the font, and then did Windows-Left to fit it to the left side of the screen and it decided to do the screenshot below. The only way i've found to make it go away is the log off/on but that's obviously impractical and doesn't fix the problem.
I've had it in the past but not this bad. It usually happens when I move or resize the window. Is there a setting to have it just auto resize by default?
[edit] and then, about :05 later out of nowhere, it popped away. I'm just sitting here doing something else and it changed back to normal.
That means that you (or someone else) is connected to the same Byobu session from another computer with a smaller terminal size.
You should be able to kick the other session using Alt-F6.
Full disclosure: I am the author and maintainer of Byobu.
For mac user, by querying from the help info ctrl-a + ?, one could simply run the bash script $BYOBU_PREFIX/lib/byobu/include/tmux-detach-all-but-current-client to kick other sessions.
I'm configuring GNU screen in a cygwin environment. Re-configuring actually--it always just worked before, and when I upgraded to cygwin-64 the same config files give me unexpected behavior.
What happens is that whenever I do something in the terminal that overflows a full screen the terminal does not scroll. Instead, each new line "overwrites" the last one on the bottom row of the window. Even when the process is through, if I CTRL+l, there's a bunch of garbage left on the last three lines of the terminal. Also, when I use a program that takes up the entire screen, such as vim or irssi, the "caption" line disappears.
I suspect that there's some discrepancy between my xterm settings and screen's 'term' setting, but I'm a little at sea here and, as I said, all the same configuration files worked fine (and do work fine on other machines--both cygwin and native linux). Can anyone recommend a way to get my beloved screen to behave again?
Here's my .screenrc:
shell /bin/bash
screen -t bash 0
select 0
escape ^Zz # Instead of Control-a, make the escape/command character be Control-z
autodetach on # Autodetach session on hangup instead of terminating screen completely
startup_message off # Turn off the splash screen
defscrollback 30000 # Use a 30000-line scrollback buffer
nethack on
# Misc h4x to make scrollback work
terminfo * te#:ti#
termcapinfo xterm|xterms|xs|rxvt ti=\E7\E[?47l
# Bells are annoying
bell_msg ''
vbell off
caption always '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
You're running screen under xterm (something I do all the time myself). The screen process "knows" how big the terminal is, but that information can be out of sync with reality. I find this happens a lot when I run screen -dr from a different window.
Resizing the xterm windows causes it to send a SIGWINCH signal to the process running under it, which typically causes that process to re-query the tty settings.
Click the maximize button twice. If you're already maximized, that will restore it to a normal window and then re-maximize it; if it's not already maximized, it will do the opposite. In either case, it should cause screen to recompute the window size.
I encountered the same problem today. Thank everyone for the heads-up. The final solution I found out is that to set the mintty term type to: vt220. There must be something not right about the "xterm". After that, everything is good.
I'm answering my own question here because, while #Keith Thompson's answer does resolve the symptom of the problem, it didn't keep the symptom from occurring. He did set me on the right path, which was to install the xterm package in cygwin-64. That appears to have resolved the issue.
I downgraded screen version to Screen version 4.02.01 (GNU) 28-Apr-14 and it worked.