hlissner ( Henrik Lissner )

[ ] It targets the develop branch
[ ] I've searched for similar pull requests and found nothing
[ ] This change is NOT in Doom's do-not-PR list: https://doomemacs.org/d/do-not-pr
[ ] If I've bumped any packages, I've done so according to https://doomemacs.org/d/how2bump
[ ] I've linked any relevant issues and PRs below
[ ] All my commit messages are descriptive and distinct

-->

Fixes #0000

{{{ Summarize what you've changed HERE and why }}}

+1 -1

1 commit in hyperfocus1337/doom-emacs/tree/patch-1 hlissner/doom-emacs/tree/develop

0 comment

1 changed file

pr created time in 11 minutes

fork hyperfocus1337/doom-emacs

An Emacs framework for the stubborn martian hacker

hlissner/doom-emacs hyperfocus1337/doom-emacs

fork in 13 minutes

issue openedhlissner/emacs-solaire-mode

Autoloading file ~/.emacs.d/straight/build/solaire-mode/solaire-mode.elc failed to define function solaire-mode-in-minibuffer

I got this error constantly and i can't use solaire mode This is my config inside my init.el

;; A more complex, more lazy-loaded config
(use-package solaire-mode
  :straight t
  ;; Ensure solaire-mode is running in all solaire-mode buffers
  :hook (change-major-mode . turn-on-solaire-mode)
  ;; ...if you use auto-revert-mode, this prevents solaire-mode from turning
  ;; itself off every time Emacs reverts the `file`
  :hook (after-revert . turn-on-solaire-mode)
  ;; To enable solaire-mode unconditionally for certain modes:
  :hook (ediff-prepare-buffer . solaire-mode)
  ;; Highlight the minibuffer when it is activated:
  :hook (minibuffer-setup . solaire-mode-in-minibuffer)
  :config
  ;; The bright and dark background colors are automatically swapped the first 
  ;; time solaire-mode is activated. Namely, the backgrounds of the `default` and
  ;; `solaire-default-face` faces are swapped. This is done because the colors 
  ;; are usually the wrong way around. If you don't want this, you can disable it:
  (setq solaire-mode-auto-swap-bg nil)

  (solaire-global-mode +1))

created time in 14 minutes

startedhlissner/doom-emacs

started time in 30 minutes

startedhlissner/doom-emacs

started time in 3 hours

startedhlissner/doom-emacs

started time in 3 hours

fork sini/doom-emacs

An Emacs framework for the stubborn martian hacker

hlissner/doom-emacs sini/doom-emacs

fork in 9 hours

fork RyanBoring/emacs-doom-themes

An opinionated pack of modern color-themes

hlissner/emacs-doom-themes RyanBoring/emacs-doom-themes

fork in 11 hours

pull request commenthlissner/doom-emacs

Add Selectrum module Round 2

FYI, new which-key PR in need of testing; adds simple menu support, which in turns works with embark-act.

https://github.com/justbur/emacs-which-key/pull/308

Screenshot from 2021-06-19 18-57-31

Emiller88

comment created time in 12 hours

issue openedhlissner/emacs-doom-themes

Regression on doom-molokai magit vc-added highlights

What happened?

After updating 13d2377 to b2c0ea0, magit highlights for doom-molokai share the same background and foreground, making the diffs unreadable.

Old, commit, readable no matter if the cursor is inside the diff or not: old_1 old_2

New commit, unreadable if the cursor is not inside the diff: new_2 new_1

What did you expect to happen?

Have the same behavior as before (no green background for magit highlights). Example: doom-monokai-spectre works as expected.

Steps to reproduce

spc g g
scroll to a change in the magit status buffer.
Fail to read the change.

System Information

Emacs version: 27.1
Emacs distro: Doom Emacs
Operating system: Debian Bullseye
Installed commit of doom-themes: b2c0ea0
Which theme are you using: doom-molokai

created time in 13 hours

fork RyanBoring/doom-emacs

An Emacs framework for the stubborn martian hacker

hlissner/doom-emacs RyanBoring/doom-emacs

fork in 14 hours

startedhlissner/doom-emacs

started time in 16 hours

startedhlissner/doom-emacs

started time in 17 hours

pull request commenthlissner/doom-emacs

show all available lsp servers when switching

somewhat related, maybe should report as a bug: +lsp/switch-client sometimes restores the client priority before lsp-workspace-restart is finished, making so the server switch doesn't happen, putting the priority restauration on a 1s timer solved the issue for me, but doesn't seem like a good solution

chaoky