Bug: bad interaction between ui and preview window for omnifunc with extra info
Carlos Pita
1) The window title flickers (it changes too fast so the change is perceived as a flickering artifact).
2) The window name at the taskbar also flickers.
3) Plugins like vim-airline, which are able to show a buffer list highlighting the current buffer, will madly switch the highlight back and forth.
I think an implementation which doesn't switch focus is in order.
Bram Moolenaar
I haven't looked at the code yet, but often it's unavoidable to switch
to the buffer to be changed, which also requires switching windows,
which then requires triggering autocommands to have editing work as
expected... Perhaps it could be done with one switch and back, instead
of switching multiple times.
--
There are three kinds of people: Those who can count & those who can't.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
h_east
2014/7/4(Fri) 19:05:30 UTC+9 Bram Moolenaar:
> Hirohito Higashi wrote:
>
>
>
> > Hi Carlos,
>
> >
>
> > 2014/7/3(Thu) 5:04:10 UTC+9 Carlos Pita:
>
> > > When the omnifunc provides extra info to be shown in the preview window (in case preview is included in completeopt) there is a permanent focus switching back and forth between the current window and the preview window, which produces several annoying and very noticeable visual artifacts:
>
> > >
>
> > > 1) The window title flickers (it changes too fast so the change is perceived as a flickering artifact).
>
> > >
>
> > > 2) The window name at the taskbar also flickers.
>
> > >
>
> > > 3) Plugins like vim-airline, which are able to show a buffer list highlighting the current buffer, will madly switch the highlight back and forth.
>
> > >
>
> > > I think an implementation which doesn't switch focus is in order.
>
> >
>
> > Attached patch fixed 1) and 2).
>
> >
>
> > Bram, what do you think?
>
>
>
> It's a nice simple solution, even though it won't fix everything.
>
> I haven't looked at the code yet, but often it's unavoidable to switch
>
> to the buffer to be changed, which also requires switching windows,
>
> which then requires triggering autocommands to have editing work as
>
> expected... Perhaps it could be done with one switch and back, instead
>
> of switching multiple times.
I think so, my patch is really good solution. If we don't think about autocommands. :-(
autocommands is too powerful.
Carlos Pita
You can selectively supress autocommands at vimscript level with noautocmd and eventignore. Can you do that at the C level? Do you think it's undesirable to do so? I'm not able to think of a listener interested in this particular buffer switch as it's more of a subproduct of a particular implementation than of an intentional switch.
Cheers
--
Carlos
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/z-ABEOyJMFc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ben Fritz
> You can selectively supress autocommands at vimscript level with noautocmd and eventignore. Can you do that at the C level? Do you think it's undesirable to do so? I'm not able to think of a listener interested in this particular buffer switch as it's more of a subproduct of a particular implementation than of an intentional switch.
>
I have autocmds to set certain options on the preview window; for example, "nowrap".
Carlos Pita
>>
>
> I have autocmds to set certain options on the preview window; for example, "nowrap".
to the preview window creation event but I see no point reacting to a
permanent flow of focus in/out events triggered by the autocomplete
mechanism.
Carlos Pita
particular implementation of the autocomplete mechanism<, not by the
user or other plugins or parts of vim where they could arguably be of
interest.
Carlos Pita
h_east
2014/7/12(Sat) 13:18:29 UTC+9 Carlos Pita:
> What do you think about supressing events in the specific way I described above? Is it possible without a lot of work? Could it be problematic for some reasonable use case?
I think your idea is last resort.
Because it would be an incomplete work the autocmd mechanism.
I think that there is a good solution to the other.
I do not know just yet...
Let's read a src/edit.c
Bram Moolenaar
Hirohito Higashi wrote:
> Attach a patch.
> Suppress preview window's status line redrawing when popupmenu opened
> for completion with preview window.
>
> What do you think? worth to consider?
before, and now reveals (part of) it? Does the check for "resized"
catch that?
--
Every time I lose weight, it finds me again!
h_east
2014/7/18(Fri) 0:34:05 UTC+9 Bram Moolenaar:
> Hirohito Higashi wrote:
>
>
>
> > Attach a patch.
>
> > Suppress preview window's status line redrawing when popupmenu opened
>
> > for completion with preview window.
>
> >
>
> > What do you think? worth to consider?
>
>
>
> Looks tricky. What if the popup menu was covering the status line
>
> before, and now reveals (part of) it?
I update a patch. Please check.
> Does the check for "resized" catch that?
It seem to redraw correctly in the existing code.