I trying to add the ability to run jshint on a document which has changes that haven't been saved to the filesystem to the jshint.tmbundle bundle:
https://github.com/fgnass/jshint.tmbundle
I wondered if there was a way to have textmate make a tmp file of the current document so I could pass that file in a command line invocation of jshint.
I was also checking out the Preview command in html.tmbundle and noticed that if I saved a file, added some text and ran Preview without saving the preview showed the new html content.
The code in the "Show Web Preview": command is pretty simple but it's not at all clear to me how it works to accomplish this:
https://github.com/textmate/html.tmbundle/blob/master/Commands/Show%20Web%20...
#!/bin/sh if [[ -e "$TM_FILEPATH" ]]; then echo "<base href="file://$TM_FILEPATH">" fi cat
Does anyone have any suggestions of perhaps another bundle I can look at which does something like this?
FYI: this is the current command that invokes jshint in jshint.tmbundle:
https://github.com/fgnass/jshint.tmbundle/blob/master/Commands/Save%20and%20...
At 10:34 PM -0400 9/6/13, Stephen Bannasch wrote:
I trying to add the ability to run jshint on a document which has changes that haven't been saved to the filesystem to the jshint.tmbundle bundle:
https://github.com/fgnass/jshint.tmbundle
I wondered if there was a way to have textmate make a tmp file of the current document so I could pass that file in a command line invocation of jshint.
I solved this by specifying input from document and and inputFormat as text in the "Hint (without save)" command and then using this in the nodejs code to read the currentDocument:
var currentDocument = fs.readFileSync('/dev/stdin').toString();
FYI: I've got three pull requests in to jshint.tmbundle.
- Include jshint npm production dependencies https://github.com/fgnass/jshint.tmbundle/pull/17
- Use custom options if they exist https://github.com/fgnass/jshint.tmbundle/pull/16
- Hint without save https://github.com/fgnass/jshint.tmbundle/pull/18
They are cumulative so if you want them all just grab the branch referenced in the 'Hint without save' pull request.
All together they make working in JavaScript much nicer on both my 10.6 system running an old TextMate2 and my 10.8.3 system running the latest TextMate2.
On 8 Sep 2013, at 1:13, Stephen Bannasch wrote:
[…]
I solved this by specifying input from document and and inputFormat as text in the "Hint (without save)" command and then using this in the nodejs code to read the currentDocument: […]
I had a longer response partially written, as there’s a lot of options related to the overall goal here, but I’ll put that in the manual instead and drop a link here (when finished).
Of course being able to decorate the actual document with the results of syntax checks etc would be a very welcome feature.
Gerd
On Sep 9, 2013, at 5:05 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 8 Sep 2013, at 1:13, Stephen Bannasch wrote:
[…]
I solved this by specifying input from document and and inputFormat as text in the "Hint (without save)" command and then using this in the nodejs code to read the currentDocument: […]
I had a longer response partially written, as there’s a lot of options related to the overall goal here, but I’ll put that in the manual instead and drop a link here (when finished).
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
At 12:05 PM +0200 9/9/13, Allan Odgaard wrote:
On 8 Sep 2013, at 1:13, Stephen Bannasch wrote:
[]
I solved this by specifying input from document and and inputFormat as text in the "Hint (without save)" command and then using this in the nodejs code to read the currentDocument: []
I had a longer response partially written, as there's a lot of options related to the overall goal here, but I'll put that in the manual instead and drop a link here (when finished).
I look forward to it.
I ended up making a number of other changes to jshint.tmbundle ... then Felix Gnass made me a repo collaborator so they are all in the master branch now.
I'm sure there are some things I could do better but it seems to work reasonably well now.
Regarding integration with TextMate -- the bundle code written in JavaScript and running on nodejs is sending html output to the console log and running process.exit(205).
https://github.com/fgnass/jshint.tmbundle/blob/3f709/Support/jshint-tm.js#L1...
One of the features I added was to have the JSHint window with errors close if you fix all the errors.
Along with the ability to use ctrl-shift-L to check the current document (instead of just the saved file done with command-S) I use this iteratively until the JSHint error window goes away and then save.
There might be a better way ... but this is what I did to close the window.
When JSHint is invoked and there are errors it creates a window with the title "JSHint: <name of file>".
When it is invoked and there are no errors it executes this in nodejs:
https://github.com/fgnass/jshint.tmbundle/blob/3f7091/Support/jshint-tm.js#L...
function closeWindowWithTitle(title) { spawn('osascript', ['close-window.applescript', title], { cwd: __dirname }); }
Which runs this very simple applescript:
https://github.com/fgnass/jshint.tmbundle/blob/3f7091b8c1311154af3d1575ca19f...
on run argv set window_name to item 1 of argv try tell application "TextMate" to close window named window_name on error number -1728 end try end run
This is of course not perfect ... but it seems to be good enough.
On 11 Sep 2013, at 1:13, Stephen Bannasch wrote:
[…] When it is invoked and there are no errors it executes this in nodejs: […] This is of course not perfect ... but it seems to be good enough.
In theory you can use ‘window.close()’ to close windows (from JavaScript).
In practice there is a bug in WebKit so that this only works the first time a WebView instance gets closed, meaning that if the view is re-used (which they generally are), it will not react to the close function the second time.
I’m looking into adding a workaround (so WebViews are not re-used when the close function has been used).
At 11:22 PM +0200 9/11/13, Allan Odgaard wrote:
On 11 Sep 2013, at 1:13, Stephen Bannasch wrote:
[] When it is invoked and there are no errors it executes this in nodejs: [] This is of course not perfect ... but it seems to be good enough.
In theory you can use 'window.close()' to close windows (from JavaScript).
In practice there is a bug in WebKit so that this only works the first time a WebView instance gets closed, meaning that if the view is re-used (which they generally are), it will not react to the close function the second time.
I'm looking into adding a workaround (so WebViews are not re-used when the close function has been used).
Most of the time the common use pattern for using the jshint.tmbundle for checking/correcting is that the jshint function is invoked on the current doc ... and may be done repeatedly.
However it also possible now to invoke it on one doc, generate and error window, and invoke on a separate doc and generate a second error window. If you then switch back to the first document and resolve all the errors the first error window will close.
This should work OK with my recent changes as long as you aren't doing this on two documents with the same filename. I could fix this issue by using the full path from the project root in the window name ... so a window-name might look more like this:
"JSHint: src/core/graph.js"
If use window.close() in the future would I be able identify which window I wanted closed by name?
On 13 Sep 2013, at 14:17, Stephen Bannasch wrote:
In theory you can use 'window.close()' to close windows (from JavaScript). In practice there is a bug in WebKit […]
For the records, alpha.9477 has a workaround for (alleged) the bug.
[…] If use window.close() in the future would I be able identify which window I wanted closed by name?
No, it will close the HTML output window (or split) from which it is being called.
It’s unclear to me though how you can target specific windows for different documents when showing the errors in the first place.
On Sep 15, 2013, at 4:57 AM, Allan Odgaard mailinglist@textmate.org wrote:
[..]
It’s unclear to me though how you can target specific windows for different documents when showing the errors in the first place.
That's why I came up with ApLo [1], because I routinely need to compile and run two or more targets simultaneously in my Xcode [2] bundle.
It also supports syntax checking for JavaScript [3], Lua [4], Perl (not released), and does semi-automatic HTML Preview [5].
Gerd
[1]: https://github.com/gknops/ApLo [2]: https://github.com/gknops/xcode4.tmbundle [3]: https://github.com/gknops/JavaScript-ApLo.tmbundle [4]: https://github.com/gknops/Lua-ApLo.tmbundle [5]: https://github.com/gknops/HTML-ApLo.tmbundle
At 11:57 AM +0200 9/15/13, Allan Odgaard wrote:
On 13 Sep 2013, at 14:17, Stephen Bannasch wrote:
In theory you can use 'window.close()' to close windows (from JavaScript). In practice there is a bug in WebKit []
For the records, alpha.9477 has a workaround for (alleged) the bug.
Can you point me to an existing bundle which uses window.close() ... or an example of how to use it?
[] If use window.close() in the future would I be able identify which window I wanted closed by name?
No, it will close the HTML output window (or split) from which it is being called.
It's unclear to me though how you can target specific windows for different documents when showing the errors in the first place.
When I generate the html which is sent to the output window I dynamically generate the value for the <title> element so be "JSHint: <name-of-file>".
https://github.com/fgnass/jshint.tmbundle/blob/3f709/Support/jshint-tm.js#L1...
The use pattern I then support is to follow this by making changes in the current JS doc and running the jshint checker again.
Evidently if a window already exists with the right name process.exit(205) uses that same window to re-display the error output.
These same features work together to allow multiple independent error windows to be opened and also independently closed when the all the errors are resolved for that specific document.
On 16 Sep 2013, at 0:01, Stephen Bannasch wrote:
[…] Can you point me to an existing bundle which uses window.close() ... or an example of how to use it?
A command with HTML output can execute something like:
print '<a href="#" onClick="javascript:window.close(); return true;">close</a>'
That would generate a link to close the window (effectively an alias for ⌘W).
I’m not sure any commands actually use it. An example could be the LaTeX Typeset & View command, it would always output all the typesetting information, but if the PDF was succesfully created, and being set to open in an external viewer, it could then close the output window by outputting a <script> tag or having the controlling JS do it (depending on how the command is implemented).
-
Allan Odgaard -
Gerd Knops -
Stephen Bannasch