Lazy menu construction in Vim - vim

I make a lot of use of the GUI menus in gvim, which I create on-the-fly using the ex command :menu, and its variations. Some of my menus take a long time to construct (for example, needing to glob a large directory).
Is it possible to have a lazy sub-menu which is only constructed when you try to access it?
Alternatively, with the new job_start() functionality, is it possible to display a menu while its sub-menus are still being constructed in the background?
Either of these solutions would be a big improvement in responsiveness.

Related

Is it possible to have tabs inside a Vim buffer

Having multiple tabs in vim I've noticed that when I create a new buffer, this buffer stays inside the tab where I create it. Not being an expert at vim I expected the new buffer to behave like a new chrome window where I could put more tabs in. Is there a way to have a workspace like this in vim where when I switch buffers vim would show me a new set of tabs?
Thanks in advance!
That isn't how buffers work. Buffers are containers that hold and facilitate interaction with text. To use your Chrome analogy, this is like asking: how can I open new windows in my browser tabs? which of course you can't, beacuse that is not the interface is designed to work.
As I mentioned in the comments: tabs are containers for windows. Windows display buffers. Buffers hold text.
If a higher level of hierarchical abstraction is needed on top of tabs/windows, the best bet1 is probably to just open a new terminal window and start a separate instance of vim. That is even what is suggested here. I personally never use tabs, it's too clunky and I find it easier to flip between terminal sessions, which is second nature since I do that all the time anyway. The mechanics of vim tabs don't have that kind of "portability".
1: actually, the best bet is to close some of the unnecessary documents. If you're at the point where tabs and windows just aren't enough, adding more complexity isn't going to make you more efficient.

Creating a floating menu that pops like normal menu but appears at mouse position

Some context
I've recently switched to ubuntu budgie (from unity), and I am really tired of the Plank/panel menu combo. I cannot find a setting that suits me, because depending on my screen setup, there's always something in the wrong place.
I am literally unable to show the menu on certain edges if I activate auto-hide, and if I don't activate it, it's not nice at all, to the point that I have removed the plank thing altogether. (Am I having strange bugs on this OS, or is it really messy?)
My idea
With great frustrations come new ideas. I thought again about one I had in the past. I would like to have a circle menu that pops around my mouse cursor when I press a given key combination (very much the kind of thing you would find in some games).
The main use case is to get "pined" application shortcuts easily when I need them, but perhaps other things would fit well with them (commands ...).
Questions
So my questions are:
Does such a thing already exist?
If it doesn't, is it difficult to realize? (How much time, complexity, ...)
What tools/libraries are needed for such a project? I know I'll find plenty of explanations on the gnome developer website but I could really use some more help.
Since you mention a buggy behaviour on Plank, depending on the screen configuration, I suspect you are suffering from this bug. In short: Plank's returned values for the space it needs are not always correct in multi monitor setup.
A neat option to replace at least part of the functionality is Ulauncher, by default called from a shortcut, but you could trigger it from anything that is capable of running its command.
Since Ulauncher's window simply identifies in the window list, you can easily write a script to move it to the current mouse position.
In case you'd need any help in that, just leave a comment.
Not sure if you are also referring to quick access of the window list, but for that you could use the Window Previews applet, or even the Workspace Overview applet, so life without Plank is possible.

Vim popup menu, like the omni autocomplete popup

I'm making a Vim Script. I want to make a popup that offers alternatives. It should work the same as the Omni-popup, but not replace the string or go through the omni functions. Like this:
I've haxxed in the functionality I need by using the completefunc and the auto command event CompleteDone, just to get the popup. But it's really ugly and messy, since I'm not using it for auto completion.
Is there a way to use this popup but with full control, not going through the omni-complete functionality? Like populating it with values and receive the value selected?
I know you can just place the alternatives in an other buffer and just grab the input from there. But it disturbs the work flow, I want a popup.
The insert mode popup menu is only meant for completions, as you've correctly found out. There is not other precedence for popup menus as a general selector in Vim, so such functionality is not there and is difficult to emulate. (In GVIM, one can populate a right mouse button popup menu, but this would need to be triggered by a mouse key press.)
The "Vim way" would be to :echo the list of menu items and query (via getchar() or input()), or just use confirm() or inputlist(). Examples built into Vim are the query in :tselect.
Plugins often use a split scratch buffer to build a more elaborate menu; this can even be combined with 'completefunc', as any text entry into the scratch buffer is discarded, anyway.
The FuzzyFinder - buffer/file/command/tag/etc explorer plugin uses this, and even provides an API for custom uses, cp. :help fuf-callbackitem-mode. That's certainly worth a look, though the menu would still be located at the top, not inside the current buffer.
Do either of these do what you want?
:help inputdialog()
:help inputlist()

Vim Autocomplete Hints for Go

I use https://github.com/nsf/gocode in conjunction with https://github.com/Shougo/neocomplete.vim for my Go autocompletion.
It works really well, except for one little thing. When I type something like
fmt.pri
I get autocomplete option like so:
fmt.Println(a ...interface{}) (n int, err error)
Since I'm new to Go, this is super helpful, because now I know what arguments the method takes, what are the types, and also what does it return.
Unfortunately, as soon as I write past bracket, the information is gone.
fmt.Println(
So on more complex methods that I'm using for first time, I'm stuck, and have to jump to source definition, or run godoc.
It would be much easier to have that information available somewhere, preferably on the bottom of Vim where the command/status line is.
Does anyone know how such a thing could be achieved?
Preview window breaks my Vim so it's not an option.
I use autocomplpop (well, my fork of it) and it has a feature where it does a small split window with the completion text in it that sticks around. It does this when you set...
let g:acp_completeoptPreview = 1
I'm sure neocomplcache has a similar feature. Glancing through its documentation it discusses a preview window in several places. Search for preview in its docs and see what you can find.
This is ultimately controlled by 'completeopt' containing 'preview' (:h completeopt). The auto-completing packages often set these values as part of their functionality, which is why with autocomplpop you need to use its option to control it instead of just doing 'completeopt+=preview'.

How to modify menus items in WMD editor forks?

I am just getting into the WMD editor varieties out there :) Of all of them I like MarkEdit because of the ability to modify the menu items quite easily, but it doesn't do a couple of things that I really like in a couple of forks, for example, http://github.com/openlibrary/wmd.
Ideally my perfect WMD editor would:
create list items automatically on pressing return when in a list block (not implemented in MarkEdit)
allow the removal of menu items (implemented in MarkEdit)
the cheat of making a newline without the need for two spaces (implemented in MarkEdit)
As point 1. and 2. are both quite important to me, but I imagine 1. is harder to implement, I may have to use the forks such as the openlibrary-wmd rather than my preferred choice of MarkEdit.
How can I modify the menu buttons in a fork like openlibrary-wmd? The configuration function no longer seems to work as described for the original.
I recently used the markitup editor and found the skin implementation pretty useful. Each skin has its own images and styles which you can easily override if you need to. The editor is also jQuery-driven, which is nice if you're used to that syntax. Check it out

Resources