ardagnir / athame

Full vim for your shell (bash, zsh, gdb, python, etc)
GNU General Public License v3.0
1.62k stars 32 forks source link

Custom vimrc? #52

Open jnclayiii opened 6 years ago

jnclayiii commented 6 years ago

I'm wondering if there's an easy way to specify what vimrc athame should use.

My current vimrc and athame do not play nice. On the other hand no vimrc and athame seem to get along just fine (e.g. throwing in a ATHAME_TEST_RC=1).

I'm willing to contribute a patch if this doesn't yet exist. I would probably do so as a file list in a shell variable. For example:

export ATHAME_VIM_RC_FILES=/home/user/config/vimrcForAthame1.vim;\ /home/user/config/vimrcForAthame2.vim

In addition, I would probably add the following to the invocation of the vim process:

vim --cmd "let g:athamerc=1" -S vimbed.vim -S athamerc.... <or whatever is currently done>

Thoughts?

ardagnir commented 6 years ago

Yes, you can use ATHAME_TEST_RC. :) It's not a boolean. It currently does two things: 1) Overrides the path of the athamerc (Otherwise /etc/athamerc or ~/.athamerc is used) 2) If set, skips vimrc and all plugins (passes -u NONE to vim).

It's weird because it's really just a hack for tests, but in the short term you should be able to get what you want by using ATHAME_TEST_RC=~/.athamerc and sourcing all the vimrcs you want to use from there.

I think that if people are going to actually use this, it should probably be renamed and split into two flags, one to set the athamerc path and one to toggle "-u NONE". I don't want to support a list of RC files because file lists in env variables tend to cause problems and it's easy to source rc files from each other. (You could even have an athamerc that is solely a list of other files to source)

I also don't think I understand the second part of your comment with the g:athamerc=1, but that seems like something that you could add to your athamerc instead of adding it to the vim command.

jnclayiii commented 6 years ago

Hi!

Thank you for the response. I didn't notice that the AMATHE_TEST_RC had that functionality.

Sure, I can split it into two flags. I don't particularly want to clutter the environment with long PATH like variables either.

In regards to the g:athamerc: it's just a variable indicating to "downstream" vimrc's that the current vim instance is being used by athame. This variable doesn't need to be set by invocation if the user puts it in their athamerc file. However, if it is set during invocation then using athame becomes simpler for those loading vim plugins conditionally if athame is the invoker. It wouldn't require them to maintain an athamerc in addition to their vimrc's, and as athame becomes increasingly popular, vim plugins could count on the variable being present to enable or disable functionality if necessary. Currently though it's just a nice to have, though I would be interested to hear if you disagree (perhaps I'm missing something again!).

ardagnir commented 6 years ago

That makes sense. I like the idea of a standard global that plugins can check. Feel free to send a pr. Using g:athame_binary (like zsh/bash/gdb) probably makes more sense than g:athamerc. That way plugins can also check for specific programs running athame.

jnclayiii commented 6 years ago

Great! I'll see if I can put in a quick PR at lunch.