It seems there's an edge case in EXWM where input events may occur
without keys to cause them (#8064), so these two keybind fixes need to
be ready to receive an empty vector from `this-single-command-raw-keys`.
Fix: #8064
This was a tricky regression to track down. 9753bfb tries to fix an
issue where the `default` face's :foreground changes to `#000000` in any
new frames created after the initial one (by calling `make-frame`),
because those frames' `background-color` and `foreground-color`
parameters default to "#000000" (possibly a bug with `disable-theme` too
eagerly defaulting them to black).
240493a replaces that with new, seemingly cleaner approach: setting
`frame-inherited-parameters`, which instructs `make-frame` to copy those
parameters from the last open frame, however, those parameters in the
initial daemon frame will be set to "unspecified-bg" or
"unspecified-fg" (see the docstring for `face-{back,fore}ground`), which
are invalid color strings. `make-frame` crashes tries to create a frame
with those color values, causing #8059.
Fix: #8059
Amend: 240493ae92
Amend: 9753bfb775
Those `face-*` calls sometimes returned nil, causing new frames spawned
from emacsclient to quietly crash sometimes. By instead relying on
`frame-inherited-parameters` we achieve the same but more stable result.
Amend: 9753bfb775
Now, uses can rebind ctrl+m by targeting [C-m] (or "<C-m>", same thing),
and it won't rebind RET. This will only work in GUI Emacs, however, and
there is no kkp support for this one.
Ref: 96d7e50f3e
Experienced users (the type to use symlinks in their projects) can add
-L back to `projectile-git-fd-args`, otherwise, its poorer UX for
beginners if Projectile indexes symlinked build artifacts (like 'result'
symlinks by Nix); i.e. things they didn't symlink themselves.
Fix: #7781
Instead of constantly checking $__DOOMSH, since I may eventually add
additional values for it (like in the cases where the doom script is
invoked by bin/doomscript, from a terminal emulator in Emacs, or future
wrappers).
c9acdb7 removes doom.cmd because it was broken in most cases. This adds
doom.ps1; an alternative script for Windows+Powershell users, which
properly initializes the state it needs. Naturally, it requires
Powershell 3+ be installed on your systems, but it can be invoked from
either cmd.exe or PowerShell.exe.
This is the first powershell script I've ever written, so I expect edge
cases (for one, shell commands passed to `exit!` will need to be guarded
against the environment).
This also requires emacs.exe be your $PATH, however, unless you set
$EMACS to its path first. E.g.
$env:EMACS = "C:\Program Files\Emacs\emacs-29.4\bin\emacs.exe"
That said, if you use WSL2, you're still far better off using the bash
script (bin/doom).
Ref: c9acdb72a4
New frames created after the first get initialized with #000000 as their
{back,fore}ground-color parameters, for some reason, making text
unreadable in dark themes.
`(de?)activate-mark-hook` is triggered a little too often in too many
edge cases where the user isn't interactively selecting a region. One
annoying edge case has non-evil motions used on evil operators
activating but not deactivating the mark (e.g. #8047).
This leaves non-evil users without the nicety of hl-line auto-disabling
itself when the region is active, but I'll revisit that in v3.0, when
most of these package defaults are moved out to modules.
Fix: #8047
Eventually, I want to autoload some of this stuff, so that users in
interactive sessions can safely load it without side effects (useful
when writing their own CLIs or editing Doom's source).
Doom loaded subdirs.el's in `load-path`, but doesn't need to. This
normally wasn't an issue because subdirs.el files are typically
idempotent, but there is one case where it isn't: on nixpkgs, with
certain configurations on top of programs.emacs (see
NixOS/nixpkgs#267548), which will cause file-missing errors trying to
load the user's site-lisp afterwards (see #7681).
Ref: NixOS/nixpkgs#267548Fix: #7681
Amend: 6c0b7e1530
