radian-software / ctrlf Goto Github PK

Hi,

I really want to like this package, especially because of this design principle:

re-use the flow and keybindings of Isearch

I could never stick with swiper et. al. because, as an old Emacs user, all the semantics of isearch and search-map are embedded in my fingers.

The first thing I noticed was that I had a ctrlf search going, and then wanted to pull up my Occur buffer (to go use the handy occur-edit-mode). From an ongoing isearch, this is just M-s o:

M-s o runs the command isearch-occur (found in overriding-terminal-local-map)

Which runs occur from isearch. Outside of an isearch, this same binding just runs occur.

A lot of the toggles listed under the core keybindings I think ought to exist under the (overriden) search-map bindings, to really uphold the stated design principle. Right now, M-s runs the command next-matching-history-element, which is completely unexpected as Emacs/isearch user when running a search.

Some others I can think of:

• M-s o to switch to occur (as above)
• M-s r to toggle regexp/literal (currently on C-M-s and C-M-r, which are fine to keep too, but also on C-o s which isn't Emacsy)
• M-s . runs the command isearch-forward-symbol-at-point (this works both in and out of an isearch), should run ctrlf with the symbol at point (currently on M-n, which also seems fine, but different from isearch)
• M-s c toggles case sensitivity (currently on C-o c which also isn't Emacsy)
• M-s e doesn't need to exist, since it enters isearch edit mode, but ctrlf appears to always be editable

It seems like adding the prefix C-o was just a choice made during development, but it's inconsistent with the design principle of re-using the flow and keybindings of isearch. The search-map is really handy, and already bound to M-s, which a lot of Old Emacs Users already use (and some of us add a lot of other things to the normal search-map, like bindings to rgrep and equivalents).

Anyway, ctrlf looks really promising, thanks for the work on it. I just found the lack of M-s very jarring as an isearch user.

This is a QoL issue, a potential user enabled customization, but I find myself needing to search with the same input, not having hit enter to commit the previous search but having typed C-g to exit the search prematurely. I have to type the word again after a subsequent C-s because it is not saved in C-r or s i-search results. I do notice I typically type C-s, C-r, C-l again after an initial C-s or C-r so maybe capturing the searched text somehow during those events would help?

I don't have hl-line-mode enabled, so that face doesn't exist for me. But I don't have a good idea about which face to inherit.

Bind C-l to recenter, C-v and M-v to move a page's worth of matches forward or backward.

I updated to the latest version, then I got this when Emacs startup:

Symbol's function definition is void: map-apply

The weird thing is even I remove the use-package code of CTRLF, this still happens. I looked into it and found it may be caused by this in the autoload:

(define-minor-mode ctrlf-mode "Minor mode to use CTRLF in place of Isearch.
See `ctrlf-mode-bindings' to customize." :global t :keymap ctrlf--keymap (when ctrlf-mode (setcdr ctrlf--keymap nil) (map-apply (lambda (key cmd) (when (stringp key) (setq key (kbd key))) (define-key ctrlf--keymap key cmd)) ctrlf-mode-bindings)) (with-eval-after-load (quote ctrlf) (if ctrlf-mode (advice-add (function minibuffer-message) :around (function ctrlf--minibuffer-message-condense)) (advice-remove (function minibuffer-message) (function ctrlf--minibuffer-message-condense)))))

When I delete straight/build-cache.el, Emacs could startup correctly, but when I open Emacs again, it fails. Notice that the use-package code of CTRLF is already removed, but I think straight still builds it since it's in straight/repos.

A simple fix is add ;;;###autoload on (require 'map), but I'm not sure if this is a good fix.

Example: search for ^ in regexp mode. The number of matches appears to be doubled.

isearch opens invisible org-mode sections if there are matches within them. ctrlf does not do this. It finds the matches and you can cycle between them, but they are invisible if the section is invisible.

Hi, I know that you list the Overview feature of Swiper as maybe not that useful. However, I really like being able to see occurances (and some context) throughout the buffer, even those that are not visible yet. Any chance there will be a similar feature in Ctrlf?

I'm loving Selectrum and am looking to get rid of the Swiper/Ivy/Counsel suite.

Thanks!

Currently, only the text content of the current line is highlighted when ctrlf-highlight-current-line is non-nil. However, it is possible in Emacs to highlight the entire line, all the way to the right margin. We should do this instead.

Hi!

Really nice package here, it feels very snappy and is simple to use, thank you for your work!

Unfortunately it seems that it's not really compatible with mini-frame. For instance, C-s keeps moving the cursor back to the beginning of the prompt and then input is reversed.

To reproduce, evaluate code below in an emacs -Q and try C-s

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'mini-frame)
(straight-use-package 'ctrlf)

(ctrlf-mode +1)
(mini-frame-mode +1)

If you start CTRLF and then press C-SPC immediately, you end up with a rather odd result:

In particular the minibuffer prompt has been selected, and if I type M-w then the prompt is copied to my kill ring.

Mark behavior is otherwise unremarkable. It's just when the search input is empty.

Although searching for the empty string is not interesting, it is interesting to search for something like %* which matches not only the empty string but also other strings. Therefore we should support this use case.

(Currently, if you change the regexp to something that matches the empty string, the previous search results remain onscreen, which is also bad and should be fixed.)

When searching ), ] or }, CTRLF says "No matching parenthesis found", but the search actually success, I can call ctrlf-next/prev-match to browse the result.

This happens in all search styles.

This is good:

This is bad:

This illustrates that the overlay is still being created; it's just not visible by default:

(These examples are in org-mode.)

Hello,

It seems that ctrlf doesn't support char-fold-to-regexp search mode (see search-default-mode). It would be lovely to get support of this feature as it helps searching text with diacritical marks. For example, consider the following buffer:

Bună dimineața
Buna dimineata

With isearch typing buna matches both variants, while ctrlf matches only the last one.

You can read more about this feature in the documentation of char-fold-to-regexp function or in pretty old post by Artur Malabarba.

Thanks in advance :)

Sometimes we are just searching to peek things. When the match is on the beginning/end of the window, we have to search backward/forward again and then move back to show its surroundings. So how about keeping current match in the middle of the window?

When using helm and loading the default keybindings in helm-config, helm-minibuffer-history is bound to C-r in minibuffer-local-map, which the minibuffer keymap used in ctrlf inherits from. Pressing C-rwill then call helm-minibuffer-history instead of the remapped isearch-backward from ctrlf-mode-bindings.

I solved this simply for my case by:

(add-to-list 'ctrlf-minibuffer-bindings '("C-r" . nil))

I don’t know if anything should be done on the side of ctrlf to prevent this, or if it should be left to the user (perhaps with a note in the readme?). One idea otherwise is to bind C-r to isearch-backward and C-s to isearch-forward in ctrlf-minibuffer-bindings to prevent any other command from overriding it, but I suppose that's not a very good idea either as we can’t assume those are the keys the user wants to use.

What we would like to do is unbind (or bind correctly) any bindings for the keys used for isearch-forward/backward when the minibuffer keymap is created, but I don’t know if this is possible

I do not currently have a full recipe to reproduce this issue, but sometimes pressing C-g will not reset point to its original position, but rather to the beginning of the current line.

When searching for a symbol, we use this regexp:

\_<symbol-name\_>

This works fine in isearch-foward-regexp, but when typing it in CTRLF, Emacs stucks like forever. Typing C-g can recover it, but I can't search anything after that in the current CTRLF session.

I can paste it directly and make CTRLF do the search, so this should be a problem when handling user input.

Currently when the mark is active and you type C-g, the current CTRLF session is aborted. Instead, the mark should be deactivated.

When using pdf-tools and its pdf-isearch-minor-mode to search in pdfs this works by pdf-isearch-minor-mode setting variables like isearch-search-fun-function to suitable functions that work on the pdf. This doesn't work at all when ctrlf-mode overrides the keys for isearch.

A simple solution would be to make it possible to disable ctrlf-mode locally.
Then we could just do:

(add-hook 'pdf-isearch-minor-mode-hook (lambda () (ctrlf-mode -1)))

A more complex and more awesome solution would be to implement all the things that isearch does with these redefined functions. pdf-isearch-minor-modesets:
isearch-search-fun-function, isearch-push-state-function, isearch-wrap-function and some other options.

CTRLF remaps minibuffer-beginning-of-buffer to ctrlf-first-match, but that doesn't work on my setup, and I didn't find such a command. I changed it to beginning-of-buffer and it works. Should this be done?

When moving to the next/prev match and the window scrolls, you can see the overlays refresh a little bit later. This is obvious when ctrlf-highlight-current-line is on, it feels like flicking.

I tried a little bit and found if I comment out this (redisplay) line, the problem is fixed, but seems that's not the right thing to do.

I'm trying to get rid of ivy and swiper. When using ctrlf to find next search using, my muscle memory make me press C-n and I get

Not a really big issue, and I may forget C-n and use C-s instead.

I'm migrating from ivy to selectrum (as you know). Now what I miss most is swiper and counsel-git-grep. I can do search & replace with the built in tools from Emacs, but when I'm just searching and jumping to places (without replace), I would like to have an ivy/selectrum like UI. When I was just thinking about implementing it using selectrum, I saw this package. I haven't tried it mainly because I didn't get an impression from the README. So, what will it be like? Could you talk a little about your blueprint or design?

If you delete the entire search query, the match count can end up on the left-hand side of the CTRLF prompt.

I think we need replacing functionalities to make this package complete. Do you already have some thoughts or design on this?

When navigating between matches, it is difficult to keep track of the match index and count because they are in the minibuffer but you are looking at the main buffer. One way to address this problem is to additionally add an overlay to the right margin of the buffer being searched which duplicates the match index and count information.

Similar to #1, point flickers to different positions while typing.

Typing C-u 5 C-s should move forward five times, and analogously for C-r.

In isearch, the default behavior is do case insensitive search when the user input is all lower case, and do case sensitive search otherwise. This is neat.

I once thought this behavior is controled by case-fold-search, but then I found it controls case sensitivity directly. If there's no built-in mechanism for this, we may need to invent our own.

here https://github.com/raxod502/ctrlf#why-not-swiper you didn't mention swiper-isearch, which was introduced a year ago

Using regexp search for ^ in following sample file, including trailing newline:

ff
ergergjeg
egr
hst
sth
tshr
g
gre
ergs

• No match is displayed on the first or last line although it is possible to select those matches interactively.
• When the match on the last line is selected, no other matches are reported.
• When starting from the beginning of the buffer and advancing using C-s, the first match is selected after the fourth one, so the fifth and following matches are only selectable using M-> or by moving point manually.

Snippet of my config:

(use-package ctrlf
  :straight (ctrlf
             :type git
             :host github
             :repo "raxod502/ctrlf")
  :config (ctrlf-mode +1)
  :bind (:map minibuffer-local-map
              ("C-r" . ctrlf-backward-literal)))
;; Not sure why
(ctrlf-mode +1)

Notice I have to activate ctrlf-mode twice to get it to stay active. Also, another issue I had was having to define "C-r" keybind again even though i-search appeared to be overridden by ctrlf, but only to get C-r's to work in the minibuffer.

Currently if you want to switch between literal and regexp searches, you have to exit and come back. We could instead simply bind C-M-s and C-M-r as toggles during a search.

Hello,

If ctrlf-occur is called before ctrlf is used for the first time, it will fail with a Lisp error (void-function nil).

Steps to reproduce:

1. Open emacs;
2. Execute ctrlf-occur.

Best regards.

When typing, the match count in the minibuffer flickers a little bit. This is a bug and should be fixed.

I frequently use find-file history search (C-x C-f followed by C-r). That errors out with ctrlf-mode enabled. I'm not sure if there's a recursive minibuffer in play when isearch is used from find-file or switch-buffer, but maybe you could detect this situation and fall back to vanilla isearch.

If the match count overlay is active and you trigger a message (e.g. by trying to use a recursive minibuffer), point shows up between the two messages rather than in its usual place at the end of the user input.

After starting a search, I should be able to change the direction without inserting the last search query.

It's not currently possible to select text in the minibuffer while CTRLF is active.

Currently, zero-length matches are invisible, which is bad user experience. They should be displayed as some sort of (preferably effectively zero-width) vertical bar.

Basically now I can't type any backslash in regexp search. For example:

\(aa\).*\(bb\)

It will look like this:

But the warning disappears as long as I finish a valid regexp.

Currently, I'm using phi-search for its integration with multiple-cursors. Is there an easy way to extend ctrlf to also support multiple cursors? For now, I've employed this hack:

(defmacro ctrlf-or-phi (key phi-version ctrlf-version)
  "Call ctrlf unless multiple cursors are active, in which case call phi"
  `(global-set-key (kbd ,key)
                   #'(lambda () (interactive)
                       (if multiple-cursors-mode
                           (,phi-version) (,ctrlf-version)))))
(ctrlf-or-phi "C-s" phi-search ctrlf-forward)
(ctrlf-or-phi "C-r" phi-search-backward ctrlf-backward)

It's not good to have a public user option (ctrlf-style-alist) whose default value includes private symbols (e.g. ctrlf--fuzzy-translate). This should be fixed.

Currently if you use C-s to jump to a match, then press C-r C-r, you jump to the previous match. However, if you do the same sequence of actions with the roles of C-s and C-r interchanged, you stay at your current match. The latter behavior should be used in both cases.

In Isearch, it is possible to toggle case-fold-search by pressing M-c or M-s c during an active search. I don't think binding M-c is a good idea given that CTRLF (unlike Isearch) actually allows you to edit the query at any time, but binding M-s c would be great. Implementing this feature will require updating the search results automatically when case-folding is toggled. See also #22.

If you perform a search which takes you away from the original position of point, then when you press C-g point is restored correctly but the scroll position of the window may be different. This is a bug.

To reproduce: type C-p repeatedly. Copies of [Beginning of buffer] will accumulate until the search query is modified. This is because the overlays are condensed into the match index and count overlay, which is marked as persistent. It is the opposite problem from this code: https://github.com/raxod502/ctrlf/blob/aea8d3c4eb66c3754a0508b5dfc02bf1cad65833/ctrlf.el#L576-L588

Starting with an empty config, and adding the following lines

(setq initial-buffer-choice "buffer1")
(setq straight-repository-branch "develop")
(defvar bootstrap-version)

(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'ctrlf)
(ctrlf-mode +1)

If I start Emacs, write something in the buffer and then and press C-s or C-r once, I get in the mini buffer

CTRLF ↑ literal:

but after I write some text and re-press C-s or C-r to search for it, instead of navigating through the occurrences I get a message in the mini-buffer:
I-search backward: [No previous search string]

and in the *Messages* buffer:
isearch-edit-string: Command attempted to use minibuffer while in minibuffer

I then have to cancel the command with C-g and if I try to use CTRLF again, this time it works in the expected way.

This also happens if the user does not suppress the default splash screen.