Should MatchParen plugin restore current window?
Benjamin Fritz
Justin M. Keyes
On Dec 8, 2015 14:34, "Benjamin Fritz" <fritzo...@gmail.com> wrote:
>
> Currently the MatchParen plugin distributed with Vim, will automatically cycle through all windows with :windo, when you use the :NoMatchParen or :DoMatchParen command.
>
> This causes problems with (for example) the LargeFile plugin from Dr. Chip, since that plugin calls NoMatchParen *prior to* reading the file, and then expects the window to remain unchanged.
>
> Should this command save the current window and jump back to it?
Why shouldn't all :*do commands preserve the original window? The current behavior is the opposite of what 99% of users would expect and want.
--
Justin M. Keyes
Charles E Campbell
and jumping back to it (and it also saves and restores the alternate
window, too). I think NoMatchParen probably should save and restore the
current and alternate windows, myself.
Regards,
Chip Campbell
Ben Fritz
> I glanced at LargeFile (v7c) -- its already saving the current window
> and jumping back to it
Well thanks for pointing that out...I had been using the version from vim.org which is a couple years old. Hopefully that solves my immediate problem, but I still think MatchParen should probably save/restore windows, unless we break backwards compatibility and fix it in :windo itself.
I'm not sure I'd want :windo changed, since the current behaviour makes sense for :argdo and :bufdo. I agree I don't like it for :windo and :tabdo but it's easy enough to work around, and at least it's consistent.
Justin M. Keyes
> On Tuesday, December 8, 2015 at 2:26:06 PM UTC-6, DrChip wrote:
>> I glanced at LargeFile (v7c) -- its already saving the current window
>> and jumping back to it
>
> Well thanks for pointing that out...I had been using the version from vim.org which is a couple years old. Hopefully that solves my immediate problem, but I still think MatchParen should probably save/restore windows, unless we break backwards compatibility and fix it in :windo itself.
>
> I'm not sure I'd want :windo changed, since the current behaviour makes sense for :argdo and :bufdo.
> I agree I don't like it for :windo and :tabdo but it's easy enough to work around, and at least it's consistent.
command-line, it requires managing some global state (g: variable(s))
before and after the :windo and :tabdo, not to mention :windo and
:tabdo must now be coddled in a `exe ':tabdo ...'` which now requires
the user to worry about escaping single-quotes.
Why should a user have to fiddle with these workarounds just to
iterate through a list?
Justin M. Keyes
Ben Fritz
> On Tue, Dec 8, 2015 at 4:15 PM, Ben Fritz <fritzo...@gmail.com> wrote:
> > On Tuesday, December 8, 2015 at 2:26:06 PM UTC-6, DrChip wrote:
> >> I glanced at LargeFile (v7c) -- its already saving the current window
> >> and jumping back to it
> >
> > Well thanks for pointing that out...I had been using the version from vim.org which is a couple years old. Hopefully that solves my immediate problem, but I still think MatchParen should probably save/restore windows, unless we break backwards compatibility and fix it in :windo itself.
> >
> > I'm not sure I'd want :windo changed, since the current behaviour makes sense for :argdo and :bufdo.
>
> Why does it make sense for :argdo and :bufdo?
>
Well, especially :argdo, I'm conceptually saying "I have a list of files, I want you to visit each of them and do something" which to me makes sense to start at the first file and stop at the last file. Often I'll open a new tab, set the argument list, and run :argdo if I want to repeat an action on a bunch of files, and I'm just going to close the tab when I know the command is done anyway.
Personally, I mostly organize my files by windows and tabs rather than buffers, so when I do :bufdo, it's usually the same situation.
The newly added :cdo and :ldo also, should start at the first item and end at the last.
If any of these returned to the initial position, I might wonder whether anything happened.
> > I agree I don't like it for :windo and :tabdo but it's easy enough to work around, and at least it's consistent.
>
> What is the easy workaround? If user wants to iterate these objects at
> command-line, it requires managing some global state (g: variable(s))
> before and after the :windo and :tabdo, not to mention :windo and
> :tabdo must now be coddled in a `exe ':tabdo ...'` which now requires
> the user to worry about escaping single-quotes.
>
> Why should a user have to fiddle with these workarounds just to
> iterate through a list?
>
Well, mostly I meant, it's easy enough to work around in a script.
But for most interactive use, all you need to do as a workaround is: check the current window number (I have that displayed in my statusline), run the :windo command, then do <C-W>3w or whatever to get to the correct window.
Similar for :tabdo (using [count]gt with tab page number), :bufdo (using :b command with buffer number), or :argdo (using :argu [count] command with "x of y" count from the title).