I have run into this freaky thing in two places now, on a Windows 7 and an XP machine.
I have a laptop with an extra monitor connected. I start up cygwin's x-server, using the start menu shortcut (Cygwin-X/XWin Server). I then start an xterm by right-click the X icon in the icon tray at the bottom right, and selecting Applications/xterm.
I get an xterm. In it I can type text, but depending on which monitor the xterm window resides, all characters that require two keypresses on my swedish keyboard (example: "~" requires me to first press alt+the key marked "^ ¨ ~" and then press space, rendering a single ~ on the screen) result in a space being printed.
If I move the xterm to the other monitor, I am suddenly able to type a ~ in the xterm. Move it back to the previous monitor, and I can't type ~ anymore.
Weird or what? This is the problem I have now, on my XP laptop. On my Windows7 laptop (same basic setup) I had the problem that I could only type stuff like åäö (not indirect/combined characters - I have keys marked å, ä and ö respectively on my keyboard) on one monitor, not the other.
I have messed around with different ways to start up the X Server, I think I am doing it the right way as I describe here.
My cygwin installation is maybe a year old on both machines. I would like to be able to find whatever setting causes this behaviour, so I can handle it should I come across similar problems in the future.
Any ideas?
Edit: some stuff that looked like html tags got mangled.
Since this seems to be a problem only with xterm, as a simple workaround I would suggest using some other terminal emulator instead of xterm. On Cygwin, a really nice substitute is mintty (available as a Cygwin package from within Cygwin setup). I stopped using xterm in favor of mintty some time ago because I found it to simply be an all-around more useful terminal emulator.
As a possible side benefit of using mintty, if xterm is the only X application you typically use, then you don't even need to run an X server any more because mintty is not an X application.
Related
I use Conemu and Cygwin at home and at work, and I was trying to get the keyboard and highlighting to behave the same way in both places, so I imported my home Conemu settings file into my work Conemu, and now I've lost my ability to use Apps+PgDn/PgUp to scroll the backbuffer. Instead, when I press the Apps key, the mintty menu pops up.
How do I get that back?
I finally figured out that the problem is mintty.exe. I think they changed it in Windows 10 so the Apps/Menu key makes the context menu pop up, and there doesn't seem to be any way to disable that. I'm using Windows 8 at work and Windows 10 at home, hence the disparity.
If you just set your task to run bash.exe, everything seem to work fine.
Now that I figured it out, I can see why running mintty.exe in ConEmu doesn't make much sense, since they're kind of competing products, both designed to be better alternatives to cmd.exe.
There are only a couple of differences:
bash.exe has no way to specify an icon, but that easily fixed by putting /icon "C:\cygwin\Cygwin-Terminal.ico" (or whatever your cygwin icon path is) in ConEmu's task parameters.
The color scheme is also different, but appending -new_console:P:"<Standard VGA>" to the task command makes it the same as mintty.exe's (I want ConEmu to run Far Manager with the <Solarized> color scheme).
When working in GUI we do alt-tab (or cmd-tab in mac) to switch between multiple programs, for example I am writing a text file in a text editor and then I do alt-tab to switch to already running browser to google up something then I alt-tab again to come back to keep editing.
How do you perform such "switch between" programs in command line interface - for example working with a ssh command line shell?
EDIT: I forgot to mention it, I am using ssh to connect to my university's server, and they don't have screen & tmux installed, and my account have no right to install any new apps... Is there any built-in functionality to perform this task, or any work around? For exmaple can I "minimize" running proggram and come back to regular shell interface, do some work, then display the "minimized" process again?
Another workaround: use the shell's job control, eg if you're editing a file, CTRL-z pauses the editor and brings you back to the shell, where you can compile, see manpages, browse the web or whatever -- and of course you can background the browser or anything else.
Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.
As a crude workaround, run multiple terminal windows on your computer, and alt-tab between them.
Incidentally, at the Linux console, you can switch virtual terminals with ctrl+alt+F for at least F1 through F6, commonly F8 or more (depends on how the distro sets them up). Not your case, I know, but in case future visitors should benefit.
If you are comfortable in Emacs, it allows you to run multiple independent ansi-term buffers.
You can also use "GNU screen" to emulate multiple terminals in one terminal.
I am aware that the mousefocus option is only supposed to work in gVim. But I was wondering, if it's possible to have the console Vim switch to different windows in response to mouse clicks, would it be not possible to easily add following mouse movement to it, too?
I'm an xmonad user, I love the focus following the pointer feature, I do a lot of pdf viewing and browsing while writing in Vim, and I'd be so much happier if I didn't have to keep mentally switching back and forth between two different types of focus changing.
If that's completely not possible, I guess opening new Vim windows (as with :split) in new instances of the terminal is no easier to do?
It would not be at all simple to add this. Using the mouse within the terminal works by vim sending control codes to the terminal requesting that mouse actions be sent as part of the input stream. Terminals only report clicks not changes in the pointer position, so vim has no way of knowing where the mouse is.
With major changes it would likely be possible for a vim with X support to get pointer activity directly from the X server, but that would likely be reported by pixel rather than by character so further work would need to be done before it could determine which vim window is currently under the pointer.
set mouse=a
should do the trick but it will probably depend on your terminal emulator. See :help 'mouse'.
This works for Windows 7/Cygwin 32bit mintty/vim 7.3: (I DO NOT use gvim!)
Having installed this: http://ehiti.de/katmouse/, I can scroll the window under my cursor without having to have clicked to select a window, click-selecting of single vim-windows works, too. It does not pull the vim window to the foreground, if another window overlaps it, if that is what you desire. Still it can be scrolled without click-selecting it first.
So:
Check if there exists a software paket for your distribution, that implements your desired mouse behavior on the OS level. When this works for my self-compiled vim in cygwin, it might very well work with console vim on linux, too.
This post here serves as evidence, that it is possible at all, that is the reason this was not made a comment. When I am on linux again I will investigate this further and update this post, but that might take a while.
On set mouse=a: The vim help states you a need a terminal capable of handling mouse inputs, further information can be found here. :help ttymouse might also be helpful, i.e. if you have a xterm-compliant console, but :help term is set to something else.
UPDATE: (Freshly installed Fedora 19 with packages, no self-compiled stuff.)
Fedora 19 + se mouse=a = scrolling in single console vim window with several buffers opened next to each other independently works, too. Window manager used is LXDE.
Something extremely weird is happening when I open files in vim, and I can't remember doing anything that would have caused it.
Weird behaviors include:
no text being visible until I highlight it in visual mode, at which point it is visible from thereon. ":redraw!" does not make anything visible.
line 1 missing
occasionally the cursor appears one line below where it is editing
statuses become permanent and scroll up from the bottom, rather than just redrawing at the bottom
the vim text not extending to the bottom of the vertically maximized window
I lack the reputation to post screenshots but I'll happily provide any other information that could help in a diagnosis.
ETA: Ah! My .vimrc specified a column/row size. I've removed that line, and so far things are behaving well. Thank you!
vim is terminal based, and errors like this happen when the terminal you are using does not match the terminal vim thinks you are using. Most people use vim with terminal emulators. This kind of thing can happen when you resize the emulator window and vim does not find out about it, or more rarely, when the terminal-identifying-string specified in the environment does not match the terminal emulator you are running.
Without more details about the platform on which you are running vim, it is hard to be more specific-- but as a tip: don't resize the emulator window after it is created but before running vim.
Terminal emulators are supposed to communicate size changes back to the program running within them, but this is not 100% foolproof, especially when you are logged in to a remote machine within the emulator.
If you're doing this from a UNIX (Linux et al), try running :!resize to force your terminal to re-adjust its size parameters. At the very least it'll tell you what the system thinks your window is sized to, which may not match its actual size.
I had a similar problem when using vim with bash. When I switched from bash to zsh, it gave redraw errors where, while I typed, the cursor or screen would appear to go down one row for every 10 characters I typed. Scrolling with arrow keys also caused major display problems along the same lines, but worse.
I had this line in my previous .vimrc, I believe it was to set the color for vim
set t_256
I changed it to set term=xterm=256color and the problem went away.
Business as usual: I've logged into my Linux machine from my MacBook Pro using NX, opened a terminal, and ... key bindings with M- (Meta-) do not work. (Talking about bash, of course.) Wait for it. I'm using a PC keyboard hooked up to my Mac (I cannot work on a cramped laptop keyboard). So I decided to investigate: used xev to capture events. When I press left 'Alt' on the PC keyboard, 'xev' reports that 'Meta_L' got depressed. Problem is, it seems that it gets ignored for some reason (no idea why).
It is really annoying, because the same is true for Eclipse. Practically all key bindings with Alt- in them are gone.
My hunch would be to use xmodmap to force the left Alt key to actually emit 'Alt_L', but I wanted to hear a second opinion.
It turns out, the problem was that, according to 'xmodmap -pm', Meta_L and Meta_R were not in Mod1 special modifier category. When I moved them there, everything started to work. (Turns out, some programs assume, incorrectly, that 'Mod1' is Meta/Alt, and ignore keysyms like Meta_L.)