Not able to apply ANSI scheme to the effect of the screenshot

[asfaltboy]

After installing the plugin, I attempted the same as in the animated screenshot; namely I add a few ansi color codes into a text file and toggle from "plain text" syntax to ANSI.

Although the plugin seems to have been loaded and no errors appear in console, no change seems to happen.

I'm new to ST syntax language/theme files; is there any way to debug what the issue is? Here is some sample content:

[0;36mtest_something[0;34m()[0m
[0;32m    514 [0;31m[0;34m[0m[0m
[0m[0;32m--> 515 [0;31m        [0mself[0m[0;34m.[0m[0massertEquals[0m[0;34m([0m[0mr[0m[0;34m.[0m[0mstatus_code[0m[0;34m,[0m [0;36m400[0m[0;34m)[0m[0;34m[0m[0m
[0m[0;32m    516 [0;31m[0;34m[0m[0m
[0m

Update1: The generated ansi.tmTheme file, just in case you need to have a look at it.

Update2: If I run view.run_command("ansi") in console when the ANSI file view is focused it works nice

[asfaltboy]

Oh right, after restart the event listener works properly and syntax triggers command.

[JannesMeyer]

I have the same problem and for me a restart doesn't resolve the problem. Changing the syntax to ANSI does nothing, but view.run_command("ansi") in the console works.

[anantshri]

Latest ST3 build has the same problem plugin loaded after changing to ANSI nothing happens however if i run view.run_command("ansi") i get the desired output.

[asfaltboy]

Can you guys please check if any errors pop in console upon change of syntax to "ANSI" ? Also, provide us with your environment details please. For me, it still works on latest ST3 (after initial restart) and I'm on OS X Yosemite.

[anantshri]

OSX Yosemite, ST latest Build, I have tested this over multiple builds both by using Package manager as well as direct cloning. And cleaned environment multiple times.

For all instances even when i change syntax to "ANSI" no change but when i run the function it works.

Any specific environment detail you need.

[asfaltboy]

I'll reopen my issue, although I'm obviously not experiencing the same issue as you, please provide as many details as possible, e.g.: console log on syntax change, console log on package installation. And please try to install the package on a clean ST (backup and move your other packages / themse) and see if the problem persists. @aziz please add other details if you require more info.

[azhang]

+1, Yosemite + ST latest build. When I change syntax it doesn't change but view.run_command works.

[asfaltboy]

@azhang Please make sure you restart sublime after package installation.

If the issue persists, please copy the output from the console after doing the syntax change.

If we still aren't able track an error, I'll add a debug branch so we can figure out what happens in the event handler.

[vittorius]

Nothing happens in the console when changing syntax to ANSI. SublimeText 3 beta build 3083, Linux Ubuntu 14.04.3 LTS. Running view.run_command('ansi') works.

[2msd]

Hi have the same problem.

Here two files: ok.txt will be shown correctly. nok.txt is shown correctly only if I run the view.run_command('ansi') in the console.

It seems to have something to do with file length. Very long files are not shown correctly (usually background color is black, not the correct color) even with the console command.

nok.txt ok.txt

[asfaltboy]

@2msd These files are exactly the same other than nok.txt having a bit more content.

Let's try to conclude what all the comments above have in common:

• All report the event handler does not fire at first
• All report that using view.run_command manually works
• Some report that after running the command, the event handler starts working

So a possible fix would be to run the command once on plugin load.

To test this we'd have to take a clean sublime text 3, install SublimeANSI, run view.run_command('ansi') and restart the editor, then check if everything works as intended.

[aziz]

I'm pretty busy right now and don't have time to investigate this. Sorry guys! I'd love a PL or a volunteer as a collaborator.

[carycodes]

@asfaltboy That is pretty much exactly what happened to me when I tried to use this plugin just now.

1. Install plugin.
2. Immediately try to change to ANSI. Nothing happens.
3. Change back and forth between Plain Text and ANSI to be sure. Nothing happens.
4. Restart ST3, repeat steps 2 and 3. Still nothing happens.
5. Google search and find this issue.
6. Try changing between Plain Text and ANSI while watching the console. Zero output.
7. Run the command view.run_command("ansi") from the console. File changes to ANSI format.
8. Try changing back to plain text from the drop-down menu. No dice; nothing happens.
9. Restart ST3 again, and try changing formatting. Finally changing between Plain Text and ANSI works as expected.

[matt1003]

@aziz I have spent a bit of time looking into the source code trying to figure out the cause of this issue. I can confirm on my local setup (Ubuntu 14.04.1, Sublime 3 Build 3103) that changing the syntax via the main menu causes the syntax definition for the current view to be set correctly, however the corresponding methods within ansi.py are not being invoked.

How are the AnsiCommand.run and UndoAnsiCommand.run commands hooked into sublime? (I cannot find such hooks explicitly defined anywhere; or this there some sublime magic that is supposed to automatically pick these up?)

[asfaltboy]

IIRC there's an event listener for syntax change in a view

[matt1003]

@asfaltboy @aziz It appears that the behavior of event listeners "on_load" and "on_load_async" have changed from ST2 to ST3. They are no longer triggered for files that are already open on ST3 startup (see https://github.com/SublimeTextIssues/Core/issues/5). SublimeANSI uses the on_load_async event listener to assign the hook method "syntax_change" (responsible for detecting syntax changes, and executing the correct command in response) to the current file.

This means that files already open on ST3 startup will not respond to the ANSI syntax change (via the menu), as the required hook method has not been assigned to such files. However, files manually opened afterwards should work fine, as the on_load_async event listener will be invoked thus assigning the required hook method.

A quick fix, for anyone having this issue, is to simply close and re-open the file that you are having issues with. Re-opening the file will cause the required hook script to be assigned, allowing the ANSI syntax change (via the menu) to work correctly.

A more permanent solution (as suggested in https://github.com/SublimeTextIssues/Core/issues/5) is to have the SublimeANSI plugin loop through all open files on ST3 startup, manually invoking the on_load_async event listener for each open file.

Note: As mentioned, executing the ANSI syntax change from the python console [view.run_command("ansi")] works fine; this is because it manually bypasses the hook method.

[asfaltboy]

Woah, that's really a lot of helpful info! Thanks @matt1003 !

However, the initial issue as I recall it, was that the on_load* handler was not triggering the command right after installation, regardless if we close and reopen multiple different files.

I assume you had a similar issue so you arrived here? Did installing the plugin and reopening a file work for you? I honestly hadn't had a chance to get a clean ST3 installation and try it again.

[aziz]

I don't have enough time to maintain this package. if you're interested let me know here and I give you push access.

[matt1003]

@asfaltboy I suspect that these two issues have the same root cause; i will have to do a little testing to confirm it. Actually, i could not get the plugin to work at all when i first installed it; the prescribed method of restarting ST3 didn't work for me. It wasn't until later that i noticed it working intermittently, and finally traced it to whether files had been opened manually or not. But essentially both these issues are due to the event listener not being setup correctly.

@aziz I can put together a fix when i have some spare time; however it would be good if i could have some help testing it.

[matt1003]

A fix for this issue has now been released in ANSIescape version 0.1.3.