On 24 Aug 2016, at 18:26, Graham Heath wrote:
Current test build has a preliminary implementation of this feature.
Thats great news. You mention that the commands could update the HTML view, would they also have access to the gutter (and/or tooltips)?
You can access gutter via `$TM_MATE` and tool tips can be shown by using `$DIALOG`.
You’ve got a good point that the process should be killed when a user no longer wants it, for my use though I can’t imagine wanting to turn the linter service off while TextMate was still open. If there was a "application-will-close" event, bundles could be responsible for cleaning up after themselves.
Here is the preliminary documentation (I will likely change the keys to match the semantic classes and also make it a mask rather than either/or):
- - -
New `autoRefresh` key that can be set in `tmCommand`, value can be either:
- `documentDidChange`: Re-run the command after document has changed. - `documentDidSave`: Re-run the command after a file in the project has been saved (after delay to coalesce multiple documents being saved).
If a document has `autoRefresh` set to `onDocumentChange` it will stop running if the document is closed. If there is a HTML output window, this window will then also close.
If a command has HTML output, closing the HTML output will stop running the command.
If the user runs a command with `autoRefresh` enabled for a second time, and there is an open HTML output window associated with the command, then it brings the window to front, otherwise it will stop the first instance.
For successive command executions the `TM_REFREH` environment variable is present and set to `YES`.
Planned: If the command’s title matches: `(\w+) / (\w+) (.+)` then it will show as `$1 $3` by default and `$2 $3` when running. This means the command can be named “Show / Hide Preview” and will appear as “Show Preview” unless the preview is already showing, in which case it becomes “Hide Preview”.
Debouncing an event like this over 300ms would mean that the event doesn’t fire until 300ms have elapsed where the trigger wasn’t re-triggered.
Such complicated terms for “when the user is idle” :)