cream-general — General discussion about Cream for Vim

Re: Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

On Tue, Apr 08, 2003 at 01:34:47AM -0400, Steve Hall wrote:
> > I created a cream-expert-keys.vim which I've dropped into the addons
> > directory. Starting in creamlite mode, all key bindings get dropped
> > then these get added back which works nicely. I've attached the
> > initial file to this message.
> 
> There might actually be two things you're trying to do. The first, is
> matching normal mode mappings to insert mode ones. This makes some
> sense for things like folding, list toggle and calendar, since they're
> mapped to the function keys and don't really have any traditional Vim
> mapping. This is what I originally thought you meant, and still feel
> it would be a good idea to extend these to normal mode, albeit in a
> separate file.
> 
> But then there is a set of modified insert mode mappings, where the
> standard Cream maps are exchanged for more traditional Vim ones, such
> as Ctrl+X/C/V and Ctrl+P. This approach drifts too far from the
> project's implied goal of using standard CUI mappings for commonality
> and accessibility across platforms.

Yes, I agree. What I hope to achieve is to enable the Cream extras, like
folding, calendar, HTML tags, in normal mode. If you were looking at the
cream-expert-keys.vim that I sent, I just copied the cream-keys.vim file
to get started; I should get rid of all references to the CUI mappings.

One problem I'm having with starting in creamlite is that my custom
keybindings in my _vimrc are getting blasted even though I call cream
first thing. Enabling this would be the best way, in my mind, to enable
custom mappings (e.g., I like the C-Ins and C-Del for cutting and
pasting) but not force such mappings into the normalmode addon.


> My original plan was to stay clear of normal mode. I'm not convinced
> that any two Vim users would *ever* agree as to the best use of its
> mappings and figured most of our audience wouldn't ever notice. ;)

For better or worse, your project has attracted (and hopefully will
continue to attract) the attention of power users who like the functions
you've grouped together but don't want to go back to a non-modal editor.
I think we can come up with a reasonable set of key mappings for
creamlite mode (I think this would be the most reasonable time to import
the mappings since expert mode only changes how one switches between
normal and insert mode).

We need to be able to come up with a way to have these remapped by a
custom _vimrc settings file or even by other add on programs. I think I
see why creamlite mode is overwriting my key bindings. You call the
Cream_behave_init function via an autocmd on VimEnter (in the
cream-autocmd.vim file). I read your note in there but don't quite
understand it. Perhaps that note explains why you did not do the
creamlite setup in cream.vim as you did with vi and vim mode (although I
see the remnants of an attempt at doing this with the elseif statement).

If there's no way around that issue then the next thing to do would be
to unmap only the keys that Cream mapped instead of unmapping all key
bindings; unmapping everything works but isn't very polite. I'd be glad
to work on this effort if needed. I think the cream-keys.vim should have
two functions--map_cream_keys and unmap_cream_keys. What do you think?

Now that I think of it, I'm wondering why we need to unmap at all. Why
can't we just avoid mapping in the beginning if creamlite is set? I used
the check you gave me and added it to the cream.vim file. This works for
avoiding setting of keys when starting up in a non-cream mode, but then
I realized that it would fail if the user decides to change the mode
after loading vim. Hmm, I guess that leads back to being more precise
about which keys get unmapped when calling creamlite, vi or vim.


> Just to be clear, I use the term "menu" to mean the word menu bars and
> "toolbar" to mean the icon bar. The previous files were technically
> menu entries, not toolbar ones. This matters only because there is
> considerable overlap between the two, and both actually would need to
> be addressed.

Yes, sorry about that confusion.


> I'm good with normal maps to the function keys, although I still think
> they make more sense in a separate file. They need to remain optional
> so that users that prefer a different behavior in normal mode don't
> get squashed.

I'm fine with that which is why I created the cream-expert-keys addon. I
think that should be cleaned up to remove the CUI stuff as discussed
above and renamed to cream-normalmode-keys to make it clear that these
are for normal mode. What do you think?


> But I still don't think we have a strategy for normal mode mappings,
> yet. For example, I have had several queries about the possibility of
> working in portions of the Vim-LaTeX suite. How would that be
> coordinated? What if there was a C-Suite and a PHP-module, too? Yikes,
> you can just start going through scripts on VimOnline and find nearly
> everyone suggests its own mappings.

Well, it seems to me that as long as the user recognizes that these
additional suites will overwrite any cream settings, there shouldn't be
a problem. The problem I forsee is when moving from a buffer with a
latex file to one with a C source. If Vim-LaTeX does not clean up after
itself, there may be remnants of its key mappings lying around. Is that
the problem you see? If you can come up with a way to add Ken Shan's
code into Cream, I think we could begin to address these issues. He has
functions that set and unset keys for different filetypes. It's rather
elegant I think.

If you add this kind of custom key-bindings for different filetypes, I
think you'd need to set the Cream key-bindings (if we're not in
creamlite), then let the addon set its own bindings. When switching,
you'd need to unset the custom bindings for the addon, reset the Cream
key-bindings (if not in creamlite), then let the new filetype set its
own bindings (if necessary).


William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Using a custom _vimrc with Cream

[Steve H. <dig...@mi...>]

William McKee wrote:
 >
 > I created a cream-expert-keys.vim which I've dropped into the addons
 > directory. Starting in creamlite mode, all key bindings get dropped
 > then these get added back which works nicely. I've attached the
 > initial file to this message.

There might actually be two things you're trying to do. The first, is
matching normal mode mappings to insert mode ones. This makes some
sense for things like folding, list toggle and calendar, since they're
mapped to the function keys and don't really have any traditional Vim
mapping. This is what I originally thought you meant, and still feel
it would be a good idea to extend these to normal mode, albeit in a
separate file.

But then there is a set of modified insert mode mappings, where the
standard Cream maps are exchanged for more traditional Vim ones, such
as Ctrl+X/C/V and Ctrl+P. This approach drifts too far from the
project's implied goal of using standard CUI mappings for commonality
and accessibility across platforms.


 > I can see where expert users are going to disagree about what keys
 > should/should not be mapped, but we can cross that bridge when we
 > get to it.

Actually, I think creating a strategy on the front end is the hardest
bridge to construct. Once you have a design, implementing the details
becomes easier.

My original plan was to stay clear of normal mode. I'm not convinced
that any two Vim users would *ever* agree as to the best use of its
mappings and figured most of our audience wouldn't ever notice. ;)

Which isn't to say the effort wouldn't be worth while. I just think
it's a project larger than the Strait of Messina, too much for me to
add into my part time hobby.


 > Is there a way to only load these mappings if creamlite (or some
 > other setting) is enabled?

You can check:

	if exists("g:CREAM_BEHAVE")
	\ && g:CREAM_BEHAVE ==? "creamlite"
		" my mappings
	endif


 > Although that's a good start for key mappings, it still does not
 > address the issue of the toolbars. I would like to see the diff I
 > sent for cream-menu-tools.vim applied to the standard files. Normal
 > mode mappings should not interfere with standard cream mode and will
 > make the toolbar usable for expert/creamlite mode users. I need to
 > make several additional modifications to get all the sensible
 > toolbars working but wanted to get your feedback before I begin
 > tackling this project.

Just to be clear, I use the term "menu" to mean the word menu bars and
"toolbar" to mean the icon bar. The previous files were technically
menu entries, not toolbar ones. This matters only because there is
considerable overlap between the two, and both actually would need to
be addressed.

I'm good with normal maps to the function keys, although I still think
they make more sense in a separate file. They need to remain optional
so that users that prefer a different behavior in normal mode don't
get squashed.

But I still don't think we have a strategy for normal mode mappings,
yet. For example, I have had several queries about the possibility of
working in portions of the Vim-LaTeX suite. How would that be
coordinated? What if there was a C-Suite and a PHP-module, too? Yikes,
you can just start going through scripts on VimOnline and find nearly
everyone suggests its own mappings.


--
Steve Hall  [ dig...@mi... ]

Try Cream... the usability project for Vim!
   http://cream.sourceforge.net

Re: Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

On Thu, Apr 03, 2003 at 11:28:04PM -0400, Steve Hall wrote:
> > I like the idea of placing my keymappings in an add-on. If any other
> > Vimmers on this list has started mapping keys to Cream functions,
> > I'd like to take a look at their file. It'd be nice to come up with
> > a file that can be included into the distribution for those of us
> > who are stuck on the old ways.
> 
> One of the reasons key theming is on the Todo (although long term) is
> because of the immense diversity in Vim users needs and styles. I'm
> not sure you'll find any common threads for normal mode needs, other
> than Vim's default. But it would be interesting if you develop
> something and get feedback... maybe there would be some common
> customizations people would like apart from the standard. At least
> with themes, you could quickly swap back and forth depending on the
> editing task at hand. I know LaTeX users enjoy the vim-latex suite,
> perhaps there could be suites for C, HTML and other popular languages.

Hmm, interesting idea. I've got some vim scripts from Ken Shan's website
at
<http://www.digitas.harvard.edu/cgi-bin/wiki/ken/VimConfigurationFiles>
which uses this same idea. You may want to check it out.

In the meantime, I created a cream-expert-keys.vim which I've dropped
into the addons directory. Starting in creamlite mode, all key bindings
get dropped then these get added back which works nicely. I've attached
the initial file to this message. I can see where expert users are going
to disagree about what keys should/should not be mapped, but we can
cross that bridge when we get to it. Is there a way to only load these
mappings if creamlite (or some other setting) is enabled?

Although that's a good start for key mappings, it still does not address
the issue of the toolbars. I would like to see the diff I sent for
cream-menu-tools.vim applied to the standard files. Normal mode mappings
should not interfere with standard cream mode and will make the toolbar
usable for expert/creamlite mode users. I need to make several
additional modifications to get all the sensible toolbars working but
wanted to get your feedback before I begin tackling this project.


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Starting in creamlite behavior

[William M. <wi...@kn...>]

On Fri, Apr 04, 2003 at 12:03:56AM -0400, Steve Hall wrote:
> I think you're right, there appears to be a bug or two in the behavior
> switching and recovery stuff. Could you try out some updates and see
> if they work better?

Yes, better. However, I'm getting an error on line 66 of
cream-showinvisibles.vim. Are you getting this?

William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Calendar problems

[William M. <wi...@kn...>]

On Fri, Apr 04, 2003 at 12:25:36AM -0400, Steve Hall wrote:
> It would be a big help if you can track down the issue. I briefly
> looked through it and couldn't find anything out of the ordinary. In
> most cases, problems like this are caused when script assumes a mode
> and then uses a keystroke with conflicting meanings depending on
> possible mode. I always try to fix third party scripts with "<Esc>" or
> "<C-l>" because insertmode, or lack thereof, breaks them.
> 
> Rather than wrapping a behavior check, better to just fix the script
> so it works both ways. Then it's more portable.

I tracked this down to the hide function in the Cream_window_hide()
function in the cream-window-buffer.vim file. The hide operation was
causing the text of the window to be lost. According to the Vim manual,
hide is a "safe" operation so that shouldn't be happening.

So, I decided to see if my custom _vimrc was causing problems by
commenting out all lines except those that read in Cream. I was still
losing the contents of the Calendar window. Finally, I renamed my
vimfiles directory (I'm running under WinNT) to vimfiles.old and it
worked! So, something which I've yet to track down in my custom Vim
plugins was interfering with Cream. I think this simple test would be
another good addition to the FAQ for folks like me who like to use
external libraries and don't always RTFM (I think you said that Cream
doesn't like other libraries; you weren't kidding!).

William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: cream speed

[Steve H. <dig...@mi...>]

jhollett wrote:
 >
 > i am using cream to edit files over a remote NFS share. vim & gvim
 > have instant response time, but using cream config is very slow. for
 > instance, it takes 5-10 seconds to scroll down a page. i've tried
 > using no swap & no backup options, but have not had any luck.
 >
 > any suggestions?

Sorry, no specific ones. One of the things on the short term ToDo is
to try and speed things up a bit generally. Probably those will help
you (when we get them done some day) but they're just theoretical
areas we want to explore, like arrays and autocommands.

You might try incapacitating various non-core modules and see which
one(s) is offending, check cream.vim for what's loading. (Note all the
add-ons are autoloaded.)

Be glad for tips, info or patches if you find something obvious.

--
Steve Hall  [ dig...@mi... ]

cream speed

[jhollett <je...@nw...>]

i am using cream to edit files over a remote NFS share. vim & gvim have 
instant response time, but using cream config is very slow. for 
instance, it takes 5-10 seconds to scroll down a page. i've tried using 
no swap & no backup options, but have not had any luck.

any suggestions?

thanks...

Re: Calendar problems

[Steve H. <dig...@mi...>]

William McKee wrote:
 > Hi Steve,
 >
 > It turns out that the problems with displaying the calendar went
 > away when I disabled the `set noinsertmode` in my custom _vimrc file
 > (that line was coming after I sourced cream's _vimrc).
 >
 > Ok, so here's an example of one of those things that could break
 > when using noinsertmode. I did a bit of debugging in the
 > calendar.vim file and tracked down the problem to the call to
 > Cream_window_setup() in the Cream_calendar function. Any ideas why
 > that function would not work in insertmode? I don't have time right
 > now to track it down.
 >
 > For now, I've commented it out and everything appears ok. If that's
 > safe, can we place a check around it to see if we're in creamlite
 > mode?

It would be a big help if you can track down the issue. I briefly
looked through it and couldn't find anything out of the ordinary. In
most cases, problems like this are caused when script assumes a mode
and then uses a keystroke with conflicting meanings depending on
possible mode. I always try to fix third party scripts with "<Esc>" or
"<C-l>" because insertmode, or lack thereof, breaks them.

Rather than wrapping a behavior check, better to just fix the script
so it works both ways. Then it's more portable.


--
Steve Hall  [ dig...@mi... ]

Try Cream... the usability project for Vim!
   http://cream.sourceforge.net

Re: Starting in creamlite behavior

[Steve H. <dig...@mi...>]

William McKee wrote:
 > Hi Steve,
 >
 > From what I can see in the cream.vim file, it does not appear that
 > creamlite startup behavior is being handled. On line 118, you source
 > the cream-conf.vim file. Following that is an if block which checks
 > for vi or vim mode but not creamlite mode. Is CREAM_BEHAVE being
 > checked somewhere else for creamlite mode or has this been
 > overlooked?

I think you're right, there appears to be a bug or two in the behavior
switching and recovery stuff. Could you try out some updates and see
if they work better?

Following is a partial alpha package of the next Cream version:

   http://cream.sf.net/cream-0-21alpha-partial.zip (340K)

Could you try the changes and see if things improve? A couple of set
up notes:

o *** BACK UP YOUR EXISTING INSTALL DIR ***
o Remove all your current cream/addons. We've done some renaming and
   structuring, and since the directory auto loads, you don't want
   duplicates.
o Make sure you copy the _vimrc and _gvimrc over your existing ones.
o This is a partial install, it won't work on it's own.
o Copy it over your existing installation.
o Note that cream-conf.vim has a change at g:cream_behave_warn
   terminology. I think the bit meanings were inverted.

This works for me on Win95 and WinXP. Hope so for you.


--
Steve Hall  [ dig...@mi... ]

Try Cream... the usability project for Vim!
   http://cream.sourceforge.net

Re: Using a custom _vimrc with Cream

[Steve H. <dig...@mi...>]

William McKee wrote:
 > Hi Steve,
 >
 > Thanks for your time and suggestions. They sound like a very good
 > idea. In fact, I'm coming around to the point where I'd prefer to
 > customize my key mappings entirely as I find that for certain
 > functions I keep hitting the default Vim keys and am getting the
 > Cream behaviors. Having spent the time to learn the vi way, I'm
 > hesitant to learn a new system which will displace standard vi
 > behaviors (and thus my ability to use vi effectively on non-Cream
 > systems).
 >
 > FWIW, I'm also coming from the Mac/Win world. I used BBEdit when on
 > a Mac; on the PC, I used Programmer's File Editor (PFE) for years
 > until I came across syntax highlighting in UltraEdit. I used it up
 > to version 6 at which point I wanted a cross-platform editor and
 > tried Emacs for a year then tried Vim. I got hooked with Vim.
 >
 > So, the capabilities you've built into Cream remind me of the
 > features and ease of a decent Windows/Mac editor. However, over the
 > past couple of years of using Vim, I've become both habituated and
 > fond of the power of modal editing. So, I've got a foot in both
 > worlds and am trying, like you, to make them both work.

Thanks for the background. I feel like there will be many more like us
in the near future: Windows/Apple users looking to drift into Linux.
But from the beginning, I've felt the "classic" vim needed to be
accessible, too. I hope you'll agree (once we get it working) the four
possible behaviors plus Expert mode are diverse enough for anyone.


 > I like the idea of placing my keymappings in an add-on. If any other
 > Vimmers on this list has started mapping keys to Cream functions,
 > I'd like to take a look at their file. It'd be nice to come up with
 > a file that can be included into the distribution for those of us
 > who are stuck on the old ways.

One of the reasons key theming is on the Todo (although long term) is
because of the immense diversity in Vim users needs and styles. I'm
not sure you'll find any common threads for normal mode needs, other
than Vim's default. But it would be interesting if you develop
something and get feedback... maybe there would be some common
customizations people would like apart from the standard. At least
with themes, you could quickly swap back and forth depending on the
editing task at hand. I know LaTeX users enjoy the vim-latex suite,
perhaps there could be suites for C, HTML and other popular languages.


--
Steve Hall  [ dig...@mi... ]

Try Cream... the usability project for Vim!
   http://cream.sourceforge.net

Calendar problems

[William M. <wi...@kn...>]

Hi Steve,

It turns out that the problems with displaying the calendar went away
when I disabled the `set noinsertmode` in my custom _vimrc file (that
line was coming after I sourced cream's _vimrc).

Ok, so here's an example of one of those things that could break when
using noinsertmode. I did a bit of debugging in the calendar.vim file
and tracked down the problem to the call to Cream_window_setup() in the
Cream_calendar function. Any ideas why that function would not work in
insertmode? I don't have time right now to track it down.

For now, I've commented it out and everything appears ok. If that's
safe, can we place a check around it to see if we're in creamlite mode?

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Starting in creamlite behavior

[William M. <wi...@kn...>]

Hi Steve,

From what I can see in the cream.vim file, it does not appear that
creamlite startup behavior is being handled. On line 118, you source the
cream-conf.vim file. Following that is an if block which checks for vi
or vim mode but not creamlite mode. Is CREAM_BEHAVE being checked
somewhere else for creamlite mode or has this been overlooked?

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

Hi Steve,

Thanks for your time and suggestions. They sound like a very good idea.
In fact, I'm coming around to the point where I'd prefer to customize my
key mappings entirely as I find that for certain functions I keep
hitting the default Vim keys and am getting the Cream behaviors. Having
spent the time to learn the vi way, I'm hesitant to learn a new system
which will displace standard vi behaviors (and thus my ability to use vi
effectively on non-Cream systems).

FWIW, I'm also coming from the Mac/Win world. I used BBEdit when on a
Mac; on the PC, I used Programmer's File Editor (PFE) for years until I
came across syntax highlighting in UltraEdit. I used it up to version 6
at which point I wanted a cross-platform editor and tried Emacs for a
year then tried Vim. I got hooked with Vim.

So, the capabilities you've built into Cream remind me of the features
and ease of a decent Windows/Mac editor. However, over the past couple
of years of using Vim, I've become both habituated and fond of the power
of modal editing. So, I've got a foot in both worlds and am trying, like
you, to make them both work.

I like the idea of placing my keymappings in an add-on. If any other
Vimmers on this list has started mapping keys to Cream functions, I'd
like to take a look at their file. It'd be nice to come up with a file
that can be included into the distribution for those of us who are stuck
on the old ways.


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Re: Using a custom _vimrc with Cream

[<dig...@mi...>]

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... ]

Re: Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

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

Re: Re: Using a custom _vimrc with Cream

[<dig...@mi...>]

[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... ]

Re: Re: First impressions of Cream

[<dig...@mi...>]

on 3/31/2003 11:07 AM William McKee said the following:
> On Mon, Mar 31, 2003 at 09:33:20AM -0500, dig...@mi... wrote:
> >
> > You might try poking around a bit more at these ideas, but off the
> > top of my head I can't think of a simpler way.
> 
> Yeah, I see what you mean. I'm starting to think I should work with
> the creamlite behavior. I don't see much documentation about this
> mode but get the impression that it leaves the toolbar and menus but
> gets rid of the key mappings which is what is giving me the most
> trouble being a habituated Vimmer. I should then be able to create
> my own mappings in the cream-user.vim, right?

Right! Most experienced Vim users that try Cream find our functions
and other environmental stuff useful, just not the key mappings. Cream
Lite removes only our mappings and :set insertmode.

--
Steve Hall  [ dig...@mi... ]

Re: Re: Using a custom _vimrc with Cream

[<dig...@mi...>]

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... ]

Re: Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

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?


> 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.


> > Reading the FAQ, I noticed a section that mentioned putting personal
> > customizations into a cream-user.vim file. Is this where all my
> > current settings in $HOME/_vimrc should go?
> 
> Yes, this file is loaded after the rest of Cream, so it's your
> opportunity to negate any behaviors you don't like, too. ;)

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.


> 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.

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.


Regards,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: First impressions of Cream

[William M. <wi...@kn...>]

On Mon, Mar 31, 2003 at 09:33:20AM -0500, dig...@mi... wrote:
> You might try poking around a bit more at these ideas, but off the top
> of my head I can't think of a simpler way.

Yeah, I see what you mean. I'm starting to think I should work with
the creamlite behavior. I don't see much documentation about this mode
but get the impression that it leaves the toolbar and menus but gets rid
of the key mappings which is what is giving me the most trouble being a
habituated Vimmer. I should then be able to create my own mappings in
the cream-user.vim, right?

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: Using a custom _vimrc with Cream

[<dig...@mi...>]

on 3/31/2003 9:05 AM William McKee said the following:
> Hi all,
> 
> I'm still getting familiar with Cream and have been sourcing the
> _vimrc file directly since Cream was not autoloading. I am using
> Cream under WinNT and used the Windows installer. It turns out that
> my custom _vimrc in my $HOME directory is getting called instead of
> the $VIM/_vimrc file (according to Vim's helpfile, only the first
> init file gets called--read ':help VIMINIT' for details).

Try to work around this by creating an environmental variable:

  set VIMINIT="source %VIM%/_vimrc"

Perhaps you'll have to hardcode %VIM%, too.


> So, I added a source $VIM/cream/_vimrc to the beginning of my
> personal _vimrc which caused Cream to load but creates strange
> results with the toolbar (no icons). Simply doing a :source
> $VIM/cream/_vimrc clears things up. It's curious that sourcing this
> file from script causes the problem but there is no problem when
> calling it after Vim has started. I also tried putting the source
> command at the end of my _vimrc but got the same results. Renaming
> my _vimrc so that the $VIM/_vimrc file loads instead of my custom
> version produces the same results.

Is the icon issue the only problem? Sounds like a runtime path issue
if so (:help runtimepath).

The Cream vimrc does all our path configuration *except* runtime path.
Check the top of cream-menu-toolbar.vim for a runtime path hack that
works around a nasty Vim 6.1 toolbar icon loading bug. We can clean
this up for Vim 6.2 when released, but not before. If you can track
down what is causing your issue, I might be able to adjust our hacks.
Maybe the VIMINIT startup will fix it, too.


> Reading the FAQ, I noticed a section that mentioned putting personal
> customizations into a cream-user.vim file. Is this where all my
> current settings in $HOME/_vimrc should go?

Yes, this file is loaded after the rest of Cream, so it's your
opportunity to negate any behaviors you don't like, too. ;)


> Seems like the FAQ should mention potential problems with custom
> _vimrc files not starting Cream. Something under Advanced Vim Users
> like the following would be helpful:
> 
> Q: I see no changes after installing Cream.
>
> A: If you have a custom _vimrc in your home directory that is being
>    loaded, the $VIM/_vimrc file which Cream installed will not be
>    used. You can add the following line to the beginning of your
>    custom _vimrc to load Cream: 
>
>       source $VIM/cream/_vimrc

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%.)

Please let us know if you are able to fix things with the VIMINIT
method above, and if this clears the icon problem on load. I'd like to
settle for a simple single solution if possible.

--
Steve Hall  [ dig...@mi... ]

Re: Re: First impressions of Cream

[<dig...@mi...>]

on 3/31/2003 8:47 AM William McKee said the following:
> On Sun, Mar 30, 2003 at 05:12:45PM -0500, Steve Hall wrote:
> 
> > Indeed, in many different ways. You might start on our FAQ page:
> 
> Ahh, thanks for the pointer. So, I now have cream-conf.vim setup to
> start me out in expert mode; however, I didn't see a way to start up
> in Normal mode as is normal Vim behavior. I'd be glad to send a
> patch if you could point me to your source where you're changing the
> mode to Insert. I tried a search but came up empty.

I'm not sure there's a good way to do this. A couple of strategies:

o Turn off :set insertmode in cream-settings.vim. But turning this off
  means none of the scripts will return to state as expected, and
  commands may not behave correctly. 
o Use an autocmd to Ctrl+L on the VimEnter. But there's no guarantee
  that other commands using the same event won't then fail. 
o Try to find the last script loaded (cream-user.vim) and place:
    execute "normal \<C-l>" 
  at it's end. But this fails for me, not sure why.

You might try poking around a bit more at these ideas, but off the top
of my head I can't think of a simpler way.

--
Steve Hall  [ dig...@mi... ]

Using a custom _vimrc with Cream

[William M. <wi...@kn...>]

Hi all,

I'm still getting familiar with Cream and have been sourcing the _vimrc
file directly since Cream was not autoloading. I am using Cream under
WinNT and used the Windows installer. It turns out that my custom _vimrc
in my $HOME directory is getting called instead of the $VIM/_vimrc file
(according to Vim's helpfile, only the first init file gets called--read
':help VIMINIT' for details).

So, I added a source $VIM/cream/_vimrc to the beginning of my personal
_vimrc which caused Cream to load but creates strange results with the
toolbar (no icons). Simply doing a :source $VIM/cream/_vimrc clears
things up. It's curious that sourcing this file from script causes the
problem but there is no problem when calling it after Vim has started. I
also tried putting the source command at the end of my _vimrc but got
the same results. Renaming my _vimrc so that the $VIM/_vimrc file loads
instead of my custom version produces the same results.

Has anyone experienced this behavior? Any suggestions besides resourcing
the $VIM/_vimrc?

Reading the FAQ, I noticed a section that mentioned putting personal
customizations into a cream-user.vim file. Is this where all my current
settings in $HOME/_vimrc should go?

Seems like the FAQ should mention potential problems with custom _vimrc
files not starting Cream. Something under Advanced Vim Users like the
following would be helpful:

Q: I see no changes after installing Cream.
A: If you have a custom _vimrc in your home directory that is being
loaded, the $VIM/_vimrc file which Cream installed will not be used. You
can add the following line to the beginning of your custom _vimrc to
load Cream:
	source $VIM/cream/_vimrc


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: First impressions of Cream

[William M. <wi...@kn...>]

On Sun, Mar 30, 2003 at 05:12:45PM -0500, Steve Hall wrote:
> Indeed, in many different ways. You might start on our FAQ page:

Ahh, thanks for the pointer. So, I now have cream-conf.vim setup to
start me out in expert mode; however, I didn't see a way to start up in
Normal mode as is normal Vim behavior. I'd be glad to send a patch if
you could point me to your source where you're changing the mode to
Insert. I tried a search but came up empty.

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: First impressions of Cream

[Steve H. <dig...@mi...>]

William McKee wrote:
 > Kudos to everyone who contributed to the Cream project. I think this
 > is a great asset to the Vim community and look forward to trying it
 > out with some of my fellow developers who are still new to modal
 > editing.
 >
 > However, having spent the last couple of years getting accustomed to
 > modal editing, I find it to be one of my favorite features of Vim
 > and indispensible in my daily work. IMO, it has improved my
 > efficiency manyfold.
 >
 > So, although I really like all the nifty features that Cream
 > provides, I am unsatisfied with having to use Ctl+L to return to
 > NORMAL mode. Is there a way to modify Cream to allow Vim powerusers
 > to have the standard Escape key functionality along with all the
 > nifty features that Cream offers?

Indeed, in many different ways. You might start on our FAQ page:

   http://cream.sourceforge.net/faq.html

Almost half way down the page, in the Advanced Vim Users section, is a
question (or two) which outlines your options. Write back if that
doesn't help.

--
Steve Hall  [ dig...@mi... ]