Le samedi 13 septembre 2014 09:49:22 UTC-4, Jason Pleau a écrit :
> Le samedi 13 septembre 2014 08:23:26 UTC-4, Christian Brabandt a écrit :
>
> > On Fr, 12 Sep 2014, Jason Pleau wrote:
>
> >
>
> >
>
> >
>
> > > Le jeudi 11 septembre 2014 14:23:46 UTC-4, Christian Brabandt a écrit:
>
> >
>
> > > > Interesting. I can reproduce the issue. I can't see how patch
>
> >
>
> > > > 7.4.396 can cause this. However I noticed a couple of things:
>
> >
>
> > > >
>
> >
>
> > > > vim -u <(echo set clipboard=unnamedplus) -N (paste - E353)
>
> >
>
> > > >
>
> >
>
> > > > vim -u <(echo set clipboard=unnamedplus) -N --noplugin (paste - E353)
>
> >
>
> > > >
>
> >
>
> > > > vim -u NONE -N -c 'set clipboard=unnamedplus' (paste works)
>
> >
>
> > > >
>
> >
>
> > > > vim -u <(echo set clipboard=unnamedplus ei=VimEnter) -N (paste works)
>
> >
>
> > > >
>
> >
>
> > > > vim -u <(echo ':au VimEnter * :set clipboard=unnamedplus' ) -N (paste
> > > > - E353)
>
> >
>
> > > >
>
> >
>
> > > > I am not sure how to debug this further. When running a debug built
>
> >
>
> > > > with gdb, it always pastes correctly.
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > I have worked a bit on this tonight, and another bisect revealed 396
>
> >
>
> > > as the root of the issue.
>
> >
>
> > >
>
> >
>
> > > I don't have much knowledge of vim's source code.. however please see
>
> >
>
> > > the attached patch. Removing the start_global_changes() and
>
> >
>
> > > end_global_changes() in src/ex_cmds2.c fixes the issue for me. (note:
>
> >
>
> > > I haven't tested anything else except the issue at hand, with this
>
> >
>
> > > patch)
>
> >
>
> >
>
> >
>
> > Your patch basically just disables, what Patch 7.4.396 did. The purpose
>
> >
>
> > of this patch was to disable accessing the system clipboard only on very
>
> >
>
> > specific occasions, e.g. when using :bufdo, :g, :folddo etc. So that Vim
>
> >
>
> > does seem to hang, by accessing the system clipboard many times in short
>
> >
>
> > terms (which it seem to do on Windows). This has nothing to do with
>
> >
>
> > startup and I don't see, how this can affect startup.
>
> >
>
> >
>
> >
>
> > Plus, this seems to be highly dependent on the system as accessing the
>
> >
>
> > clipboard works, when running under gdb. I am at loss, how that can have
>
> >
>
> > an impact here. Perhaps Bram has an idea.
>
> >
>
> >
>
> >
>
> > Best,
>
> >
>
> > Christian
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Denn das Wort ist wahr, daß ein Extrem regelmässig das
>
> >
>
> > entgegengesetzte Extrem auslöst. Das gilt so beim Wetter, in unseren
>
> >
>
> > Körpern und erst recht bei den Staaten.
>
> >
>
> > -- Sokrates (470-399 v.Chr.)
>
>
>
> I have digged a bit deeper, and it seems that in ex_cmds2.c, ex_listdo() is
> called when I launch vim (the command is: windo call
> s:LocalBrowse(expand("%:p")). So start_global_changes() is effectively
> launched when opening vim.
>
>
>
> ex_listdo is called for :argdo, :windo, :bufdo and :tabdo. Do
> *_global_changes() need to be called for these other than :bufdo?
Hello again.
Thanks to Pauli from https://code.google.com/p/vim/issues/detail?id=257 , the
:windo call is from the netrwPlugin.vim plugin.
So at least we know where the start_global_changes() call at vim startup comes
from. My previous post still stands, do we want start_global_changes() to fire
at :windo ? In the meantime I'll disable the plugin as it fixes the issue for me
--
--
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 the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
