A rg-define-search example for the documentation

[hmelman]

I'd like to propose this or something like this (the :dir path is for macOS) as an example in the documentation.

(rg-define-search rg-emacs 
    :dir "/Applications/Emacs.app/Contents/Resources/lisp" 
    :flags '("-z") 
    :files "*.{el,el.gz}" 
    :menu ("Custom" "L" "lisp"))

It seems like it would be a useful example, as I expect many emacs users search the emacs lisp source while customizing emacs. It took me a long time to get this working as emacs' lisp directory has mostly .el.gz files.

First I was surprised that just rg -z --type elisp didn't work, but that's the way ripgrep works. Then I put:

--type-add
elispgz:*.{el,el.gz}

in my ~/.ripgreprc file and that made a command line like rg -z --type elispgz work but it didn't work in rg.el in emacs. First I was using :files "elispgz" but found out that was incorrect. Then I tried :flags '("-z" "-telispgz") but that didn't work because rg-ignore-ripgreprc is t. It would help if it's documentation explained better what might break if it's nil. I really didn't want to replicate my --type-adds in rg-custom-type-aliases so I found the above worked.

Lastly I added the :menu part. At first I used "Search" from the rg-define-search documenation example but found that put this (and some others I defined) in the existing first column of rg-menu and that seemed out of place. "Custom" seems better as an example as is used in the rg manual section called The menu . I also suggest adding the various keyword arguments like :dir, :flags, etc to the rg.info index.

[dajva]

Thanks for the example. It's a good one that I will consider for the documentation.

rg-ignore-ripgreprc is new so it may need a bit of clarification. The main problem is that the requirements may change so any detailed documentation of breakage is likely to get out dated. So what will break kind of depends. I think the most problematic ones are any custom colors that may break parsing of the results via color codes.

[hmelman]

I think anything more specific, even if just provisionary, than "Disabling this setting can break functionality of this package." would be a help.