• zygo_histo_morpheus@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    There are many cases I actually prefer the quickfix list to an interactive picker:

    • When working on a very large project, such as my $DAYJOB, interactiveness gets in the way more than it helps if you’re running a slow command (like greping a large number of files)
    • You can use :Cfilter to filter things matched in the quickfix list and :colder/:cnewer to navigate the history of the quickfix list without having to rerun the command
    • You can run ex commands on the items in the quickfix list, like :cdo norm gcc to comment the matched lines (with the vim-commentary plugin), run a macro with :cdo norm @q, or :cdo yank A to put all the matched lines in the a register for example. You can also do stuff like :cdo -10,+10g/re/p to print all lines matching some regular expression re within the range of 10 lines before to 10 lines after the match.
    • You can put more things in the quickfix list than you can with interactive pickers, like :Git diftool to get diffs. Vim also has support for parsing the output of many compilers and linting tools so you can use e.g. :compiler cargo followed by :make to build the current project with cargo and get any build errors in the quickfix list.

    In short, interactive pickers are better for browsing, but the quickfix list is better for scipting and holding on to data for longer without having to rerun commands, and can with some basic scripting be used for more things.

    Afaik helix doesn’t have diff capabilities which is also a major thing missing from my git workflow.

    I expect some of these things to make it into helix eventually, particularly git stuff, but I would be surprised if they add support for more weird janky vim stuff like the quickfix list and ex commands, which is a valid design decision, but they are also very useful tools once you get your head around them.