Error rewriting command sublime_linter_remove_panel. Encountered infinite loop

[gerardroche]

In the Sublime Text build 4150 I'm the following error in the console:

plugins loaded
SublimeLinter: log_handler.py:79      Logging installed; log level INFO
Error rewriting command sublime_linter_remove_panel. Encountered infinite loop
SublimeLinter: sublime_linter.py:76   debug mode: on
SublimeLinter: sublime_linter.py:77   version: 4.22.0

SublimeLinter seems to be working fine so far so I don't know what exactly has broken, if anything.

[kaste]

Yeah, I reported that on discord for v4149. It also has a ticket now sublimehq/sublime_text#5978

[gerardroche]

👍 I'll close this here. Thanks.

[rchl]

So the warning is misleading, as I've pointed out in my issue, but it's still potentially an issue in SL's code. The issue being that triggering a (Window) command directly from plugin_loaded doesn't really trigger the command. It never did, even before that warning was added in ST.

So if triggering this command on plugin_loaded is not really required for proper functioning then it should be avoided. Otherwise it should be delayed until next "tick" (for example with set_timeout) or whatever is appropriate.

[kaste]

We call it in plugin_loaded not for when Sublime starts but when SublimeLinter hot-reloads. And in that case, calling it "sync" (as we also reload all linter plugins after that) makes sense and feels easier to follow/understand. (That's a bit iirc as it is also old code.)

[rchl]

We can wait and see how the ST issue gets resolved but as of now, the mentioned command does nothing on ST start. Whether it's an issue for SL or not is another matter but if it's always gonna be triggering warning on start then it won't be ideal.

[rchl]

BTW. I've fixed similar issue in LSP (sublimelsp/LSP#2277) by not relying on executing a command (which in our case looked like a hack to workaround access issues anyway) and instead executing code normally (calling it).

[gerardroche]

Can you extract the code inside the command so that it can be called directly from plugin_loaded without having to call the command?

[kaste]

Sure I can inline. The reason this is in a command is the added decoupling and to let Sublime Text decide if it actually runs the command. That run_command("foo") becomes a no-op when Sublime or a window of it is not ready was the point of it. lol.

[gerardroche]

This is the danger of uses undocumented behaviour. It always bites you on the ass in the end.

[kaste]

Well, everything is undocumented in Sublime land, at least when it comes to these runtime aspects. But I think it is fundamental, that you can write Window(-1).run_command("foo") without throwing. That is: a) a window that was or has become invalid (for example when you're on the "async"/worker thread and b) calling a command that has not registered (yet). But the feature is not gone, it is still a no-op, they just checked in bad code when trying to detect an "infinite loop while rewriting a command". We're not doing this.

I really like the ST runtime aspects, the task scheduler (set_timeout), etc. Maybe ideally we would hop between the worker thread and ui thread more often. E.g.

# we're on the worker
with lock_current_window() as window:
    # in this block window will always be `valid` 
   # and we're essentially blocking the UI
    # so we're on the UI thread essentially 
    ....
# and we're on the worker again...

but this has the problem that lock_current_window() might throw if there is no window anymore. And so current_window().run_command("this_block_from_before") basically solves (that's my way of reasoning about this) the problem how we enter the UI thread and get a locked window without throwing.

Now I'm getting really chatty 😀