Feature request : add a "tags" property

[aphecetche]

In the same spirit as [ the "make" property allows to set the "makeprg" for a path regexp ] I could certainly make use of a "tags" property that would set the "tags" for a given path.

The use case is to get an easy way to set the tags to be used when editing a file in a project that depends on another project.

somedir
├── AliRoot
├── alo-aliroot

in this example alo-aliroot is the project I work on, but it uses lots of code from AliRoot and so I need the tags from both projects for my workflow. Note that the tags themselves in each directory are managed just fine with vim-gutentags.

So, something like :

let g:projectionist_heuristics = {
      \   "alo-aliroot" : {
      \     "*": { "make":"alienv setenv alo-aliroot/latest -c make -C ${ALIBUILD_WORK_DIR}/BUILD/alo-aliroot-latest/alo-aliroot install" },
      \     "*": { "tags":"~/.cache/tags/user-name-alo-aliroot-tags,~/.cache/tags/user-name-aliroot-tags" },
      \   }
      \ }

The first rule with "make" is already possible and works fine, what I'm proposing here is to add one for "tags" as well.

Hope that makes sense ;-)

[tpope]

This is basically identical to the built-in 'path' support and I think it would be a reasonable addition.

[aphecetche]

Great ;-)

I assume the next step is for me to prepare a PR then (might take some time as my VimL skills are pretty poor) ?

BTW, contrary to what I stated in my original post, I seem to fail to get the proper detection of my project's top dir :

let g:projectionist_heuristics = {
      \   "alo-aliroot" : {
      \     "*": { "make":"alienv setenv alo-aliroot/latest -c make -C ${ALIBUILD_WORK_DIR}/BUILD/alo-aliroot-latest/alo-aliroot install" },
      \   }
      \ }

(was only working because I had the same "make" rule in a .projections.json file...)

There is probably something fundamental I don't understand here : how can I target a specific directory (and everything below it) ?

Thanks,

[tpope]

If it's a dir it needs a trailing slash: "alo-aliroot/".

[aphecetche]

I've actually tried with a trailing slash :

let g:projectionist_heuristics = {}
let g:projectionist_heuristics["alo-aliroot/"] = { 
            \   "*": { 
            \       "make": "alienv setenv alo-aliroot/latest -c make -C ${ALIBUILD_WORK_DIR}/BUILD/alo-aliroot-latest/alo-aliroot install",
            \     },
            \     "*.cxx": {
            \       "alternate": "{}.h",
            \     },
            \     "*.h": {
            \       "alternate": "{}.cxx",
            \     }
            \ }

But it's still not working. "Funny" thing is that the alternates seems to be working, but not the make.

If I do :echo b:projectionist on a buffer for a file in the alo-aliroot directory, here is what I get :

{'/Users/laurent/alice': [{'*.h': {'alternate': '{}.cxx'}, '*': {'make': 'alienv setenv alo-aliroot/latest -c make -C ${ALIBUILD_WORK_DIR}/BUILD/alo-aliroot-latest/alo-aliroot install'}, '*.cxx': {'alternate': '{}.h'}}], '/Users/laurent/alice/alo-aliroot': [{}]}

as if the rules were applied to the parent directory instead ?

[tpope]

Yes, you're targeting the directory's contents. If you really just want to do one arbitrary directory, a .projections.json might be more appropriate.

[aphecetche]

Might have to do that then, yes, but it's annoying : the issue with a per root directory .projections.json is how to manage it ?

I can't/don't want to pollute the project with my own rules, so I can't commit it back to upstream. So putting the rules outside the project, in my own .vimrc (which I have total version control about) seemed the right thing to do.

Will have to find another way to manage the rules then...

BTW, is there a fundamental thing that would prevent the vim-projectionist plugin to support targeting a directory (as opposed to directory's contents) ?

[tpope]

If you don't want to commit the file to the repo, add it to .git/info/exclude. Or use Fugitive's new Projectionist support and put your projections in .git/info/projections.json.

If having it in your .vimrc is a must, and you really can't come up with a Makefile&latest/ style heuristic to target it, a ProjectionistDetect autocommand can do literally anything.

[aphecetche]

First, thanks a lot for your patience. I guess the ProjectionDetect would be my preferred route, if I knew some VimL ;-)

Tried this in my .vimrc :

function! s:pjdetect(f)                                                
    if a:f =~# "\/alo-aliroot\/"                                       
        let proj = '{                                                  
                    \ "*": { "make": "zob" },                          
                    \ "*.cxx": { "alternate": "{}.zob" }               
                    \ }'                                               
        call projectionist#append(a:f,proj)                            
    endif                                                              
endfunction                                                            
                                                                       
autocmd User ProjectionistDetect call s:pjdetect(g:projectionist_file) 

If I put a echoe a:f (did not get a echom to work for some most probably trivial reason) I see the regexp looks correct and the append is called, but the make or the alternate are not associated with my files...

[tpope]

Drop the single quotes.

…

On Tue, Nov 27, 2018 at 11:28 Laurent Aphecetche ***@***.***> wrote: First, thanks a lot for your patience. I guess the ProjectionDetect would be my preferred route, if I knew some VimL ;-) Tried this in my .vimrc : function! s:pjdetect(f) if a:f =~# "\/alo-aliroot\/" let proj = '{ \ "*": { "make": "zob" }, \ "*.cxx": { "alternate": "{}.zob" } \ }' call projectionist#append(a:f,proj) endif endfunction autocmd User ProjectionistDetect call s:pjdetect(g:projectionist_file) If I put a echoe a:f (did not get a echom to work for some most probably trivial reason) I see the regexp looks correct and the append is called, but the make or the alternate are not associated with my files... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#119 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABevzkPTmlc2hmRO2wRvrg69hqVLK5ks5uzWhCgaJpZM4Yxgqf> .