Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Is this a useful feature to add? #1408
Searches for the pattern
So far I've been making these changes in my personal configuration, but if you think it's worth adding them to swiper I can create a PR.
Of course, if there is a better way to accomplish this let me know.
(defun lr/parse-ag-input (string) "Parse the user input as STRING into a list of two strings: (query extra-ag-args). Where query is the search term and extra-ag-args are any additional switches." (let ((query string) (extra-ag-args "")) (when (string-prefix-p "-" string) (let ((index (search "-- " string))) (when index (setq query (substring string (+ 3 index))) (setq extra-ag-args (concat " " (substring string 0 index)))))) (list query extra-ag-args))) (defun lr/counsel-ag-function (original/counsel-ag-function &rest args) (let* ((string (car args)) (base-cmd (cadr args)) (extra-ag-args (caddr args)) (result (lr/parse-ag-input string))) (setq string (car result)) (setq extra-ag-args (concat extra-ag-args (cadr result))) (funcall original/counsel-ag-function string base-cmd extra-ag-args))) (advice-add 'counsel-ag-function :around #'lr/counsel-ag-function)
(defun lr/counsel-grep-like-occur (cmd-template) (unless (eq major-mode 'ivy-occur-grep-mode) (ivy-occur-grep-mode) (setq default-directory counsel--git-dir)) (setq ivy-text (and (string-match "\"\\(.*\\)\"" (buffer-name)) (match-string 1 (buffer-name)))) (let ((result (lr/parse-ag-input ivy-text)) (extra-ag-args nil) (cmd nil) (cands nil)) (setq ivy-text (car result)) (setq extra-ag-args (cadr result)) (setq cmd (format cmd-template extra-ag-args (shell-quote-argument (counsel-unquote-regex-parens (ivy--regex ivy-text))))) (message "%s" cmd) (setq cands (split-string (shell-command-to-string cmd) "\n" t)) ;; Need precise number of header lines for `wgrep' to work. (insert (format "-*- mode:grep; default-directory: %S -*-\n\n\n" default-directory)) (insert (format "%d candidates:\n" (length cands))) (ivy--occur-insert-lines (mapcar (lambda (cand) (concat "./" cand)) cands)))) (defun lr/counsel-ag-occur () "Generate a custom occur buffer for `counsel-ag'." (lr/counsel-grep-like-occur "ag --nocolor --nogroup %s -- %s")) (advice-add 'counsel-ag-occur :override #'lr/counsel-ag-occur)
Yes, it's not a new capability but a UI enhancement.
The prompt behaves as it does now unless the search term starts with
I hope it makes more sense.
If I'm not mistaken, I think this is how helm-ag works which IMHO is very convenient.
I tried to use the prefix argument as @abo-abo mentioned above for counsel-ag (
then no matter what I type and hit
I'm an emacs/spacemacs neophyte and might be misunderstanding or doing something wrong?
Anyway, if this PR is acceptable, would be cool to see it also in counsel-rg.
I see no-one has mentioned
I realise that Counsel, even more so than Ivy regexp builders, is a loose collection of community- (and owner-) contributed functionality (which no single person can easily maintain alone any more). Nevertheless, the
Personally, I think the ability to, in one way or another, modify the search command ad-hoc is essential. I like @DEADB17's suggestion to support command flags as part of the search input, as this is about as interactive/ad-hoc as it gets, with instant search result feedback. But the
Recursive editing is an interesting idea worth exploring even for the sake of consistency with other counsel commands, as you said in your comment.
It can either complement or replace the
Regarding the additional complexity of the code, again it's a judgment call once we can get a feel of how useful or redundant the interaction between the two is.
In general I find that reducing complexity comes from observing common patterns emerge. Sometimes two features might look redundant initially but evolve into separate entities after a while.
So, I'm in favor of adding features, observing and simplifying once it can be rationalized.
Regardless it'd interesting to try the recursive editing option. I don't have the time right now, but I will at some point if no one steps up before.
Judging from my own experience and the discussion in this issue, I don't think the recursive edit is convenient enough to replace inline switches. Its use case is more elaborate full-length command editing, so my suggestion is that they complement each other to an extent. Even if they are or become overly similar, there's no need to remove one or the other without good reason. Emacs and its packages should support as many workflows/options as possible within reason.
The two UIs are mostly, if not completely, independent of one another (one has already existed, and #1559 is proposing the addition of the other). So, agreeing that these two UIs are sufficient and should be applied consistently to all Counsel search commands will create no greater complexity than already exists.
Steps up to do what? Port
Also agree. I think inline flags might be more convenient though.
It can't replace it, but it's a simple low-impact command / key binding that can do the job. Plus it has history, which might be useful.