icomplete and minibufexplorer

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

icomplete and minibufexplorer

Aaron Griffin
OK, here's my issue
a) I love minibufexplorer
b) icomplete is a godsend for c/c++ coding.  It adds an intellisense
style capability in a preview window

The problem lies in redrawing and switching windows.  With both the
minibuffer list up and the icomplete window, when the icomplete window
needs to be changed, it is switched to and rewritten, then issues a
"wincmd p" which *should* flip back to the main buffer, but instead
switches to the minibuffer list.

Is there any way to fix this?  I don't like typing "->C-w,j" to get
these completions.  For now I have stopped using minibufexplorer, but
would like to use it again.

Is anyone out there using both?
Reply | Threaded
Open this post in threaded view
|

Re: icomplete and minibufexplorer

Hari Krishna Dara

On Tue, 9 Aug 2005 at 10:01am, Aaron Griffin wrote:

> OK, here's my issue
> a) I love minibufexplorer
> b) icomplete is a godsend for c/c++ coding.  It adds an intellisense
> style capability in a preview window
>
> The problem lies in redrawing and switching windows.  With both the
> minibuffer list up and the icomplete window, when the icomplete window
> needs to be changed, it is switched to and rewritten, then issues a
> "wincmd p" which *should* flip back to the main buffer, but instead
> switches to the minibuffer list.
>
> Is there any way to fix this?  I don't like typing "->C-w,j" to get
> these completions.  For now I have stopped using minibufexplorer, but
> would like to use it again.
>
> Is anyone out there using both?
>
>

I don't use either plugins and I don't know how they internally work,
but I have dealt with a very similar problem before and so I will make
an attempt to explain what might be happening here. The issue I think is
with the minibufexplorer listening to window autocommands and jumping
cursor into its own window to update the contents (to reflect the
current buffer or something similiar). This would cause the
"previous-window" (the window the cursor would jump to when executing
^Wp command) to be always set to minibufexplorer's window causing all
plugins that rely on "previous-window" to misbehave. Here is more clear
picture to understand the problem better:

Working case (no minibufexplorer):
- cursor in user window.
- user activates icomplete plugin.
- icomplete create a new window, cursor enters into this new window.
- user makes a selection.
- icomplete closes new window and uses ^Wp to return to user window.

Non-working case (with minibufexplorer):
- cursor in user window.
- user activates icomplete plugin.
- icomplete create a new window, cursor enters into this new window.
- minibufexplorer gets WinEnter event, so jumpts into its own window to
  update itself.
- minibufexplorer uses ^Wp or similar to return back to icomplete
  window.
- user makes a selection.
- icomplete closes new window and uses ^Wp to return to user window.
- cursor ends up in a wrong window.

In fact, when icomplete closes its window, cursor might end up jumping
back and forth between minibufexplorer and other windows one or two
additional times.

The solution to this problem is for minibufexplorer (or any other plugin
that does similar user transparent stunts) to always preserve the
"previous-window" for all window jumpts it does. I have added a few
utility functions to my genutils.vim plugin, to make this job simpler
and encourage plugin writers to do this. You should look at the
MarkActiveWindow(), RestoreActiveWindow() and CloseWindow(). These
functions when used while temporary disabling event processing (to avoid
recursive processing of events) should solve this problem.

--
HTH,
Hari

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com