Changing the encoding/line ending from the status bar menu doesn't update the template output

[eugenesvk]

This might be a limitation of the ST's API (see this bug) when losing focus to the status bar menu doesn't update the on_activate API, but maybe not and you know a way out :)

P.S. to be fair, this is a rather minor bug since people who use your plugin will likely replace the default status bar element and won't be able to change the encoding using it ;)

[jfcherng]

But how is this plugin affected?

The built-in line/column keeps stay in status bar when the view loses focus too.

[eugenesvk]

No it doesn't, the native status works fine (and I'm talking about encoding/line ending, not line/column)

[jfcherng]

Good point. Right now, the message only updates when on_activated and on_selection_modified indeed.

[jfcherng]

Most likely fixed in https://github.com/jfcherng-sublime/ST-CustomStatusMessage/commit/5f777f65a55820ff74fdeeb17246ba298f2ac9d9 and release in v0.0.2.

[jfcherng]

The weird part is that if there are two (or more) consecutive line endings changes via the status bar. Only the first change will triggers the view settings listener callback. But still, better than never.

[eugenesvk]

two (or more) consecutive line endings changes via the status bar. Only the first change will triggers

yeah, that's weird, tab size, though, doesn't have this weird bug

By the way, this seems to activate on every single keypress (even without on_selection_modified enabled), is that too much or no big deal (wish they just fixed their APIs so there is no need for these types of hacks)?

[jfcherng]

Well, line/column changes on every keypress , isn't it?

[eugenesvk]

but the encoding/line ending don't change

[jfcherng]

so? since line/column changes, you have to update anyway. I would image encoding/line ending etc are all cached rather than heavily calculated in ST. I don't think you can notice the latency this plugin causes. Further optimizations are most likely meaningless at this moment but just make codes much more complicated.

[eugenesvk]

since line/column changes, you have to update anyway

not really, maybe you're not using the line/column part of the template (either have it off or use the default shortened version), but only using the other indicators that don't update as often

Anyway, was just curious, hopefully it's all cached an all

[jfcherng]

not really, maybe you're not using the line/column part of the template (either have it off or use the default shortened version), but only using the other indicators that don't update as often

Yes, we can let template variables update only when they change.

[jfcherng]

The fix in 0.0.2 doesn't seem to work. I have no idea why it worked yesterday...

[jfcherng]

It seems the fix introduce in 0.0.2 only works for files on filesystem, rather than unsaved buffer. I guess that's because LSP changes the view settings and thus triggers the view settings listenser.

[jfcherng]

Yes, we can let template variables update only when they change.

Done in https://github.com/jfcherng-sublime/ST-CustomStatusMessage/commit/33aa1c88529ec2d79d766eefa4d0cbb9d76e7f3f and release 0.0.3.

[eugenesvk]

I guess that's because LSP changes the view settings and thus triggers the view settings listenser.

BracketHighlighter is also heavy on storing its frequent changes in the settings, thus triggering the settings callback https://github.com/facelessuser/BracketHighlighter/issues/431

[eugenesvk]

Unfortunately, the ST folks closed my bug report with a weird take that losing input focus doesn't matter to the API that tracks losing input focus :( So maybe there is no 100% certain way to track these changes...