dajva / rg.el

Emacs search tool based on ripgrep
https://rgel.readthedocs.io
GNU General Public License v3.0
465 stars 38 forks source link

Only rg-use-old-defaults seems to work with result buffer #149

Closed PyB1l closed 1 year ago

PyB1l commented 1 year ago

In emacs 28.2 new defaults seem not to be working as expected in results buffer.

Although a get results when pressing RET on result I get a popup that asks me to manually set the path for the file.

On the other hand, rg-use-old-defaults seem to work as expected, but is there any workaround to use the new defaults and have the compilation / grep buffer work as usual?

dajva commented 1 year ago

Works fine for me. Could you post the result of running M-x rg-print-environment?

PyB1l commented 1 year ago

I get the following error:

Not enough arguments for format string

GNU Emacs 28.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2023-01-30

dajva commented 1 year ago

Sounds like you have some sort of error in your environment. Everything works fine for me in emacs 28.2. I suggest you try with the latest version of this package from master and use a clean emacs and see how it works.

PyB1l commented 1 year ago

Is it possible to happen due to xterm compilation filter? My init.el looks like this

(use-package compile
  :config
  (progn
    (setq compilation-scroll-output t)))

(use-package xterm-color
  :ensure t
  :functions (xterm-color-filter my/advice-compilation-filter)
  :config
  (progn
    (setq compilation-environment '("TERM=xterm-256color"))
    (add-hook 'shell-mode-hook
          (lambda ()
            ;; Disable font-locking in this buffer to improve performance
            (font-lock-mode -1)
            ;; Prevent font-locking from being re-enabled in this buffer
            (make-local-variable 'font-lock-function)
            (setq font-lock-function (lambda (_) nil))
            (add-hook 'comint-preoutput-filter-functions 'xterm-color-filter nil t)))
    (defun my/advice-compilation-filter (f proc string)
      (funcall f proc (xterm-color-filter string)))
    (advice-add 'compilation-filter :around #'my/advice-compilation-filter)))

(use-package rg
  :demand t
  :commands (rg-use-old-defaults rg-enable-menu)
  :config
  (rg-use-old-defaults)
  (rg-enable-menu)
  (setq rg-buffer-name
       (lambda ()
     (let ((p (project-current)))
       (if p
           (format "rg %s" (abbreviate-file-name (cdr p)))
         "rg")))))

(when (executable-find "rg")
  (setq grep-program "rg"))

(use-package wgrep
  :custom
  (wgrep-auto-save-buffer t)
  (wgrep-change-readonly-file t))
dajva commented 1 year ago

This is a known issue with xterm-color modifying the color sequences used by this package. The main problem IMO, is that xterm-color is integrated by advising compilation-filter which breaks modes like this that is not supposed to work with xterm-color. There is a pretty long discussion in #65 in case you want to dig into the details and the maintainer of xterm-color and me does not really agree on the problem here. My opinion is that you should probably hook in xterm-color the "normal" way by adding a compilation-filter-hook instead of using advise. Not sure how that works with that package TBH but in that way you should be able to make this package work even though it does not use the highlighting from xterm-color.

dajva commented 1 year ago

Closing this since there is not anything to fix in this package.