Prevent ST from blinking from one to another scheme #14
Conversation
|
Can you explain what the issue is and how this fixes it? |
|
Lint issues can be ignored. I need to update the lint environment. |
|
Yes, you are right, when I disable linter, ThemeScheduler works great. So
my fix seems, is a workaround for ST with lint enabled.
On Sun, Feb 25, 2018 at 12:15 AM Isaac Muse ***@***.***> wrote:
Lint issues can be ignored. I need to update the lint environment.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWS_PkvH6V6sjTIiWBz3vt4g2YW14iOks5tYF_JgaJpZM4SSAV1>
.
--
With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45
Skype: Gabdullin.AT <http://is.gd/GabdullinAT>
LinkedIn: ArtGabdullin <https://www.linkedin.com/in/ArtGabdullin>
|
|
I think you are mistaking what I was saying. When I was referring to linting, I was referring to linting in this pull requests continuous integration tests below. As for conflicting with a linter plugin, I'd have to better understand what that linter plugin is doing. If it is modifying the color scheme when ThemeScheduler swaps themes, then that may be something to take up with the linter. But if there is a specific, fundamental issue with ThemeScheduler, then we may need to fix it. Anyways, more details would be needed for me to accept this as I am not sure exactly what this is attempting to fix. |
|
I still don't feel I understand what the problem is and how this fixes said problem. I need some more information to determine if this is a reasonable pull, or if something else needs to be done. I'm afraid if I can't get anymore information about this, I'll have to close this request. |
|
Well, I think I can explain how you can reproduce the problem.
So we need a clean sublime build 3143 without any plugins installed
Then Install Package Control, and ThemeSchedular via Package control
So content of Data\Packages\User\Preferences.sublime-settings is:
{
"color_scheme": "Packages/Color Scheme - Default/Breakers.tmTheme",
"ignored_packages":
[
"Vintage"
],
"theme": "Adaptive.sublime-theme"
}
And the content of the Data\Packages\User\ThemeScheduler.sublime-settings
is:
{
"enabled": true,
"themes": [
{
"theme": "Packages/Color Scheme - Default/Breakers.tmTheme",
"time": "08:00",
},
{
"theme": "Packages/Color Scheme - Default/Monokai.tmTheme",
"time": "19:00",
}
]
}
And current time is 22:00
So in my case, Windows 10, when I run ST it will load *Breakers *them first
and then after 3 seconds it will load *Monokai*
Yes, it is ok, bc plugin needs time to be loaded and perform theme changes.
And if I close and open ST again it again firstly uses theme form main
settings file *Breakers *and after 3 seconds load *Monokai*
On Sun, Mar 4, 2018 at 7:30 PM Isaac Muse ***@***.***> wrote:
I still don't feel I understand what the problem is and how this fixes
said problem. I need some more information to determine if this is a
reasonable pull, or if something else needs to be done. I'm afraid if I
can't get anymore information about this, I'll have to close this request.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWS_Aq0KpzKnBSOQY1AUoFXdOCgeXxKks5ta_qLgaJpZM4SSAV1>
.
--
With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45
Skype: Gabdullin.AT <http://is.gd/GabdullinAT>
LinkedIn: ArtGabdullin <https://www.linkedin.com/in/ArtGabdullin>
|
|
Okay, so you are just complaining about refresh of the theme on startup because the theme isn't saved to preference file. So on close, you are left with whatever was originally set, and not what is currently set. I'll have to do some testing. I'm not sure if you noticed, but there are two paths, a safe save (which manually reads and saves the user preference file), and then there is the path you are editing that uses the API. We initially use the safe save which should physically write the preference file, but additional theme/scheme updates will use the API, but not use the API to save (which you have added). Safe save came about to avoid a weird case where we were using the API too early and forced the user settings to be erased when we saved. To avoid that, we read the physical settings file sidestepping the API I need to make sure using a save here never causes the issue to return. So let me investigate. |
|
ok, thank you!
On Mon, Mar 5, 2018 at 1:15 AM Isaac Muse ***@***.***> wrote:
Okay, so you are just complaining about refresh of the theme on startup
because the theme isn't saved to preference file. So on close, you are left
with whatever was originally set, and not what is currently set.
I'll have to do some testing. I'm not sure if you noticed, but there are
two paths, a safe save (which manually reads and saves the user preference
file), and then there is the path you are editing that uses the API. We
initially use the safe save which should physically write the preference
file, but additional theme/scheme updates will use the API, but not use the
API to save (which you have added).
Safe save came about to avoid a weird case where we were using the API too
early and forced the user settings to be erased when we saved. To avoid
that, we read the physical settings file sidestepping the API
I need to make sure using a save here never causes the issue to return. So
let me investigate.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADWS_E0FNAKKQNYVZXp-RH9LIVVWCCDlks5tbEtzgaJpZM4SSAV1>
.
--
With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45
Skype: Gabdullin.AT <http://is.gd/GabdullinAT>
LinkedIn: ArtGabdullin <https://www.linkedin.com/in/ArtGabdullin>
|
No description provided.