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.
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 have a bug which is completely over the planet. IntellIJ doesn't display. It's on, yet doesn't display.
It worked well before, last thing I did was re-setting up new dependencies on my code and (nothing to do with that) re-setting SDK for other reasons, both of which shouldn't be linked to display properties.
As you can see it's working, I see the pop up windows:
But doesn't display:
Yet I can see IntelliJ windows with Shift + Tab:
and yes, my screen doesn't duplicate, so it's not hidden in another dimension or something
I tried:
restart computer
uninstall install IntelliJ
uninstall install IntelliJ without previous parameters
try other JetBrains software, like DataGrip, it works and displays well
call a homeopathic doctor
Unsuccessfully. So I knee and await before your judgement of this critical situation.
I have this exact same behavior happen to me when I use IntelliJ at work and then go home and try to use it via Remote Desktop. Its very strange (regardless of which monitor I leave it on at work when I leave).
If I hover over it in the task bar and then hover over the thumbnail for the running app, I can right click and tell it to maximize and it magically comes back into focus. Sometimes I have to tell it to restore and then to maximize before this works.
Occasionally even this doesn't work and I have to close it, re-open, and do the same. It makes no sense, so I understand your frustration.
It works
As John Humphreys - w00te mentionned, click right over the thumbnail (I insist: the thumbnail ! Not the taskbar icon) and then select maximize and voilà.
Bon appétit.
Thanks for your contribution and I hope it will help some people in need here.
I have had this issue when I have moved from a dual monitor setup to a single monitor setup or a different dual monitor set up. The issue here that intellij window seems to save and use the coordinates of the last dual window setup to render the window. It doesn't matter you restart your computer, it will always try and render to that position, even if that position is not visible on the new monitor set up. On windows there is an easy way to fix this issue. Go to your display setting and flip the order of the windows. The intellij window should now be visible. you can drag the window to the your other monitor and re-arrange the windows back to the order you had previously. After that, you can place the intellij window wherever you want.
In my case I noticed there is a 1 pixel thick gray line on my screen, turns out that was the IDEA window and I could resize upon hovering that line. Needless to say it wasn't me shrinking it.
I have this same behavior, It happens to me when I connect a monitor in extended mode and move the intellij window to the monitor, then disconnect without moving it back. No other solution other than to connect to monitor again and bring it back to the original window for me works.
On mac, select the app from the app tray so that the menu for it appears up top. Then on the menu up top, go to Windows->Zoom and it should expand to fill the viewport.
From there you can drag it down to size and reposition.
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'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.
Is there an SSH client that can present a client side GUI interface to the screen* program?
I'm thinking of an SSH program that would hook in with screen's session handling and map client side actions (clicking on a tab, ctrl-tab, scrolling, possibly even allowing several tabs to be seen at the same time) to whatever it takes to make screen at the other end do it's thing.
* The screen program that allow multiple virtual consoles under a single terminal session, for example you can run several apps under a single SSH connection and switch between them as well as other cool things.
An interesting idea, and quite possible (vim7's tabs show as clicky GUI tabs in gnome-terminal), but I don't see the benefit of doing this..
Using the follow ~/.screenrc shows "graphical" tabs:
startup_message off
vbell off
hardstatus alwayslastline
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}]%{=y C}[%d/%m %c]%{W}'
..which look like the following (after renaming the tabs using ctrl+a,a:
x http://img216.imageshack.us/img216/9401/picture4myi.png
You can scroll around in a screen session using "copy mode", by doing ctrl+a,[ and using the cursor keys (press Esc or ctrl+c to exit it)
You can also attach to the same screen session multiple times using the screen -x flag (rather than -r), so you could use any tabbed terminal emulator, and open one tab for each screen-window.
If you really did want to start implementing this - one option would be to look into modifying gnome-terminal, to copy the behaviour with vim's tabs for screen. Or, write your own screen client - you don't need to do anything as fragile sounding as scraping the terminal - there's a FIFO file in (usually) /tmp/uscreens/S-$USER/$PID.sessionname which I think is how screen communicates, and remember screen is open-source!
Interesting idea. I use screen everyday both on my local machine and for SSH sessions. I think your biggest problem is that I suspect most screen users are commandline junkies like me who just won't see the benefit of making a gui for tabs. In fact, I have all my terminals in one gnome-terminal window under different tabs, and having screen's text-based tabs is a nice way not to confuse the two.
I suspect it could be done, but you'd be writing a specialised terminal emulator which analyses screen's output (custom .screenrc) and retrofits the gui.
A lot of work for minimal gain.
ctrl+a shift+'
.. gui front-end to screen? what are you talking about??
also, because my rep is so low, and i cant comment, id like to LOL # geoffc for his comment in the question
I've never seen one, but the following may help you. Add to your .screenrc
To show a row of "tabs" on the bottom
caption always "%{.bW}%-Lw%{.rW}%n %t%{-}%+Lw %=%{..G} %{..Y} %m/%d"
To show the current program as the screen name [assuming you're using bash and your prompt ends with "$ " by default; others shells are the exact same idea]
shelltitle "$ |sh"