[TxMt] Re: "Document.did-change" and access to the current document in a bundle?

[Allan Odgaard]

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” :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20160928/7adacca5/attachment.html>