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

[Graham Heath]

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’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.

This is all fresh, but I’m sure it would be possible to work within the
limits of the HTML view, but I’d rather just have gutter.

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. The
idea being, as the user types the linters are off, but as soon as the user
pauses for 300ms, the event is fired. 300ms is totally arbitrary in this
case (IIRC its what Atom Linter does).

Here’s a quick video (someone else made) demoing the Atom Linter.
https://www.youtube.com/watch?v=w3M9OmB91Uo

Thanks,

Graham Heath


On August 24, 2016 at 2:41:16 AM, Allan Odgaard (mailinglist at textmate.org)
wrote:

On 22 Aug 2016, at 19:15, Graham Heath wrote:

> The way Atom appears to be doing this "on change" event is by
> debouncing it
> over 300ms. ESLint-d is a daemon implementation of ESLint. IIRC it is
> a
> rather simple wrapper around ESLint that keeps the linter open in a
> background process.

What does “debouncing it over 300ms” mean?

> If I could get the "on change" event, I’d be happy to setup a node
> script
> that either launches a background process ("TMHinter-d" perhaps) or
> attaches to the existing background process.

As Jacob quoted, a re-run of commands with HTML output is in the cards.
I initially had postponed the idea of “regular commands” because
here we lack a good way to start/stop them, e.g. for HTML output one can
run Show Markdown Preview (or similar) and this just keeps updating
until the window gets closed.

This is less transparent with a command that simply runs automatically
on changes without first being requested by the user, and with no way
for the user to tell the command to stop.

But since I’m reworking all of this command execution stuff these
days, I’ll try to find a model for this.

_______________________________________________
textmate mailing list
textmate at lists.macromates.com
http://lists.macromates.com/listinfo/textmate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20160824/bfbcc7b3/attachment.html>