Thread: Re: Re: Using a custom _vimrc with Cream
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: <dig...@mi...> - 2003-03-31 19:07:59
|
[sorry if this is a resend, ISP email is hosed ATM] on 3/31/2003 12:15 PM William McKee said the following: > On Mon, Mar 31, 2003 at 10:15:36AM -0500, dig...@mi... wrote: > > > > Try to work around this by creating an environmental variable: > > > > set VIMINIT="source %VIM%/_vimrc" > > > > Perhaps you'll have to hardcode %VIM%, too. > > That gives me an error that VIMINIT is an unknown option. Also, I've > never seen the %VIM% format before. There is no help information for > this syntax. Can you elaborate or point me to some documentation > about this usage? Heh, this is an MS-DOS batch file item. (MSDOS variables are stated "%VAR%", Vim's are "$VAR".) You need to set this environmental variable outside of Vim before it starts, so that it ignores your %HOME% setting. You can test it by simply entering it on the command line before starting gVim from the same shell. (Don't use another shell or icon link, variables aren't global across shells.) Then put it in your autoexec.bat if it works to make it global after rebooting. > > Is the icon issue the only problem? Sounds like a runtime path issue > > if so (:help runtimepath). > > You're right! I use a plugin that does a naive modification of the > runtimepath. I used your code to fix that and the icons are being > properly displayed. > > Now my problem is that Cream does not recognize the CREAM_BEHAVE > setting of creamlite in the cream-conf.vim when loading. Although I > can see the CREAM_BEHAVE is set to creamlite after loading (using > :let CREAM_BEHAVE), I have to manually go into the Settings menu and > reset the Behavior to creamlite before I get that behavior. It seems your $CREAM variable is still not being set correctly by our _vimrc. Does the setting of VIMINIT properly (above) fix this? > I see. However, it looks like sourcing the $VIM/cream/_vimrc at the > top of my $HOME/_vimrc provides the proper ordering of events so > that I can override Cream settings within my custom _vimrc. It should, you're effectively wrapping the Cream loader. > > This is a good idea, although I want to make sure we can clear up the > > icon load problem, too. Both these seem particular to the Windows > > %HOME% variable. (Our WinXP/WinNT stations here don't have this, > > default is %HOMEDRIVE%%HOMEPATH%.) > > The first one is particular to having a _vimrc in the home > directory. The second is due to poor implementation of a plugin. I'd > add a note to that FAQ to include the source line near the top of a > custom _vimrc in order to allow custom settings to override Cream > defaults. It's tough for us document setup in coordination with external files, there are a great many ways it can be foiled. I'd rather handle "customized" setups on this list. > Personally, I like this solution better than putting all my custom > settings into the cream directory which will potentially get removed > or deleted when upgrading to a new version. It also allows me to > load Cream's _vimrc directly from the cream directory which seems > much cleaner. It makes removing Cream, if anyone ever wanted to do > so, as easy as removing the source line from the custom _vimrc and > removing the cream directory. I understand your concerns. We never provide a cream-user.vim file though, so there shouldn't be any worry for it being over-written. But your solution works fine--I just don't want to add yet another level of complexity in the documentation. Cream is so fundamentally different from most other Vim scripts I can't imagine all the ways they can break it. -- Steve Hall [ dig...@mi... ] |
From: <dig...@mi...> - 2003-03-31 18:25:52
|
on 3/31/2003 12:15 PM William McKee said the following: > On Mon, Mar 31, 2003 at 10:15:36AM -0500, dig...@mi... wrote: > > > > Try to work around this by creating an environmental variable: > > > > set VIMINIT="source %VIM%/_vimrc" > > > > Perhaps you'll have to hardcode %VIM%, too. > > That gives me an error that VIMINIT is an unknown option. Also, I've > never seen the %VIM% format before. There is no help information for > this syntax. Can you elaborate or point me to some documentation > about this usage? Heh, this is an MS-DOS batch file item. (MSDOS variables are stated "%VAR%", Vim's are "$VAR".) You need to set this environmental variable outside of Vim before it starts, so that it ignores your %HOME% setting. You can test it by simply entering it on the command line before starting gVim from the same shell. (Don't use another shell or icon link, variables aren't global across shells.) Then put it in your autoexec.bat if it works to make it global after rebooting. > > Is the icon issue the only problem? Sounds like a runtime path issue > > if so (:help runtimepath). > > You're right! I use a plugin that does a naive modification of the > runtimepath. I used your code to fix that and the icons are being > properly displayed. > > Now my problem is that Cream does not recognize the CREAM_BEHAVE > setting of creamlite in the cream-conf.vim when loading. Although I > can see the CREAM_BEHAVE is set to creamlite after loading (using > :let CREAM_BEHAVE), I have to manually go into the Settings menu and > reset the Behavior to creamlite before I get that behavior. It seems your $CREAM variable is still not being set correctly by our _vimrc. Does the setting of VIMINIT properly (above) fix this? > I see. However, it looks like sourcing the $VIM/cream/_vimrc at the > top of my $HOME/_vimrc provides the proper ordering of events so > that I can override Cream settings within my custom _vimrc. It should, you're effectively wrapping the Cream loader. > > This is a good idea, although I want to make sure we can clear up the > > icon load problem, too. Both these seem particular to the Windows > > %HOME% variable. (Our WinXP/WinNT stations here don't have this, > > default is %HOMEDRIVE%%HOMEPATH%.) > > The first one is particular to having a _vimrc in the home > directory. The second is due to poor implementation of a plugin. I'd > add a note to that FAQ to include the source line near the top of a > custom _vimrc in order to allow custom settings to override Cream > defaults. It's tough for us document setup in coordination with external files, there are a great many ways it can be foiled. I'd rather handle "customized" setups on this list. > Personally, I like this solution better than putting all my custom > settings into the cream directory which will potentially get removed > or deleted when upgrading to a new version. It also allows me to > load Cream's _vimrc directly from the cream directory which seems > much cleaner. It makes removing Cream, if anyone ever wanted to do > so, as easy as removing the source line from the custom _vimrc and > removing the cream directory. I understand your concerns. We never provide a cream-user.vim file though, so there shouldn't be any worry for it being over-written. But your solution works fine--I just don't want to add yet another level of complexity in the documentation. Cream is so fundamentally different from most other Vim scripts I can't imagine all the ways they can break it. -- Steve Hall [ dig...@mi... ] |
From: <dig...@mi...> - 2003-03-31 21:45:53
|
on 3/31/2003 3:10 PM William McKee said the following: > > Speaking of mappings, I noticed in the cream-keys.vim and the menu > files that most of the Cream functionality is built only with > insertmode in mind. Would you be open to a patch that allowed > sensible operations (e.g., bookmarking and tagging, but not word > completion) to be performed from normal mode if Expert mode (or some > other Cream setting) was selected? I'm going to be modifying some of > these files in order to get that functionality for myself and would > like to see it added into the source. Not sure I understand what would change, you should find all functionality available to normal mode. Send me a patch so I can see what you mean. > I can understand that but a note about how Vim only loads the first > _vimrc it finds would be helpful for folks who have custom settings > files and are trying to get Cream working. I almost gave up on it > when nothing came up after installation. Even just a note in the > install file would be useful. IMHO, Cream is not very user-friendly > to power users right now. I agree, a warning about conflicting vimrcs would be a good idea. -- Steve Hall [ dig...@mi... ] |
From: William M. <wi...@kn...> - 2003-03-31 20:11:29
|
On Mon, Mar 31, 2003 at 02:07:55PM -0500, dig...@mi... wrote: > Heh, this is an MS-DOS batch file item. (MSDOS variables are stated > "%VAR%", Vim's are "$VAR".) You need to set this environmental > variable outside of Vim before it starts, so that it ignores your > %HOME% setting. You can test it by simply entering it on the command > line before starting gVim from the same shell. (Don't use another > shell or icon link, variables aren't global across shells.) Then put > it in your autoexec.bat if it works to make it global after rebooting. Ok, I'm with you now. So I opened a shell, set VIMINIT as instructed and launched gvim. My personal _vimrc is still loading. When I try to do a :source $VIM/_vimrc, I get errors as follows: ---------------------------------------------------------------- WARNING! First 7 characters of $VIMINIT isn't "source " $VIMINIT = "source %VIM%/_vimrc" $CREAM = "%VIM%/_vimrc" ---------------------------------------------------------------- ---------------------------------------------------------------- ERROR! Can't find loader. Cream not loaded. ---------------------------------------------------------------- Further attempts at sourcing the _vimrc only give the second error message. I checked my %VIM% settings under DOS using `set` and got the proper path. Although I'd be glad to continue to run tests for you, I'm not interested in pursuing this path any further since I do not intend to use Vim in this manner. > > Now my problem is that Cream does not recognize the CREAM_BEHAVE > > setting of creamlite in the cream-conf.vim when loading. Although I > > can see the CREAM_BEHAVE is set to creamlite after loading (using > > :let CREAM_BEHAVE), I have to manually go into the Settings menu and > > reset the Behavior to creamlite before I get that behavior. > > It seems your $CREAM variable is still not being set correctly by our > _vimrc. Does the setting of VIMINIT properly (above) fix this? No. This is the only real issue I'm continuing to see with Cream under my "alternative" configuration. I did some more digging in the source files and studied the cream-behavior.vim. I have simply added a set noim after I source Cream's _vimrc which results in the behavior that I want--I don't mind the mappings Cream uses, just can't live with the insertmode behavior ;->. Speaking of mappings, I noticed in the cream-keys.vim and the menu files that most of the Cream functionality is built only with insertmode in mind. Would you be open to a patch that allowed sensible operations (e.g., bookmarking and tagging, but not word completion) to be performed from normal mode if Expert mode (or some other Cream setting) was selected? I'm going to be modifying some of these files in order to get that functionality for myself and would like to see it added into the source. > It's tough for us document setup in coordination with external files, > there are a great many ways it can be foiled. I'd rather handle > "customized" setups on this list. I can understand that but a note about how Vim only loads the first _vimrc it finds would be helpful for folks who have custom settings files and are trying to get Cream working. I almost gave up on it when nothing came up after installation. Even just a note in the install file would be useful. IMHO, Cream is not very user-friendly to power users right now. > I understand your concerns. We never provide a cream-user.vim file > though, so there shouldn't be any worry for it being over-written. But > your solution works fine--I just don't want to add yet another level > of complexity in the documentation. Cream is so fundamentally > different from most other Vim scripts I can't imagine all the ways > they can break it. I seem to be finding several of them today <g>! If you throw enough users at it, all bugs become shallow. Thanks! William -- Knowmad Services Inc. http://www.knowmad.com |