Is there a way to automaticaly update tags in only one tag file - vim

I’m using vim with gutentags plugin https://github.com/ludovicchabant/vim-gutentags, which helps me to keep tags up to date in my project.
To give a bit of context, I’m working in a big project, containing a lot of git repos all connected together. That is why I often need to look for tags that are in another repo.
Gutentags is very useful because it manages all my tags automatically and updates them in a file. However, I’d like it to update them in a single file, where I want to, and not in multiple tag files.
I created a Maketags command in my vimrc that creates all the tags in a single file, but it freezes with GVim and not with Vim, and it is not automatic as I have to run it by myself and it opens a terminal view of the output:
command! MakeTags !ctags -V -R --c++-kinds=+px --extra=+qf --excmd=pattern --exclude=Makefile -f /root/of/the/project/tags /root/of/the/project/
Do someone know what, I could do to have a fully automated tags regenaration in a single tag file?

Related

Opening with gedit all files of a certain extension skiping one

I have several biblatex files in a directory. Every file corresponds to a subject, for example: fluids.bib, solids.bib, etc. I have a script that merges all the bib files into a file called all.bib, so, I only need to insert all.bib in my latex documents.
I update regularly the .bib files, excepting for all.bib (which is deleted and regenerated regularly by the script). Now I want to add an alias to my bashrc in order to open all the .bib files with Gedit, but I want to skip all.bib.
Is there any way to accomplish that using an alias?
Thanks in advance.
Probably better asked in unix.stackexchange.com.
However, experimenting using xed as a replacement for gedit, the following should theoretically work:
alias blech='ls !(all).bib | xargs gedit'
Modify as required for the shell you're using.

vimrc tags option specification for .git/tags files

I'm using the following method to populate a tags file in my repositories' .git directories:
https://tbaggery.com/2011/08/08/effortless-ctags-with-git.html
So, for any given git repo, I will have a .git/tags file in it. How do I configure my tags option to recursively look up from my current directories in a repo to find these tags files?
I currently have this:
set tags^=./.git/tags,*/.git/tags;~
As I understand it, that should look for ./.git/tags and if it exists use that. Else, it will go up one directory and look for .git/tags there. Failing that, it will go up two directories, and so on, stopping once it hits my home directory (~).
That seemed to work until I had another git repository in the mix. What I find is that if I have two repos at $HOME like so:
~/my_repo_2910
~/my_repo
If I am in ~/my_repo, things work fine. That is, tag resolutions happen via ~/my_repo/.git/tags. However, if I'm in a subdirectory of ~/my_repo, say ~/my_repo/dir, then running my tag commands will resolve to files in ~/my_repo_2910. I'm not sure how that is possible, but it is very dangerous for me to unexpectedly jump repos via my :tag lookups.
Clearly I'm not setting the tags option correctly. Can someone point out what I'm doing wrong.
Update
Knoble's answer works for me if I update my CentOS 7 vim to version 8 following the instructions here:
https://vi.stackexchange.com/a/21697/25433
Then his tags specification works for me fine.
With the recent fugitive updates, I had to fix my tags setup (fugitive no longer sets tags).
I have this line now:
set tags^=.git/tags;~
Note the lack of * wildcard
As sussed out in comments, there appears to be a difference between my version (8+ on macOS) and the OP version (7.4 RHEL)

Save Directory Specific history for zshell

I am trying to save my directory specific command line history. AKA, when I am in a directory called Happy, and I arrow up, I don't want to see all of my past command line history, I only want to see the history that was done in the specific Happy directory.
I also want all of this to get saved to a file so that I can access it later. Perhaps save it to files organized by directory, or by date, I don't know what would be best. Does anyone have anything like this set up?
Thank you!
It sounds like you could use this script on GitHub. Excerpt from README:
Per-Directory-History
Per directory history for zsh, as well as global history, and the
ability to toggle between them with ^G.
This is a implementation of per directory history for zsh, some
implementations of which exist in bash. It also implements
a per-directory-history-toggle-history function to change from using
the directory history to using the global history. In both cases the
history is always saved to both the global history and the directory
history, so the toggle state will not effect the saved histories.
Being able to switch between global and directory histories on the
fly is a novel feature as far as I am aware.
This is a standalone repository for the script, however it is also
included in oh-my-zsh as a plugin.

Vim editing *diff file*, updating diff ranges automatically

Suppose I generate diff of my project before commit, let say using svn. Having one diff for all files in project is a very nice way to review changes before committing them. However sometimes I wish to edit those changes without reopening each file, simple edit the diff and have it reapplied. So I have made such key map(I have setup svn diff to use unified format with fair amount of surrounding lines):
map scde :w! tmpdiff<cr>:!svn revert -R .<cr>:!patch -p0 <tmpdiff<cr>
It works, but only partially; you can edit added lines, but if you mark lines as removed or want to add another line you get some trouble since specified diff ranges do not match with actual text present in the diff. One can update them for simple changes like adding a line, however it is tedious and quickly gets complicated if you make more sophisticated changes. Is there a way to edit diff in so that range would automatically update correctly? I have found that emacs has some diff mode for this(however I have not tried it), however I was unable to find solution for my needs using vim. Maye there someone can give some suggestions?
take a look at rediff. It automatically fixes the offsets within a patch file.

Vim & ctags: Common ctags across all projects?

I'm just getting acquainted with Vim's CTags functionality - and it's damn handy.
One issue I have, though, is regenerating common tags for each project.
For example - I do a fair bit of work in rails, and like to generate ctags for the whole rails framework with
alias rctags="ctags -R `bundle show rails`/../*"
The issue is I have to do this for every rails project I start up.
So, what's the standard way to automatically access a set of tags in any vim session - ideally only if the opened file satisfies a specific condition. (Eg rails ctags preloaded for .rb files, but not .py files)
Any ideas appreciated
See :help 'tags'.
You could use, for example:
set tags+=~/.rails-tags
Which would cause ~/.rails-tags to be searched for tags.
(also, on the topic of tags: it's probably useful to suffix the tags variable with ;/. This means "search for a tags file in every parent of the working directory (ex, all the files /foo/bar/tags, /foo/tags, and /tags will be searched. For example, I use: set tags=tags;/).
Why not to use plugin Indexer that was made especially for managing the ctags in Vim?
You can define your project in ~/.indexer_files like this:
[my_rails_project]
/path/to/the/needed/directory
or even
[my_rails_project]
option:ctags_params = "--languages=Ruby"
/path/to/the/needed/directory
Then every time you opened Ruby file (i.e. *.rb or *.ruby) from the directory /path/to/the/needed/directory (with subdirs, of course), your tags will be generated automatically in background process, and when you save any file from this project, the tags will be updated automatically too (again, in the background).
So, you should not care about your tags generation, it just works.
For more information, see the article: Vim: convenient code navigation for your projects, which explains the usage of Indexer + Vimprj thoroughly.

Resources