I really like working with grep for it's robust work and customizability.
:vimgrep is too slow for me, grep without --include (or --exclude) too. Also I work with at least 8 file types and --include is a huge helper.
My problem is that:
:grep "ILookForThat" **/*.{c,h}*
Search only one catalog depths, while I need at least four.
:grep -R "ILookForThat" --include=*.{c,h}*
Doesn't work ( the same with "*.{c,h}*" )
What I look for is answer: how to make grep (not vimgrep, ag, or anything else) work, or maybe some answer like: "That definitely should work".
I can add that I use 64 bit Ubuntu 16.04 LTS , removed my aliases for grep.
Of course answers without quicklist are with no acceptance.
After some quick tests I think this should work for you but it's a little verbose:
:grep -r --include="*.c" --include="*.h" "ILookForThat" .
You could consider wrapping this in a custom :command if it's too verbose to be useful.
:grep -r --include=*.{c,h}* ILookForThat .
Everything works as designed, but grep used from within vim has to have a starting point which is stated with a dot character.
Related
I want to use the glob qualifiers in zsh to sort files by various criteria. For example, ls -l *(.oL) is supposed to return ordinary files sorted by size.
Everything else in zsh seems to work as advertised, but the sorting operators o and O have no effect. The results are always sorted by filename.
I’ve tried removing my .zshrc file, but that did not fix this.
I’m on Debian 11 and installed zsh from the repository, getting me v. 5.8.
Charles Duffy is correct, it is ls that is re-sorting the files alphabetically. We can see this using his suggestions or simply by using echo.
ls has its own sorting flags, but I wanted to commit just one syntax to memory. Filename sorting in ls can be disabled with the -U flag.
It’s odd, because several popular guides to zsh that I consulted all use sorting examples with ls. Has ls changed its behavior recently? Is the version distributed with Debian unusual?
I use fzf.vim quite a bit in my workflow I have one problem when using :GFiles.
In the codebase I work on, we have src/node_modules checked into git, so whenever I use :GFiles we get a lot of results back, which includes the node_modules contents.
How can I remove items that start with src/node_modules* for example from the :GFiles command in fzf.vim?
I figured out that git ls-files is what :GFiles run and the implementation allows for arguments and unix pipes.
The solution is to run grep to filter out the results:
map <C-p> :GFiles \| grep -v -E "(node_modules\|bower_components)"<CR>
I was following the guide at teuton.blogspot.com to set up autocompletion, when I ran the command:
ctags –R --c++-kinds=+p --fields=+iaS --extra=+q \
-f ~/.vim/commontags /usr/include
to generate a tagfile, only to realise that the command would generate a 'commontags'-file of 1.5GB – a bit larger, than I'd have liked it to be, no doubt. So I was wondering is there some way of compressing the file and have vim still recognize it?
I tried running it through gzip, which churned it down to 25MB, but I've had no luck getting vim to use that file instead.
Any ideas? I'd be grateful!
/B2S
Using --excmd=number should cut the file size down by around 50% because ctags will only store line numbers of matches instead of a search pattern. This should be fine if the files in /usr/include don't change very often.
Even if you could compress the tags file vim would still have the overhead of uncompressing it for searches.
Your best bet is excluding what you don't need. Most of the /usr/include/ are probably dev files you needed to install source packages.
You're better off creating a tags file relevant to your development projects. Basically opt in to a directory when you file you cant tag jump to it. Rather than build an enormous list of irrelevant tags. Even if your machine is fast enough to process it you will still have to deal with duplicate names.
If you want to suck in everything you might be able to use --exclude to chop it down to a manageable size. ie. a blacklist rather than a white list approach.
man ctags
/--exclude <-- to search for exclude
I'd personally do something like
`ctags –R --c++-kinds=+p --fields=+iaS --extra=+q \
-f ~/.vim/commontags /usr/include/lib_i_need_a /usr/include/lib_i_need_b `
I'd like to do ls without seeing all the ~ files generated by vim. Is it possible?
This is better solved from within vim, as opposed to bash.
Use
set backupdir=~/.backup,/tmp
to put all your ~ files in the ~/.backup directory. Change that directory to whatever you want. The /tmp means that it will act as a fallback to the ~/.backup directory.
If you don't want backup files to be generated at all, you can use
set nobackup
set nowritebackup
to disable it, but you will of course lose that functionality.
EDIT:
Although the above solution is still the one I recommend because you can do more with it, I just realized that ls has a -B option which will hide files ending with ~. I've aliased it myself, and never noticed. If you really want, you can alias ls -B and go with that.
EDIT v2.0:
As noted by Wesley, some platforms' ls command have different meanings for -B, some may not have it at all. I'm using the GNU ls, and it has had this switch for as long as I can remember.
Many editors use the ~ files to represent backup files. (I use this trick to hide the backup files from gedit.) To disable them from showing, add this command to your bashrc:
alias ls='ls --hide=*~'
Edit: Mac OS X ls does not appear to have this option, so it follows that BSD ls probably doesn't have it either. Ubuntu does have this option, so many Linux distributions probably do; check your manual pages. In addition, Mac ls appears to have a different -B, so consider this when using Sykora's advice.
You'll be sorrrrryyyy if you just hide them from ls. They'll still be there as far as grep and other tools are concerned except that now you can't see them. Moving them to /tmp is a much better way to go.
This problem is ESPECIALLY severe with .svn directories, which have all kinds of useless cr*p that you really don't want to edit. I don't know a solution to that one.
For Mac OS X:
brew install coreutils
echo "alias ls='/usr/local/bin/gls -B'" >> ~/.bashrc
The following command gives many manuals of Zsh
man zsh<tab>
alt text http://dl.getdropbox.com/u/175564/zsh.png
I would like to browse them fast to search the word compinit.
How can you search the word compinit fast in the manuals in Zsh?
Often for this kind of thing
man -k compinit
works, because authors are sensible enough to put lots of identifiers into the "short description" of the man page.
This doesn't seem to be the case here ... so you're going to have to grep through the source. Which is gzipped ...
zgrep -c compinit /usr/share/man/man1/zsh*
or if you don't have zgrep:
cd tmp
cp /usr/share/man/man1/zsh* .
gunzip zsh*.gz
grep -c compinit zsh*
There are more elegant ways to do this, but that gives you a list of how often compinit appears in each file:
zsh.1:0
zsh4.1:0
zshall.1:0
zshbuiltins.1:0
zshcalsys.1:0
zshcompctl.1:0
zshcompsys.1:29
zshcompwid.1:0
zshcontrib.1:0
zshexpn.1:0
zshmisc.1:0
zshmodules.1:1
zshoptions.1:0
zshparam.1:0
zshroadmap.1:0
zshtcpsys.1:0
zshzftpsys.1:0
zshzle.1:0
Using the internet is probably the best way. The other approach is to use the zshall manpage, which contains all the manpages together. You can then search for compinit in whatever viewer you're using.
EDIT: I just remembered a better way of doing this: Use zsh's run-help function.
$> run-help compinit
This will take you to the manpage that zsh thinks is most appropriate for the topic. It also works for non-zsh related topics like ps, grep, etc, but has been adjusted to work for zsh topics as well.
If for some reason run-help isn't loaded, you can use
$> autoload run-help
to do so.
You could use the internet... all of the man pages are on it... just prefix your searches with
zsh man
(If you know where they are located on the harddrive... you might be able to grep them... I don't know as I have not ever needed to myself)