evil-collection-integration.el: advice show-paren-function doesn't highlight opening bracket

[edkolev]

Hi, and again, thanks for this package!

I ran into the following issue - in normal state, show-paren-mode works when the point is on an opening bracket ( (the closing bracket is highlighted), but doesn't work when the point is on a closing bracket (the opening bracket is not highlighted).

To reproduce:

• use this init.el

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/") t)

(package-initialize)

;; use-package
(setq use-package-enable-imenu-support t)
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(eval-when-compile
  (require 'use-package))
(setq use-package-verbose nil)

(use-package evil
  :ensure t
  :init
  (setq evil-want-integration nil)
  :config
  (evil-mode)
  (use-package evil-collection
    :ensure t
    :init
    (evil-collection-init)))

• start emacs
• M-x show-paren-mode
• run :new then enter (abc)
• put cursor on (, works as expected:
  
• put cursor on ) - doesn't work as expected because the opening bracket is not highlighted
  

Thanks!

[Ambrevar]

I haven't tried your recipe, but isn't it the expected behaviour?
What do you get with (setq show-paren-when-point-inside-paren t)?

I don't think evil-collection fiddles at all with show-paren-mode. I could be wrong though.

[jojojames]

@edkolev It does the same thing without evil-collection right?

I did a quick check with evil only and the same behavior exists (I believe... someone else please check. :))

I think you're right though, it should highlight the paren if you're on the ending paren and evil's eol defcustom is set (can't remember the name right now).

I think the problem is emacs by default (without evil/evil-collection) will only highlight the paren if the point is after the last paren (similar to how point needs to be after paren when eval-ing s-expressions).

I could be totally off base but I think taking a closer look at the show-paren advice we have and fixing it up will be the right fix.

Thanks for the report, that behavior was bugging me too but I couldn't put my finger on what it was.

[noctuid]

I don't have this issue with regular evil.

[jojojames]

I see..

Looks like evil-mode activates/deactivtes those advices..

(defadvice evil-mode (after start-evil activate)
  "Enable Evil in Fundamental mode."
  (if evil-mode
      (progn
        (when (eq (default-value 'major-mode) 'fundamental-mode)
          ;; changed back by `evil-local-mode'
          (setq-default major-mode 'turn-on-evil-mode))
        (ad-enable-regexp "^evil")
        (ad-activate-regexp "^evil")
        (with-no-warnings (evil-esc-mode 1)))
    (when (eq (default-value 'major-mode) 'turn-on-evil-mode)
      (setq-default major-mode 'fundamental-mode))
    (ad-disable-regexp "^evil")
    (ad-update-regexp "^evil")
    (with-no-warnings (evil-esc-mode -1))))

I have a couple ideas for a quick fix but would be interested in hearing some other ideas.

A better solution might be to just rewrite the advice to use the new advice-add advice and enable it using advice-add and/or run ad-enable/activate-regexp ourselves (that seems wayy messy).

[jojojames]

I just went with changing the advice + moving it to its own integration file. Lemme know how it goes for you @edkolev.

[edkolev]

Works great, thanks for the quick response! It now works as regular evil.

[noctuid]

Wouldn't it make sense to automatically add the advice?

[jojojames]

@noctuid

I wanted to move that functionality out anyways so just went with the optional.

It's similar to #60 (comment).

There might be a set of functionality that should be set even if the user doesn't want the related keybindings. I'm still thinking about how to handle that.

[noctuid]

My bad, I misunderstood the commit. Agreed that the separation makes sense.