grunt.el
grunt.el copied to clipboard
gempesaw
Link through to files from stack trace
When grunt tasks error (mainly thinking about jasmine tests etc) and a stack trace is printed out, e.g.
Error: Expected true to be false
at Object.<anonymous> |/path/to/file/testSpec.js:125:18 (†)
It would be nice to be able to click through to testSpec.js:125 from (†).
I've been playing around with this idea on my branch, button-links. It's currently functional but haven't driven it out with tests, also, the links (emacs buttons) are only made when grunt--highlight-process-links is called, which has to be done manually or by navigating using C-c C-n or C-c C-p.
Ahh, yes, very helpful! more and more like a proper compilation buffer after all! :)
Perhaps it's time to stop using (async-shell-command) and do it properly with (start-process) and corresponding ... uhh, not sentinels, but, uh, the other thing ... ah! process-filters. that way any time the grunt process outputs text, we could call grunt--highlight-process-links if we need to.
Thinking out loud, huh, maybe we can just put the buffer in comint-mode or compilation-mode ( i always forget which one the *compilation* buffer uses...) and get that for free ?
a bit unrelated, wanna be a contributor or whatever github calls it - get a commit bit for this repo ? you've been gracious enough to refactor & improve more than half the code :P and uhhh i dunno, maybe it'd be easier not to work with forks and stuff. :)
Yeah! That would be sweet! But I'd still probably open PRs for visibility :P
But yeah, I tried to convert it from an async-shell-command to a process with start-process-shell-command, but it behaved pretty weird with things like always appending the output to buf rather than replacing the contents, and it doesn't automatically provide you with the output buffer like async-shell-command does, so you'd have to do some things to bring up the buffer correctly, nothing too difficult though! :D
I think both sentinels and filters would both work? I may be missing the subtleties between them, but isn't it just the sentinels run on a status update (i.e. exit code) and filters run on text before it's passed through to the buffer? I had a bit of a play last night and got it working with a sentinel, and seeing as the output buffer's read only, I couldn't really interact with it until it had finished anyway :)
What free stuff does compilation/comint-mode give you? o__O
yeah PRs are definitely the way to go :D. branches for days! :) I believe I've granted push permissions - you probably already know, but melpa unstable builds directly off of the master branch, and melpa stable builds off of tags.
yep i just learned about sentinels earlier this week fooling around with trying to get grunt --help to run asynchronously. i think we'd probably want to use filters - or, well, i run my jasmine tests with a file watch on, so the grunt task doesn't actually complete and wouldn't send a status update for a sentinel to catch. so, that was my use case that I was thinking filters would work best for.
i presumed one of those modes would get include g to rerun and automatically buttonify file references, at least. but, i didn't actually check. :P
if it's of assistance, compilation-minor-mode seems pretty helpful, seems like there's an alist compilation-error-regexp-alist that we'd just need to add our own regex to for it to understand the type of error messages that our processes create.
seems to be how karma.el does it: https://github.com/tonini/karma.el/blob/master/karma.el#L172
although, seems like it'll be pretty specific to the error message to do it this way. for example, error messages with source maps probably want to go to the source instead of the transpiled code. hum.
I've pulled master, I can see compilation mode being applied to the buffer but none of the error regexps seem to be being applied.
Have either of you got this working? Is there a regexp I should be adding to compilation-error-regexp-alist?
It works for me with eslint & grunt, using the UNIX formatter of eslint.