I have the ProportionalResize plugin installed, but it throws the following error message (shown below) everytime I resize the whole GUI-WINDOW after performing a window split. I realize this is a Ingo Karkat plugin which makes use of the ingo-library (I use L9 as func library). But even with his lib installed the error message changes from
to
.
There is a comment in this and this file about the stale window dimensions (comment on revision 1.00.003). Can't say I understand what he talks about. Just stumbled upon it.
If you need my vimrc, let me know.
Plugin author here. I concur with the commenters that issues like these are best first addressed directly to the plugin's author (in my case, via the email address found in the documentation and scripts, since I don't use an issue tracker for these small plugins yet), not via Stack Overflow.
Because there is no VimResizedPre event, the plugin periodically (on CursorHold) records the current dimensions to be able to calculate the difference. When there's no current record, you'll get the Stale window dimensions record error. To avoid that, try waiting for 4 seconds before attempting the resize.
Resizing internal window splits (as you've reported) should not trigger that error, however, because the plugin is only triggered when the outer Vim window borders change, not when you adapt the internal window layout.
Related
Is there any way to have something like a status bar in Vim with CoC (or just language server in general) that tells you when current buffer is static analysis-wise invalid, eg. has compilation or linting errors?
I am using Vim w/ CoC in an Angular project, and while CoC shows me errors just fine when I have the problematic line in my current view, I don't see those outside of the current scroll position.
Compare
to
I am just one line higher on the second picture and already have no indication of errors. I can jump preemptively to next issue with coc-diagnostic or just rely on compiler output but that's clearly not ideal.
So is there perhaps plugin to be used for this (preferably one which plays nicely with CoC), or is there any better way (workflow-wise) to quickly find out that current buffer is invalid?
Turns out I was unaware of the concept of configuring statusline in vim. Searching for it yielded nice integration options between lightline (which I am using) among others and Coc https://github.com/neoclide/coc.nvim/wiki/Statusline-integration.
The history tab dynamically loads more of the version history when scrolling down, is there any way of loading the entire version history without having to tediously continue scrolling until you hit the first revision? The reason is that when you try and use the Find command it only considers the items in the list view that are currently loaded.
I agree with Bryan Pendleton's recommendation. Running via command line is quick and you can massage the results however you'd like. The only thing I would add is to check out the current documentation. Googling perforce documentation is unfortunately littered with old results. Bryan's links are 3 and 5 years old.
https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_filelog.html
https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_changes.html
I am using neocomplcache along with neosnippet and honza's vim-snippets. They are great, except that when I press Ctrl-k, I can go to the next parameter, but I have no way to go back to the previous parameter.
So for example, if I inserted 'for' snippet and made a typo on the index variable, but I already pressed Ctrl-k, am I screwed? Must I go through modifications of all the parameters and then come back to do replace operation? Or is there mapping for select mode that I can help me in this situation? Currently Tab and S-Tab do not do anything.
Lastly, are all snippet plugins like this? Or is neocomplcache just missing this feature (out of the box, at least)?
I encourage you to try UltiSnips. It is much more powerful and mature than vim-snippets or neosnippet. For instance, since UltiSnips is based on Python, it is very extensible. Concerning your problem: yes, you can jump back and forth with UltiSnips. Finally, be sure to check out screencasts (listed in the link) to see all the fancy stuff you can do with it.
For example, I use the following configuration:
let g:UltiSnipsSnippetsDir = '~/.vim/snippets/'
let g:UltiSnipsSnippetDirectories = ['UltiSnips', 'snippets']
let g:UltiSnipsExpandTrigger = '<C-CR>'
let g:UltiSnipsJumpForwardTrigger = '<A-d>'
let g:UltiSnipsJumpBackwardTrigger = '<A-a>'
NOTE: ~/.vim/snippets/ is my directory for custom snippets.
As I've already mentioned UltiSnips uses Python extensively, and therefore requires Vim to be built with Python support. If you are on Windows (especially x64), that might be a trouble, the one I've run into quite some time ago. To save yourself precious time and avoid frustration you may consider downloading my Vim for Windows. Both x86 and x64 architectures are provided, and it supports both Python 2 and Python 3 simultaneously. I can assure you that it is stable. To install properly just follow the instructions. These builds are updated frequently.
The original SnipMate and its fork (the plugins for which vim-snippets is actually meant to be) both allow you to go back to the previous placeholder with <S-Tab>. I believe UltiSnips does too.
Neocomplcache doesn't support snippet expansion out of the box anymore. AFAIK, you need another plugin by the same author called neosnippet which is the one responsible for the <C-k> mapping. A quick look at the doc shows no "reverse jump" mapping, function or command. You can probably create a new issue on neosnippet's Github page.
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.
Question: Is anyone out there familiar enough with Komodo Edit to shed some light on this macro? I need to figure out how to do buffer text selection in a macro when it is invoked via the tool panel.
Problem: I have a very simple macro in Komodo Edit javascript that works as expected, but only when invoked via a custom keybinding. If the user tries to invoke it from the standard "tool panel" the selectWordLeft invocation does nothing. My guess is the failure is caused by the edit buffer not having focus, but one would have thought that telling the macro to expressly give focus to the buffer would work.
komodo.view.setFocus();
komodo.doCommand('cmd_selectWordLeft'); /// this NO_WORKY
Background:
Komodo Edit, version 5.0.2, build 2604, platform win32-x86.
Built on Wed Nov 19 18:33:41 2008.
Answer: Did some more searching and came across this response to another question on a KE forum; which seems to fix the problem.
Instead of deleting the question, here's an answer in case anyone else out there has the same or similar problem.
There are currently some issues with komodo.docommand and some commands.
To work around this, change this line:
komodo.doCommand("cmd_selectWordLeft");
to this instead:
komodo.editor.wordLeftExtend();