My gVim 8.2 (Windows 10) always get stuck during startup, showing the window below.
Looking at Windows Task Manager, it shows ctags.exe consuming ~30% of CPU, and 40MB of RAM.
I have to close it manually (or wait for 10+ minutes!), then the program starts...
How can I make it go straight to the program without showing this?
NOTE: Also, my Vim (not gVim) doesn't even show anything (only a black window with a blinking cursor, no matter if I call it from the terminal or not). Both are 64bit, but the same did happen with the 32bit version.
You have a plugin or autocommand in your Vim config that automatically runs ctags. This isn't default behavior.
Actually Don't Use The Command Line Version Use The gVim App In Your Laptop/PC
Related
Vim & NeoVim both leave patches of simply black text scattered in random locations across the viewport. This is most common when scrolling or jumping between locations. This affect has happened on multiple different colorschemes so I suspect its more a problem with vim or my shell, than with the scheme. Generally when I load a file these patches don't exist, but they appear pretty quickly after starting vim. Reloading my configuration file or changing the scheme definitely makes them appear. Restarting the shell or quitting and restarting vim doesn't have any affect.
I'm running windows build 17763.92 on windows 10 Education & vim/neovim on Ubuntu (version 18.04 Bionic) bash for windows under the WSL.
Could anyone enlighten me as to why this is happening?
Heres my vim version info.
Heres my vimrc File & A Screenshot of The Described Affect.
This is usually caused by a wrong terminal setting in $TERM. The commands that Vim sends to the terminal to clear it then don't properly set the background color, and only text written on top has the correct background.
If you don't find a fix for that, you can work around the problem by clearing the background color of the Normal highlight group:
:hi Normal ctermbg=NONE
This happened to me as well, I would get black highlighting when opening a new line using o or O, and it would also appear when paging down (ctrl D) then scrolling up (k).
I was using vim (.vimrc - colorscheme desert with syntax on) on windows ubuntu subsystem WSL.
I was able to make it go away by updating my Windows 10 version 1909, to Windows 10 version 2004.
My problem was similar to this post: https://vi.stackexchange.com/questions/21437/vim-is-highlights-everything-after-eol-in-yellow-upon-scrolling
and, someone had also mentioned it being related to the terminal type xterm-256color here (their recommendation was to upgrade Windows version, it worked for me): https://superuser.com/questions/1526515/vim-highlighting-newlines-in-a-file-how-to-disable
Vim freezes and I see a key sign as I have circled in the picture below when doing the following things
When opening a new file in terminal vim, especially a cpp file.
When terminal vim is left idle for a few seconds
When I click outside the terminal window and then click back into terminal vim.
Ctrl-c unfreezes vim.
This is 100% reproducible on terminal vim, and not reproducible at all on MacVim. I am on MacOS.
When vim is launched from MacOS terminal app (and not iterm), I get a blinking key, and vim freezes just the same.
Please help me unfreeze vim, I've been digging for a while and not come up with anything.
Maybe one of your plugins/custom config is playing the devil here. Would you try and see if the same problem exists while running vim without any custom configurations, like :
vim --clean
if it works as expected, then you should definitely take a look into your .vimrc and start cleaning it.
If the error persists even after running vim clean, then what i would have done would be to check if the shell configs (like .bashrc,.bash_profile etc) for unwanted settings that directly/indirectly affect the working of vim.
As a last resort to avoid confusion, you should also try to debug whether you have given any custom setting for your terminal emulator. Try reinstalling your terminal emulator or run it clean and see if it helps.
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 would really like to find a way to start gvim without the terminal losing focus.
I found a way to use gvim to display code when debugging in dbx.
Gvim as dbx frontend
This works great but it causes gvim to steal the focus every time it hits a breakpoint or changes line.
I am pretty sure I could adapt a terminal keeping focus to work inside dbx.
I am running solaris on a sparc processor.
How can I start gvim without it taking focus from the terminal that started it?
If you're a KDE user, you can start gvim with the kstart command. The kstart program has extensive options for controlling the behavior of the program you're starting. The --onbottom option might accomplish what you're trying to do.
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.