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