False error when searching closing parenthesis about ctrlf

[raxod502]

This does not occur for me. Is there something else in your configuration interfering?

[AmaiKinono]

I can reproduce it in emacs -Q. I suspect this is another "Emacs 26" problem (I'm on Emacs 26.3, and the latest version of CTRLF).

Here's the snippet:

(add-to-list 'load-path "/home/kino/.emacs.d/straight/repos/ctrlf/")
(require 'ctrlf)
(ctrlf-mode)

M-x ctrlf-forward-literal, then type ), this happens:

But just wait for a while, the message will disappear, and the first match is highlighted, everything is back to normal.

I think this is because CTRLF calls re-search-forward internally, and if you M-x re-search-forward RET ), the same message appears.

[raxod502]

That message is actually from blink-paren-mode. See blink-matching-open in simple.el. Does it make sense to disable blink-paren-mode in the minibuffer automatically?

[AmaiKinono]

Does it make sense to disable blink-paren-mode in the minibuffer automatically?

Well, I'd say it depends. I use show-paren-mode so I find this useless, but maybe some users need it. It's rare we need to care about matching parenthesis when searching, but sometimes we do. I don't oppose this change, though.

Maybe it's better to highlight the match and at the same time keep the message, but I wonder if it's possible.

Btw, I didn't find blink-paren-mode in Emacs 26. It's controlled by a variable blink-matching-paren.

[raxod502]

Btw, I didn't find blink-paren-mode in Emacs 26. It's controlled by a variable blink-matching-paren.

You are correct. My mistake.

Maybe it's better to highlight the match and at the same time keep the message, but I wonder if it's possible.

In general yes, maybe not with blink-matching-paren because I believe it operates by actually moving point and freezing the entire interface. I might be able to hack around it (by making CTRLF run first) but don't want to, so I disabled blink-matching-paren in CTRLF.

[AmaiKinono]

Thanks!