Move hl-line-range-function fix to ui/doom

Remapping the hl-line face is what causes the bug that this fix
addresses.
This commit is contained in:
Henrik Lissner 2019-03-05 03:01:59 -05:00
parent 35321e8b42
commit 1ec9f5b2e9
No known key found for this signature in database
GPG Key ID: 5F6C0EA160557395
2 changed files with 16 additions and 15 deletions

View File

@ -274,21 +274,6 @@ read-only or not file-visiting."
(setq hl-line-sticky-flag nil
global-hl-line-sticky-flag nil)
;; On Emacs 26+, when point is on the last line, hl-line highlights bleed into
;; the rest of the window after eob. This is the fix.
(when EMACS26+
(defun doom--line-range ()
(cons (line-beginning-position)
(cond ((let ((eol (line-end-position)))
(and (= eol (point-max))
(/= eol (line-beginning-position))))
(1- (line-end-position)))
((or (eobp)
(= (line-end-position 2) (point-max)))
(line-end-position))
((line-beginning-position 2)))))
(setq hl-line-range-function #'doom--line-range))
;; Disable `hl-line' in evil-visual mode (temporarily). `hl-line' can make the
;; selection region harder to see while in evil visual mode.
(after! evil

View File

@ -58,6 +58,22 @@
;; considered an unreal buffer, so solaire-mode must be restored.
(add-hook 'org-capture-mode-hook #'turn-on-solaire-mode)
;; On Emacs 26+, when point is on the last line and solaire-mode is remapping
;; the hl-line face, hl-line's highlight bleeds into the rest of the window
;; after eob.
(when EMACS26+
(defun +doom--line-range ()
(cons (line-beginning-position)
(cond ((let ((eol (line-end-position)))
(and (= eol (point-max))
(/= eol (line-beginning-position))))
(1- (line-end-position)))
((or (eobp)
(= (line-end-position 2) (point-max)))
(line-end-position))
((line-beginning-position 2)))))
(setq hl-line-range-function #'+doom--line-range))
;; Because fringes can't be given a buffer-local face, they can look odd, so
;; we remove them in the minibuffer and which-key popups (they serve no
;; purpose there anyway).