Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for User autocmd #14

Open
pgdouyon opened this issue Mar 19, 2015 · 3 comments
Open

Add support for User autocmd #14

pgdouyon opened this issue Mar 19, 2015 · 3 comments

Comments

@pgdouyon
Copy link
Owner

This can allow users to hook into the event that a buffer has no errors,
possibly to generate tags files whenever a file passes syntax/style checks for
example.

@pgdouyon pgdouyon changed the title Add User autocmd to allow users to hook into the event that a buffer has no errors Add support for User autocmd Mar 19, 2015
@noahfrederick
Copy link
Contributor

This could potentially eliminate the need for g:accio_auto_copen. Instead, users could be directed to do something like:

autocmd User AccioPost if empty(getqflist()) | cclose | else | copen | endif

@pgdouyon
Copy link
Owner Author

pgdouyon commented Nov 4, 2015

Yea I've been letting this one bake for a while. It's basically done, but I'm still not satisfied with the granularity of the autocommands. I've been playing with AccioFinish (although I might like Post better), AccioNoErrors, AccioFinish_{compiler}, and AccioNoErrors_{compiler} but it feels like overkill.

Technically, the NoErrors autocommand isn't needed since you could figure out there are no errors by calling accio#statusline() but that feels like a dirty hack. And adding a new function that basically duplicates the functionality of accio#statusline but under a "better" name also doesn't seem like the right solution.

I do like the idea though of using the autocommand to replace g:accio_auto_copen. The current implementation opens the quickfix window anytime an error is reported, not just when Accio finishes running, but now I'm wondering if it's useful at all.

I personally found the quickfix list popping open randomly really annoying, which is why I turned it off by default, but opening the quickfix list automatically might not make much sense in an async plugin. I implemented it because it was useful in syntastic, but that may have been because syntastic was synchronous and you had to wait for the checker to finish running anyway. In that case, having the location list window open up was a convenient indicator that the checker had finished running but Accio doesn't share that limitation.

I can't really imagine any scenario where someone would want the quickfix list to randomly open while they're navigating around their files...

@noahfrederick
Copy link
Contributor

Yeah, it's possible that g:accio_auto_copen is anticipating a use case no one has. I didn't use this feature even in Syntastic, but as you point out, now that asynchronicity is in the picture it seems even less desirable. I think there's value in being able to automatically close the quickfix window, though.

My first impression is that I'd rather have a single point of entry (a single autocommand) and a flexible way to query Accio about its state than to have many points of entry themselves carrying state information. But if the common case is doing something only when there are no errors (as in closing the quickfix window), I might see value in an AccioNoErrors event—though I'd just as well check empty(getqflist()) on a generic AccioFinish event, unless there is some edge case I'm not yet aware of. I see that there is a guard against closing the window if there are jobs in progress as s:cwindow() is currently implemented.

I don't think I'd have much use for compiler-specific events, personally. I guess it would provide an interesting way to chain compilers ("if there are no syntax errors then run my style checker"):

autocmd User AccioNoErrors_mri Accio rubocop

But this is probably not something I would take advantage of myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants