Repository navigation
Would like to set 'guitablabel' from ~/.vim/pack/mypackage #899
Description
First of all, huge thanks to the maintainers of MacVim for all the great work that you do! 😃
In #635, the team merged, discussed, and then reverted (via #637) a change to make the macvim base gvimrc allow users to override 'guitablabel' in other places besides their .gvimrc.
@chdiza said:
I don't see the point of this unless one is desperately trying to avoid needing to have a
~/.gvimrcin the first place. If you already have a~/.gvimrc, there is no reason not to put yourguitablabelsetting in it, and there is no reason to put that setting in~/.vimrc.
I am in fact someone who is trying to avoid needing a ~/.vimrc or ~/.gvimrc. My personal configurations are stored in a vim package (e.g. ~/.vim/pack/mypackage) that contains my settings as well as the plugins I use.
Because vim packages are loaded in step 4 of initialization, and GUI initialization happens in step 8, the MacVim base gvimrc overrides the 'guitablabel' setting from my package.
Would you reconsider making the MacVim gvimrc more permissive to allow this type of configuration? It didn't seem like there were any drawbacks mentioned in #635.
Activity
chdiza commentedon Jun 6, 2019
I'm not sure that MacVim should be catering to this extremely niche case.
At any rate, wouldn't it work if you put an autocmd somewhere in the pack, tied to
GuiEnter, that sets&guitablabel?mikesep commentedon Jun 6, 2019
It would work to use an
autocmd, though I've tried to stay away from them where possible because I've found them hard to debug.I personally don't feel that MacVim should be taking a strong stance on where I put my configuration settings. You are right that
.gvimrcexists to put GUI-specific settings, buthas("gui_running")exists so that I can do things conditionally. I think there's a good practice to putting related settings together. If I were customizing my tab line for vim for both terminal and GUI modes, I'd want to put that setting together, either in my.vimrcor a package file or a plugin or wherever. I find it cumbersome to always be comparing a.vimrcagainst a.gvimrcto see whether a setting was overridden later.Nearly everything else in MacVim's base
gvimrchas a way to be skipped/enabled:macvim_skip_colorscheme,macvim_skip_cmd_opt_movement,macvim_hig_shift_movement. Is it a burden to wrap theguitablabelline in anif existscheck? I wouldn't think it would make testing or maintenance more difficult, but I might be missing something.ychin commentedon Jun 9, 2019
I was thinking more about it, and yes while GUI configs "should" be placed in
.gvimrcit does seem odd that we would impose such a strong restriction on MacVim's side, especially Vim itself doesn't (this only happens because MacVim has its own gvimrc that it sources). I think there's a good point to be made such that MacVim should aim to be as un-intrusive a change to a Vim user as humanly possible and this override isn't respecting that. Let me see if I could go back to fix that.Only override 'guitablabel' if user hasn't already set it
ychin commentedon Jun 9, 2019
I have filed PR #903 which will fix this. This is a simple fix and while a little messy will do the right thing in respecting the user's preferences and I don't think anyone who cares will be negatively affected by this.
I'm generally a little dissatisfied with how MacVim's gvimrc works as it's an extra configuration file that gets injected into the configuration chain. I think other settings in
src/MacVim/gvimrclikeprintexprprobably should be done as a native default in the C code (this way you could do something likeset printexpr&in MacVim and it will work properly) but that's outside the scope of particular issue.mikesep commentedon Jun 10, 2019
Thanks @ychin! My quick tests of #903 look good on my machine.
MacVim Snapshot 156