Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Day/Night theme functionality should be extracted. #3

Open
milkypostman opened this issue Oct 24, 2013 · 6 comments
Open

Day/Night theme functionality should be extracted. #3

milkypostman opened this issue Oct 24, 2013 · 6 comments
Labels

Comments

@milkypostman
Copy link

When you install the moe-theme from MELPA, for some reason the light theme gets loaded. I feel that a theme should not do this.

I like your idea for a day and nigh theme, but would you at all consider making that functionality its own package that is not integrated wit the theme? That is you could easily make a minor-mode that simply has two variables—possibly daytime-theme and nighttime-theme—and sets the themes accordingly?

Then when this minor mode s activated, the theme choice is ignored.

I mean, the bigger issue is that I should be able to install just the moe-themes (light and dark) without having to worry about the day and night code.

@kuanyui
Copy link
Owner

kuanyui commented Oct 25, 2013

Thanks for your reporting:

When you install the moe-theme from MELPA, for some reason the light theme gets loaded. I feel that a theme should not do this.

That's not my mind... I don't know why moe-light gets applied when installing from package.el...
I just tried installing solarized-theme from MELPA, it also loaded its solarized-light, so I don't sure what do you mean...

I like your idea for a day and nigh theme, but would you at all consider making that functionality its own package that is not integrated wit the theme? That is you could easily make a minor-mode that simply has two variables—possibly daytime-theme and nighttime-theme—and sets the themes accordingly?

That's right. I've ever considered about making switching function independent from moe-theme, but soon I found a very ridiculous thing: Someone other has written an independent package (e.g. theme-changer.el, also available in MELPA) to switch light and dark themes according day/night time...So...I gave up because I thought MELPA needs not a functionally duplicated package. And the switcher kept being an additional function along with moe-theme.

Then when this minor mode s activated, the theme choice is ignored.

That's a good idea~:heart: but I need some free time to see how to write a minor mode for Emacs. [TODO]

I mean, the bigger issue is that I should be able to install just the moe-themes (light and dark) without having to worry about the day and night code.

If user isn't interesting in moe-theme-switcher, just ignore it (no matter whether location information has been set or not, as long as don't require moe-theme-switcher.) I think this may be enough, how do you think?

@milkypostman
Copy link
Author

Ah, see I haven't used solarized-theme recently but it also should not load itself when installing.

Try some other theme packages and see how they behave. Most will not change the theme, but will then show up when you run customize-themes.

@milkypostman
Copy link
Author

So I think there are actually two problems.

  1. In each theme file you set the background color outside of the deftheme
    macro.
  2. When one loads moe-theme-switcher there is a call to
    moe-theme-autoswitch.

When I get a chance I'll try to whip something up that could be a minor
mode instead of a file that always calls a function. For now we could just
remove the moe-theme-switcher from the package that melpa builds or we can
leave it until someone complains.

Thanks for taking a shoot at a fix!
On Nov 4, 2013 10:27 AM, "kuanyui" [email protected] wrote:

60261e760261e7


Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-27709568
.

@kuanyui
Copy link
Owner

kuanyui commented Nov 5, 2013

In fact, I'm just testing if the commit can fix the problem, so waiting for MELPA build it and tried to install it via package.el.

So I think there are actually two problems.

  1. In each theme file you set the background color outside of the deftheme macro.

Sorry, I still haven't understand the concept of Lisp's macro (errrrr...) so I don't know how should I fix this.
I only know if (set-background-color ......) not exist, the background and foreground will goes wrong under a GUI version's Emacs.

  1. When one loads moe-theme-switcher there is a call to moe-theme-autoswitch.
    When I get a chance I'll try to whip something up that could be a minor mode instead of a file that always calls a function.

That's TOO thanks you! 🙏 I think I definitely need spending times to learn how to write a minor/major mode for Emacs...

For now we could just remove the moe-theme-switcher from the package that melpa builds or we can leave it until someone complains.

Ja....Leave it until someone complains XD

Thanks for taking a shoot at a fix!

No no no, I really need to apologize that I left this issue for so many days... And thanks you spending times on report issues. 🙏

@ssbb
Copy link
Contributor

ssbb commented Mar 1, 2015

I think that is non-theme related feature. And we already have module for this functionality - https://github.com/hadronzoo/theme-changer

@xuchunyang
Copy link
Contributor

I still have this issue, third-part packages should not change Emacs behavior during compiling (or even loading with require) period. If moe-theme-switcher.el introduces this issue, I think it is ok to remove it from moe-theme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants