Play nicer with vim-qf

[qstrahl]

After years of frustration, I finally looked into why vim-scriptease and vim-qf didn't seem to play together nicely (among other things, vim-qf automatically runs :[cl]window on QuickfixCmdPost). What I discovered is that two things needed to change before they would kiss and make up:

1. :Vedit and pals needed to issue a doautocmd QuickFixCmdPost after calling setloclist
2. The list entries produced by :Vedit and pals needed to have {"valid": 1}

To be quite honest, I have no idea why the entries were not considered valid; I wasn't able to find much :help on the subject. I was only able to get them considered valid by using the full filename as the entry text and then by explicitly setting "valid": 1. The absence of either of these changes seemed to prevent them from being considered valid in my testing.

I always thought it was weird that the filenames had the last few characters chopped off, anyway, so it was a welcome change for me, at least. If there's some sort of black magic at play that I don't fully understand, I'd love to hear about it.

[tpope]

1. :Vedit and pals needed to issue a doautocmd QuickFixCmdPost after calling setloclist

I'll accept the doautocmd, but scriptease.vim needs to run on versions of Vim older than <nomodeline>.

I was only able to get them considered valid by using the full filename as the entry text

This is such nonsense that I almost didn't bother testing it. But I did test it and it's wrong.

I always thought it was weird that the filenames had the last few characters chopped off, anyway, so it was a welcome change for me, at least. If there's some sort of black magic at play that I don't fully understand, I'd love to hear about it.

"Last few characters"? It chops off the relative portion and leaves the directory name as seen in 'runtimepath'.

[qstrahl]

This is such nonsense that I almost didn't bother testing it. But I did test it and it's wrong.

"Last few characters"? It chops off the relative portion and leaves the directory name as seen in 'runtimepath'.

That's... a surprise. Two surprises. Something must be very wrong with my environment. I guess I'll drop the nomodeline from the one commit, drop the other commits for now, and let you know if I can definitively narrow down the other issues to some weird case in scriptease.

[qstrahl]

@tpope There; should be just the doautocmd change now, minus the <nomodeline>

[tpope]

Now that I think about it ... let's keep <nomodeline> but wrap the each doau in a if v:version >= 704. So we get reduced functionality on old Vim versions but it still works. I think that's a better tradeoff than triggering modelines on new versions.

If you're getting weird results with that truncation, one thing to rule out is symlinks in your 'runtimepath'.

[qstrahl]

Ohhh... that would do it, then. There are definitely symlinks all over my runtimepath. Could that be handled with `resolve()`?

…

On Tue, Sep 10, 2019, 18:38 Tim Pope, ***@***.***> wrote: Now that I think about it ... let's keep <nomodeline> but wrap the each doau in a if v:version >= 704. So we get reduced functionality on old Vim versions but it still works. I think that's a better tradeoff than triggering modelines on new versions. If you're getting weird results with that truncation, one thing to rule out is symlinks in your 'runtimepath'. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45?email_source=notifications&email_token=AARBXDLDRACRV5B6ALJLYXDQJAOVDA5CNFSM4IVKG4AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MWRGA#issuecomment-530147480>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARBXDK2ZX5J7VTPI6Y7IBDQJAOVDANCNFSM4IVKG4AA> .

[tpope]

Unclear. Try to pinpoint how exactly it causes it to fail.

[qstrahl]

Will do. Regarding `doau`, if we know which `v:version` to check for `nomodeline` as well, I could instead write a small function that gracefully degrades from `doau <nomodeline>` to `doau` to no-op based on the features available. Couldn't find that info in `:help`, but there's always the git log.

…

On Tue, Sep 10, 2019, 18:59 Quinn Strahl, ***@***.***> wrote: Ohhh... that would do it, then. There are definitely symlinks all over my runtimepath. Could that be handled with `resolve()`? On Tue, Sep 10, 2019, 18:38 Tim Pope, ***@***.***> wrote: > Now that I think about it ... let's keep <nomodeline> but wrap the each > doau in a if v:version >= 704. So we get reduced functionality on old > Vim versions but it still works. I think that's a better tradeoff than > triggering modelines on new versions. > > If you're getting weird results with that truncation, one thing to rule > out is symlinks in your 'runtimepath'. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#45?email_source=notifications&email_token=AARBXDLDRACRV5B6ALJLYXDQJAOVDA5CNFSM4IVKG4AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MWRGA#issuecomment-530147480>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AARBXDK2ZX5J7VTPI6Y7IBDQJAOVDANCNFSM4IVKG4AA> > . >

[tpope]

If you want to do it right, the incantation in Projectionist is the way to go.

I don't understand how vim-qf would know to use :lopen and not :copen since Vedit isn't a standard command name.

[qstrahl]

Current master doesn't, but I'm a contributor and I've got a PR up that checks if the quickfix list was modified between the `Pre` and `Post` autocmds, which avoids the need to know about each custom command in each plugin that might merit support (like all the list-populating fugitive commands, for example). Given that vim-qf aspires to Just Do The Smart Thing in most common cases, its current behaviour will have to change one way or another anyway, because it deals poorly with several fugitive commands.

…

On Tue, Sep 10, 2019, 19:16 Tim Pope, ***@***.***> wrote: If you want to do it right, the incantation in Projectionist <https://github.com/tpope/vim-projectionist/blob/94001f00825c36fab63b9f3ca47a204111e561a2/plugin/projectionist.vim#L107-L126> is the way to go. I don't understand how vim-qf would know to use :lopen and not :copen since Vedit isn't a standard command name. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45?email_source=notifications&email_token=AARBXDJJS55LPCUWHJ2N343QJATE7A5CNFSM4IVKG4AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MYTGQ#issuecomment-530155930>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARBXDN3S37MHMCHDTQGOSTQJATE7ANCNFSM4IVKG4AA> .

[tpope]

Looks like you're doing an equality check, which means if you run the same quickfix command twice in a row, the second time, it will open the location list rather the quickfix list. What a confusing bug!

I don't think there is a robust solution to this other than to look at the command in expand('<amatch>'). Checking for a leading l works for built-ins. I'd rather our autocommand match this somehow rather than provide the unhelpful Vedit.

(Fugitive currently uses Ggrep and Glgrep events. I could see renaming these to look like grep-fugitive and lgrep-fugitive.)