let hr = (strftime('%H'))
if hr >= 17
set background=dark
elseif hr >= 7
set background=light
elseif hr >= 0
set background=dark
endif
Using a light sensor would be cool, but I actually work from a desktop PC most of the time, so no sensor. I guess the next best thing would be something like f.lux does: query some web service for the sunset time at your current location.
I have this old and slightly buggy vim plugin [1] which uses py-ephem to determine the correct moment to switch themes every day. It's been quite a while since I've used vim and I don't maintain this, but you may want to chech it out. BTW, if there's anybody that wants to take over it, please contact me via a github issue through the repo below.
I really like this idea, it's something I've been wanting to try out for a while now.
I'm curious if using `run-with-timer` causes any performance issues in emacs. If so one option is to watch the value outside of emacs and then change the theme using `emacsclient -d "(load-theme 'my-dark-theme t)"` from the script.
It looks like it could; the timer isn't the problem (they're just entries in a queue), but #'shell-command-to-string call might be. It's a synchronous, blocking call (at least on my Emacs 26, running (shell-command-to-string "sleep 5") hangs the whole Emacs nicely for 5 seconds).
Personally, I'd reimplement it the way you suggest - I'd put the timer loop in C code to save on repeatedly starting a process, and then make it run emacsclient -e "(change-theme-for-lighting %d)", where %d is a sensor value, whenever that value crosses a threshold.
Alternatively, if you want to keep the entire business logic within Emacs Lisp code, there's some way to make it work too. I'd look into documentation of #'make-process[0]. There's an argument :FILTER that would let you set a function that receives stdout from that process. Alternatively, #'start-process-shell-command with NIL for buffer, + #'set-process-filter should achieve the same thing. So the C program would be barfing out the sensor value every second or so, and the process filter would read it.
(You might also want to read through the sources of #'shell-command to see how it uses the above facilities to handle asynchronous shell processes - the ones you invoke with M-x async-shell-command - but I think it'll work out of the box, and the process filter will only be executed as new output arrives.)
--
[0] - in Emacs, type: C-h f make-process. Gotta love the self-documenting features of this editor. Actually, half of my comment is based on what I just read in docs of various Emacs functions. Also, hint: make sure you install Emacs with sources - then you can easily jump from help buffer directly into code implementing the thing you're reading about.
is the background color really the problem? I though screen brightness was a more issue, for example: continue using your light theme but lower down the brightness, most of your websites are going to be white backgrounds, switch between dark and light background frequently strains more the eyes, looking for the link where I read this.
* do not offer granular enough control of the brightness on the low end (the backlight is either kind of dim, or nearly/completely off, with no in-between setting), or they
* do not have enough contrast at low brightness to read easily.
In either case, the display is more readable by having the backlight on bright, and darkening most of the display (by changing the background color).
Of course, this does not apply to all displays, but every display has pretty fine control its total light output by changing the colors it is displaying.
On my Atari I made a program to invert all colors with a button combination so I could switch between applications as needed. There are some programs around that does that in windows now. If you have nVidia drivers they can invert but I don't think that can be done with a button. Windows magnifyer has an inverter built in too.
f.lux nicely takes away only the blue light but this isn't always enough for the bright backgrounds of modern homepages and text editors.
That's why we need OLED displays to save our eyes. With OLED's pixels actually produce their own light and dark pixels are just not glowing pixels, pure dark background still provide maximum contrast on sunny days.
This is really neat, but I'm wondering if you are better off triggering the change by sending SIGUSR1 to the Emacs process [0]. This would remove the need to run the function in a timer every 1s.
Thanks for sharing, this is really cool. I often struggle with my Emacs theme switching between light and dark traveling in and out of my windowless office which is filled with intense unnatural night. I once tried to write some Elisp for determining my theme based on the network I was connected to, didn’t work out. I’ll definitely try using this!
Neat. I've done that on the occasional web site, although matched to time of sunrise/sunset. I imagine reading from a light sensor is more accurate, but it isn't available everywhere yet:
I have something similar, except it's based on sunrise/sunset. It hooks into my Mac's Night Shift timer to also enable dark mode and a darker color scheme in all my text editors when it's getting close to sunset, and undo it when the sun rises.
