| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Back to having three monitors :)
I'm also calling `display-arrange-primary` in `exwm-init-hook`, which calls
`xrandr` to ensure my displays are configured as I expect.
|
|
Today is my first day back in the office at Google (this time at MP2 in
Sunnyvale)! As such, I have a new desk, new monitors, so expect some changes to
my configuration until I stabilize everything.
|
|
I was tired of using `arandr` to manually configure my monitor positions, so I
encoded the settings in Elisp in the `display.el` module.
TL;DR:
- Drop support for `position` kwarg in `display-register` macro
- Support `coords` kwarg in `display-register`.
- `defconst` the `xrandr` arguments and command in `display-register`.
- Define `display-arrangement` macro that consumes the `xrandr` arguments that
`display-register` defines to create an interactive function,
`display-arrange-<NAME>`, which -- when invoked -- runs one xrandr command to
configure a display "arrangement".
|
|
My newly minted macro for defining monitors introduced two bugs:
1. Laptop defined its position in terms of 4k-horizontal and 4k-horizontal
defined its position in terms of laptop, I introduced a circular dependency.
2. The identifier, `laptop-monitor`, which `window-manager.el` depends on, is
now defined as `laptop`.
A friendly reminder to myself to always test new Emacs builds to make sure that
everything can initialize properly. This is something that my CI should be
automating, but ever since I moved flats, I lost my CI and need to restore it.
This is another reminder to drop into a TTY when Emacs fails to initialize, run
`nix-env --rollback`, then attempt to restart X. But this time, debugging this
entirely from a TTY wasn't so disappointing.
|
|
I recently acquired a new monitor, which I'm orienting vertically for logs,
chats, etc. As such I needed to add more functions, KBDs to wrangle the
setup. To DRY up my code, I define a macro, `display-register`, as a DSL for
supporting new monitors. This:
- defines two functions for enabling and disabling the displays
- defines a constant, `display-<name>`
It's basically just a wrapper around `xrandr`, and that's good enough for now.
|
|
This should cover most of the remaining linting errors. After this, I expect
fewer than ten linting errors.
|
|
More of the same type of linting... basically preferring `namespace-` instead of
`namespace/`.
|
|
This was a doozey because I use it everywhere. Is there a better way to globally
rename things? Aye aye aye... computers, man!
|
|
Currently I prefer working with one screen at a time, so I'm preferring to
toggle between external monitor and laptop monitor.
|
|
Today when I opened my laptop, I wasn't sure if it was powered off or on because
the display was blank. Thankfully the volume was muted and the LED indicator was
on, which informed me that the laptop was powered on. This saved me from
unnecessarily rebooting.
What happened was that last night I was working from home and using my external
monitor. Usually I enable my external display and disable my laptop display. But
when I left for work this morning, I unplugged the HDMI cable from my laptop
without disabling the external display or enabling the laptop display.
I noticed a XF86 button on my laptop entitled XF86Display. I figured that this
could be a nice place to bind a key to toggle my laptop display on or off. At
the last minute, I had the idea to just cycle through all possible display
configurations that I use; there are only three anyways. When dealing with more
than two states, I realized I should use a cycle to model the configuration
states. Now I'm thinking that I should be using cycles to model toggles as well
- instead of just using a top-level variable that I `setq` over. I haven't
refactored existing toggles to be cycles, but I am excited about this new
keybinding.
This commit additionally:
- Moves keybindings out of display.el and into keybindings.el
- Conditionally sets KBDs if using work laptop
|
|
Currently, after I connect my monitor to my laptop, I run `display/enable-4k`,
which will use `xrandr` to enable the display. The scaling of the enabled
display is not what I expect. So I've habituated re-running the same function,
`display/enable-4k`, which scales the display and meets my expectations.
What's strange is that if instead of running `display/enable-4k` the first time
from Emacs, I call `xrandr ...` from a terminal, this enables the display and
scales it properly on the first invocation.
I'm unsure how to explain this behavior. It's possible that a environment
variable is set properly in the terminal that isn't set in my Emacs, but this is
just a guess.
I'm going to using a different invocation in display.el that explicitly passes
the monitors dimensions. Let's see if that works.
|
|
Moving all of my Emacs-related files into their own directory at the root of
this repository.
|
