When I use Emacs 25.3 in Cygwin and XOrg on win10, the window moves around unexpectedly. If I snap the window to the left side of the screen and then open the minibuffer, the window slightly shifts, and covers part of the window on the right. This behavior does not happen with MS Windows Emacs. If there a way to fix this?
EDIT: I followed the guide at https://tuhdo.github.io/setup-emacs-windows.html to setup embedded browser support, so I built the linux 25.3.1 version in Cygwin.
Related
When I launch libreoffice, either from the openbox applications menu or from the command line, it doesn't display. I only see the libreoffice picture with the loading bar, then it disappears, and that's it, no window at all is displayed. Only when I use the switch-beetween-window keybinding (Alt + Tab) can I see the thumbnails of libreoffice main and the tips windows along with my other open windows thumbnails in the windows-switch menu, but no windows on my desktop nor even any outline of them...
What's more, when I
ps -e | grep libreoffice
no process is returned.
Every other graphical application works well, only libreoffice has theis issue so far.
*I'm using
Debian 11 (5.10162-1) for x86_64
Kernel : 5.10.0-21-amd64
And a minimal desktop environment made of
Openbox 3.6.1 and Polybar 3.5.5*
I tried to run libreoffice in safe mode to override the .config file
libreoffice --safe-mode
Same result.
I tried to reinstall libreoffice, nothing changed.
Currently on Ubuntu I'm running KDE version 5.18.8, and I've just started coding in Visual Studio Code, but when toggling the console, I just get an old notification on the top right corner of my screen informing me how old it is, not using the shortcut entirely.
*(I toggled the terminal manually in the settings)
Is this a shortcut I have to change in vscode or KDE? Since there isn't anything online I can seem to find for this. It's a bit of an annoyance.
I am using the remote-ssh extension with a (remote) bash as integrated terminal in Visual Studio Code September 2021 release.
When I use the scroll wheel in the integrated terminal, I move through the bash command history (like if I were pressing the up/down arrow keys). Furthermore, there are no scrollbars in the terminal so I am not able to see the text that does not fit in the current viewport.
Is there any way I can use the scroll wheel to actually scroll the content of the integrated terminal window? If I remember correctly, with previous versions of the program I was able to do exactly what I am asking.
The support page https://code.visualstudio.com/docs/editor/integrated-terminal does not say anything about this.
I have another question: is there a place with a comprehensive list of settings for the integrated terminal?
Details:
Version: 1.61.0 (user setup)
Commit: ee8c7def80afc00dd6e593ef12f37756d8f504ea
Date: 2021-10-07T18:13:09.652Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043
Microsoft remote-ssh: version v0.65.8
The issue being described here is the "alternative screen buffer" which causes the scroll wheel to act as arrow keys, scrolling the shell history rather than the window.
If you execute a command (such as vim) that puts you in the "alternative screen buffer" but doesn't put you back when it exits, you can switch back from the alternative screen buffer with:
$ echo -ne '\x1B[?1049l'
# or, if you don't want to memorize that:
$ tput rmcup
If you really want to disable alternate screen buffer switching, which could cause other apps to behave very differently than you're used to which rely on the alternate screen buffer, you could create a new terminfo entry that removes the smcup and rmcup capabilities, which enables this capability.
For example, if you're using xterm-256color, you can create a xterm-256color-noalt terminfo entry like this:
$ infocmp xterm-256color | sed \
-e 's/^xterm-256color/xterm-256color-noalt/' \
-e 's/[rs]mcup=[^,]*,//' \
>xterm-256color-noalt.ti
$ tic xterm-256color-noalt.ti
Then, set your TERM to xterm-256color-noalt:
$ export TERM=xterm-256color-noalt
But, this is a bit more drastic and, like I said, could cause other apps that depend on alternate screen buffer capability being available in the terminal to misbehave or at least behave in ways you don't expect.
CTRL+A then ESC will allow you to use the wheel to scroll up/down
Press ESC to cancel it and get back to the normal wheel functionality.
This had me so frustrated too. After a little trial-and-error, I felt so stupid when I figured out my problem: I was using the WRONG terminal type.
In the terminal "section" at the bottom of VSCode are the tabs: PROBLEMS, OUTPUT, DEBUG, TERMINAL. In the TERMINAL tab, there's a drop-down on the right for terminal type: "tmux" and "JavaScript Debug Terminal" have the awful behavior described above; choose "bash" instead!! "bash" behaves like a proper Bash Linux terminal.
Hi I'm running Linux Mint 19 and I have just installed vscode using the snapd package manager. I've not used vscode on linux before as my usual editor is emacs. However, on a fresh new install of vscode, the integrated terminal does not work, there is just a non blinking cursor in the top left of the screen, but no prompt and no keyboard strokes are registering. This appears to be a common problem as there are a lot of posts about it if googled, but they are all for Windows versions and none of the solutions that I'm able to try do anything. I've tried to open a new terminal window, but the same thing happens I just get two terminal windows that I now cannot use. I've also tried checking the box that says Code-runner: Run In Terminal, but that does nothing either. What can I do to get this to work please, I looks to me like it is just not connected to either a bash or Zsh(which I normally use). Any help on this would be appreciated.
Instead of starting vscode with its default shell script (usually located on /usr/share/code/bin/code), the integrated terminal only works for me when starting it directly from the compiled binary (typically found on /usr/share/code/code, which is the same as the launcher created by the installer:
/usr/share/code/code --no-sandbox --unity-launch %F
While I searched for a solution in the past I've also noticed that lots of folks solved similar problems just by adding --disable-gpu flag, so might be worth checking out as well.
I can't figure out why this isn't easy to find on Google, but after searching for about 10 minutes, I just decided to give up and post here.
The subject basically says it all. I'm running MinTTY as a cygwin terminal on a Windows XP desktop. All I want to do is have emacs open up in a new window rather than inside my terminal. What would be best is a switch for this, so I could toggle it depending on my current needs. This seems like something that would be useful to a lot of people, and I know I've done it before on Linux boxes, so I imagine there must be a way to do this in cygwin too. Anyone know how?
Just start a new mintty, telling it to invoke emacs:
mintty emacs
There are a couple of scenarios that you might clarify:
Running the cygwin version of emacs within a standard windows environment will call emacs within the current shell
If the Cygwin X-Windows server (i.e., “XWin Server”) has been started and the DISPLAY environment variable has been set in the mintty terminal (e.g., export DISPLAY=":0"), calling emacs will start it in its own window.
running the Windows version of emacs within the cygwin terminal should launch the new frame you are seeking.
If you want a separate emacs 'window', you would be best served by installing the Windows native version of emacs (I use the gnu emacs precompiled binaries), and calling it from the cygwin terminal.