[+textmate@lists.macromates.com] since this seems to be growing into a feature request, rather than a request for more information.
[I hope I’ve recombine-ed these emails in a sane way…]
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.
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.
Thanks,
Graham Heath
On August 20, 2016 at 2:58:31 PM, Michael Sheets (bundles@textmate.org) wrote:
On Aug 18, 2016, at 8:23 PM, Graham Heath graham.p.heath@gmail.com
wrote:
My current issue is that Atom can lint in real time. I figure with the
gutter/marks API the front-end is ready for this. However, in my research the only thing that seems to update without a save is spell checking.
Is there a Semantic Class that I’m just not finding, or could we create
one? I’d then need a way to access the document’s unsaved contents. It seems to me that spell checking is already doing this, and maybe we could hijack some of that functionality?
If there isn’t a Semantic Class (or other hook) and there’s not a way to
access the current unsaved document, could there be? :D
The current callbacks are:
callback.document.did-open callback.application.did-deactivate callback.application.did-activate callback.document.will-save callback.document.did-save
There is no option to monitor a document for changes in real time, doing so would activate for every single keypress which is just too much overhead for general use. To do this properly we need a program running constantly in the background which isn’t really part of how bundles work.
A good example to look at that we use is the SCM Diff Gutter bundle, this updates on save and open.
Is this the appropriate list for this conversation?
Will Allan see this thread if we keep it on this list? I’m sure he’s got
better things to work on, but I’d love to know how he’s thought about these issues (because I know he has).
This isn’t a list, it goes directly to me only. :) If you want to discuss things with the wider community the main TextMate mailing list is the solution. (Or for a subset the IRC chatroom perhaps.)
On August 18, 2016 at 6:23:50 PM, Graham Heath (graham.p.heath@gmail.com) wrote:
Hello again;
I’ve been working on some exciting features (for me any way) for the existing JSHinter bundle. I’ve had some PRs for small things pending for a while, and I guess that the original author is no longer interested in the project. No problem there, my work continues and the plugin will soon be better than ever.
The goal is to be comparable to the (awesome) Atom Linter plugin, and as the new author I intend to rebrand it as TextMate Linter (or something similar).
My current issue is that Atom can lint in real time. I figure with the gutter/marks API the front-end is ready for this. However, in my research the only thing that seems to update without a save is spell checking.
Is there a Semantic Class that I’m just not finding, or could we create one? I’d then need a way to access the document’s unsaved contents. It seems to me that spell checking is already doing this, and maybe we could hijack some of that functionality?
If there isn’t a Semantic Class (or other hook) and there’s not a way to access the current unsaved document, could there be? :D
I don’t know if you’re interested, but my work has been going on here: https://github.com/loadedsith/JavascriptHinter.tmbundle/ specifically off the master branch; https://github.com/loadedsith/JavascriptHinter.tmbundle/tree/scss-es-and-gjs...
2 last questions;
Is this the appropriate list for this conversation?
Will Allan see this thread if we keep it on this list? I’m sure he’s got better things to work on, but I’d love to know how he’s thought about these issues (because I know he has).
Thanks,
Graham Heath
From Allan:
"I actually have a local branch which allow commands to run on “document changed” which is designed for live HTML/Markdown preview, but could also be used for updating the gutter. Though there are some minor issues that need fixing before I can push this to master.” [1]
[1] http://lists.macromates.com/textmate/2016-May/039527.html http://lists.macromates.com/textmate/2016-May/039527.html
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.
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@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@lists.macromates.com http://lists.macromates.com/listinfo/textmate
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” :)
A few “typos” made it into my email.
The values should have been `onDocumentChange` and `onDocumentSave` rather than `documentDidChange` and `documentDidSave`. The latter though is what they’ll likely be changed to.
And the environment variable present for successive runs is `TM_REFRESH`.
Here’s an example which works with the current nightly build: https://github.com/textmate/markdown.tmbundle/blob/live-preview/Commands/Mar...
On 28 Sep 2016, at 16:59, Allan Odgaard wrote:
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” :)
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
This is huge!
Thanks so much for this! I’ll be hopefully carving out a big chunk for this work this weekend!
I’ll be sure to keep you updated.
Thanks again,
Graham Heath
On September 28, 2016 at 11:42:25 AM, Allan Odgaard ( mailinglist@textmate.org) wrote:
A few “typos” made it into my email.
The values should have been onDocumentChange and onDocumentSave rather than documentDidChange and documentDidSave. The latter though is what they’ll likely be changed to.
And the environment variable present for successive runs is TM_REFRESH.
Here’s an example which works with the current nightly build: https://github.com/textmate/markdown.tmbundle/blob/live-preview/Commands/Mar...
On 28 Sep 2016, at 16:59, Allan Odgaard wrote:
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” :)
_______________________________________________ textmate mailing list textmate@lists.macromates.com
http://lists.macromates.com/listinfo/textmate
_______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Quick bug report:
The following seems to consistently crash for me:
1) Preview a markdown doc under version control 2) Make changes 3) Save 4) SCM Revert current file
Thanks, George
On Thu, 29 Sep 2016 at 21:32 Graham Heath graham.p.heath@gmail.com wrote:
This is huge!
Thanks so much for this! I’ll be hopefully carving out a big chunk for this work this weekend!
I’ll be sure to keep you updated.
Thanks again,
Graham Heath
On September 28, 2016 at 11:42:25 AM, Allan Odgaard ( mailinglist@textmate.org) wrote:
A few “typos” made it into my email.
The values should have been onDocumentChange and onDocumentSave rather than documentDidChange and documentDidSave. The latter though is what they’ll likely be changed to.
And the environment variable present for successive runs is TM_REFRESH.
Here’s an example which works with the current nightly build: https://github.com/textmate/markdown.tmbundle/blob/live-preview/Commands/Mar...
On 28 Sep 2016, at 16:59, Allan Odgaard wrote:
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” :)
textmate mailing list textmate@lists.macromates.com
http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 4 Oct 2016, at 13:37, George McGinley Smith wrote:
Quick bug report:
The following seems to consistently crash for me:
- Preview a markdown doc under version control
- Make changes
- Save
- SCM Revert current file
Do you have crash report submission enabled?
Because I only see one crash report that I can associate with the above actions.
If you are able to reproduce this, can you tell me if there is anything note worthy of the caret position? For example, is it at the end of the buffer or on non-ASCII text (is the document using non-ASCII characters)?
I ask because it looks like the crash (for which I have a report) happens when extracting “current word” from the buffer prior to running the “SCM Diff → Update Gutter” command (in response to reverting changes).
If the caret is somehow in a “bad” position, this could cause an issue for the code extracting current word.
Yes, crash reports are enabled, here's the latest: https://api.textmate.org/crashes/345336
Caret position was a good guess. I was testing by adding lines to the end of the file, doesn't seem to happen if I move to the start of the file before reverting.
On Tue, 4 Oct 2016 at 19:02 Allan Odgaard mailinglist@textmate.org wrote:
On 4 Oct 2016, at 13:37, George McGinley Smith wrote:
Quick bug report:
The following seems to consistently crash for me:
- Preview a markdown doc under version control
- Make changes
- Save
- SCM Revert current file
Do you have crash report submission enabled?
Because I only see one crash report that I can associate with the above actions.
If you are able to reproduce this, can you tell me if there is anything note worthy of the caret position? For example, is it at the end of the buffer or on non-ASCII text (is the document using non-ASCII characters)?
I ask because it looks like the crash (for which I have a report) happens when extracting “current word” from the buffer prior to running the “SCM Diff → Update Gutter” command (in response to reverting changes).
If the caret is somehow in a “bad” position, this could cause an issue for the code extracting current word.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 5 Oct 2016, at 14:57, George McGinley Smith wrote:
Yes, crash reports are enabled, here's the latest: https://api.textmate.org/crashes/345336
Caret position was a good guess. I was testing by adding lines to the end of the file, doesn't seem to happen if I move to the start of the file before reverting.
Thanks, this would sort of explain the crash report, except that I just can’t reproduce this, and there should be code to handle this (i.e. fix cap the insertion point when the document is edited externally).
If you open a document under SCM, add a bunch of lines and keep the caret at the last line, then git revert, do you see the caret moved (to the new last line of the document)?
Okay, still happens even if I don't have preview open. But doesn't seem to be all documents. So far I've only been able to trigger it for README.md files and not all of them and not all of the time (except for the original file which it always happens for).
https://api.textmate.org/crashes/345855 https://api.textmate.org/crashes/345856
What I also noticed is that it only happens when I only use the keyboard to revert (including in the confirmation popup box). If I use the mouse I get this:
[image: Screenshot 2016-10-11 09.38.34.png] It reverted the file, but left the additional text still rendered on screen. Typing or switching away and back gets rid of it.
On Mon, 10 Oct 2016 at 18:48 Allan Odgaard mailinglist@textmate.org wrote:
On 5 Oct 2016, at 14:57, George McGinley Smith wrote:
Yes, crash reports are enabled, here's the latest:
Caret position was a good guess. I was testing by adding lines to the
end
of the file, doesn't seem to happen if I move to the start of the file
before reverting.
Thanks, this would sort of explain the crash report, except that I just
can’t reproduce this, and there should be code to handle this (i.e.
fix cap the insertion point when the document is edited externally).
If you open a document under SCM, add a bunch of lines and keep the
caret at the last line, then git revert, do you see the caret moved (to
the new last line of the document)?
textmate mailing list
textmate@lists.macromates.com
On 11 Oct 2016, at 7:56, George McGinley Smith wrote:
Okay, still happens even if I don't have preview open. But doesn't seem to be all documents […]
Thanks for the update, I think I found the issue, can you please test if you can reproduce with v2.0-beta.12.23? currently available via TextMate → Check for Updates while holding option (⌥).
The lack of refresh is a slightly different issue and may still be there, but this should not cause any instability.
Doesn't seem to be there for me…
TextMate 2.0-beta.12.22 is the latest version available—you have version
2.0-beta.12.22.
On Tue, 11 Oct 2016 at 15:21 Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2016, at 7:56, George McGinley Smith wrote:
Okay, still happens even if I don't have preview open. But doesn't seem to be all documents […]
Thanks for the update, I think I found the issue, can you please test if you can reproduce with v2.0-beta.12.23? currently available via TextMate → Check for Updates while holding option (⌥).
The lack of refresh is a slightly different issue and may still be there, but this should not cause any instability.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 11 Oct 2016, at 14:22, George McGinley Smith wrote:
Doesn't seem to be there for me…
TextMate 2.0-beta.12.22 is the latest version available—you have version
2.0-beta.12.22.
Hold down option (⌥) — the menu item title will change from “Updates” to “Test Builds”.
Yes, I am doing that, still getting the same
On Tue, 11 Oct 2016 at 16:24 Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2016, at 14:22, George McGinley Smith wrote:
Doesn't seem to be there for me…
TextMate 2.0-beta.12.22 is the latest version available—you have version
2.0-beta.12.22.
Hold down option (⌥) — the menu item title will change from “Updates” to “Test Builds”.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 11 Oct 2016, at 14:29, George McGinley Smith wrote:
Yes, I am doing that, still getting the same
And you see the menu item’s title change?
Only thing I can think of is a local proxy of sorts that responds with the old version.
Here’s a direct link to archive build: https://api.textmate.org/downloads/TextMate_2.0-beta.12.23.tbz
Yes, menu changes, just doesn't see the new one…
On Tue, 11 Oct 2016 at 16:37 Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2016, at 14:29, George McGinley Smith wrote:
Yes, I am doing that, still getting the same
And you see the menu item’s title change?
Only thing I can think of is a local proxy of sorts that responds with the old version.
Here’s a direct link to archive build: https://api.textmate.org/downloads/TextMate_2.0-beta.12.23.tbz
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Okay, yes, that seems to have fixed it, thanks.
On Tue, 11 Oct 2016 at 16:38 George McGinley Smith george@gsgd.co.uk wrote:
Yes, menu changes, just doesn't see the new one…
On Tue, 11 Oct 2016 at 16:37 Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2016, at 14:29, George McGinley Smith wrote:
Yes, I am doing that, still getting the same
And you see the menu item’s title change?
Only thing I can think of is a local proxy of sorts that responds with the old version.
Here’s a direct link to archive build: https://api.textmate.org/downloads/TextMate_2.0-beta.12.23.tbz
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-
Allan Odgaard -
George McGinley Smith -
Graham Heath -
Jacob Carlborg