Thread: 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: William M. <wi...@kn...> - 2003-03-31 17:16:58
|
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 |
From: <dig...@mi...> - 2003-03-31 15:16:39
|
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... ] |
From: William M. <wi...@kn...> - 2003-04-03 11:26:41
|
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 |
From: Steve H. <dig...@mi...> - 2003-04-04 03:26:59
|
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 |
From: William M. <wi...@kn...> - 2003-04-07 21:03:58
Attachments:
cream-expert-keys.zip
|
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 |
From: Steve H. <dig...@mi...> - 2003-04-08 04:35:59
|
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 |
From: William M. <wi...@kn...> - 2003-04-08 13:06:36
|
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 |
From: <dig...@mi...> - 2003-04-08 19:13:31
|
on 4/8/2003 9:04 AM William McKee said the following: > On Tue, Apr 08, 2003 at 01:34:47AM -0400, Steve Hall wrote: > > > > 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.... > > 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'd accept a patch for these. > I should get rid of all references to the CUI mappings. You mean remove their removal from the final patch, right? ;) > 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. What Cream Lite actually does is to load the full Cream, then go back and remove all mappings. This is so that someone switching from Vi or Vim behavior recovers the rest of the project. It's also necessary that mappings be removed when switching from full to Lite. A possible solution might be to simply load mappings at startup on the condition full Cream behavior is specified, but I don't know a clean and simple way to selectively remove mappings when switching away mid-session. > 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). I agree. > 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). Since Cream Lite is effectively the whole project minus only the mappings and :set insermode, I felt it was much easier to simply load the whole project and just back out the mappings. > 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? This is too hard... > 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. The reason for clearing *all* mappings was so the user can be assured of resuming full state, although I'd concede omaps and nmaps are a bit too far. If these two clears were removed, do you get the desired behavior you want? Another solution, maybe mute after the above, would be to simply ignore retaining the g:CREAM_BEHAVE state as "creamlite". Instead, you could repeat it's functionality at the top of your own scripts or make a call to Cream_behave_creamlite() before loading what you want. > > 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? Send me your final file, called "cream-keys-normal.vim" and then we can discuss how it should be loaded. We have several options, but I want to make sure I understand the behaviors first. > > 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? > > 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? Exactly. Sort of what we're discussing above with the current behaviors cleaning up correctly. Although I think my distiction is that mostly expert users are going to be utilizing mappings in normal mode. Generally, I'm not in favor of insert or visual modes being able to be remapped, with the possible exception of the function keys. Therefore it's important that normal mode mappings have a strategy for loading and unloading themselves based on the editing "theme" in use. > 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. Cream already loads filetype specific environments. While the available features are symbolic at best, the scheme is completely designed. Check cream-filetype-html.vim for an example. I'd propose these are used to load mappings, too. This file also illustrates some of the conclusions I came to early on and explains why templates and add-ons were implemented. It is very difficult to come up with a global strategy that shares concepts across filetypes. For example, in typical word processing, Ctrl+B with a selection makes that selection bold. So it holds that in an html file, the proper tags should be inserted around the selection. Same type of situation could apply to any number of mark up languages. But what about in a language such as C? No bold exists. But in structured type syntaxes other facilities might be useful that don't exist for mark up, such as function or loop structure insertion. Rather than come up with a defined keystroke for inserting a function, it is a better strategy to let the language itself suggest the phrase and let a single action complete it based on context, which is how Alt+Space completion now works. So in the end, a large framework of keystroke possibilities fails in my view because of the boundless alternatives and conflicts. One of the chief goals of Cream from the beginning was to provide a coordinated suite of editing functions, unlike the one-by-one approach Vim OnLine offers. > 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). I hope most of the discussion above resolves this. Filetype mappings should be in filetype specific profiles, using <buffer> scopes to avoid conflicts. We just need to have a good large view strategy of how keystrokes can be coordinated across filetypes/suites. All this is a bit rambly, but I hope we're communicating. (BTW, keep the list in the loop, we seem to have dropped it somewhere along the line. It helps with record keeping and I feel there are some thoughtful, non-vocal lurkers out there who might chime in should we err. :) -- Steve Hall [ dig...@mi... ] |
From: William M. <wi...@kn...> - 2003-04-09 14:39:22
|
Hi Steve, Thanks for the reply and for working with me to get Cream functional for us atypical users. I've learned more about using Vim in the past couple of weeks than I've learned in the past six months! I understand that Cream's current design is to load everything then unload undesired settings depending on the selected mode. It's in the unload that I'm experiencing problems (well, I've also got some problems with custom abbreviations but I'll address that below <g>). Presently, I've commented out the autoload function that calls the Cream_behave_creamlite() function on VimEnter as you had set in the dev files you sent last week. Instead I call it from my _vimrc after sourcing cream. This works nicely and allows me to keep my custom mappings. I think this is one of the solutions you proposed. Unfortunately, it puts more burden on the user to add the function call into their custom _vimrc. The second solution was to only load key mappings at startup if full cream mode or no mode was set. This solution has the issue of switching mid-stream. I think it would be reasonable to assume that the user who does such a switch should not expect custom mappings to be saved. A warning message that this will happen would be helpful. The final solution which I think is best, but you said is too difficult, is to unload only the key bindings which cream has made. I agree this is more effort but may be something to keep in mind should we need such a solution in the future. All of these solutions alleviate calling the Cream_behave_creamlite function each time a buffer is entered which will speed things up for the user and avoid unmapping custom mappings. Since time is not readily available, I suggest solution #2. Now, getting back to normal mode key mappings, you mentioned a patch at the beginning of your reply. After reading the rest of your reply, if you are refering to the cream-keys-normal.vim then this point may be no longer valid since I'll be submitting a completely new file. However, if this is a patch for the menus that will enable some of them to work in Normal mode, I'd be glad to submit patches. Let me know. In your explanation of current key behaviors, you mentioned that you are generally not in favor of allowing insert or visual modes to be remapped. Does this include disallowing the behavior for plug-ins as well? I'm guessing that's the case since you have wrapped them into Cream instead of allowing them to be just dropped into the users custom vimfiles directory. I'm guessing this gives you the ability to maintain the same mappings throughout the editing environment. On a side note, one thing I'm learning from working with Cream is how much effort is involved in getting several plugins to work together. It is easy to undo the work of custom settings or those of another module. I think the Cream project could come up with some good guidelines for plugin writers that will improve the usability of all these great tools. > Cream already loads filetype specific environments. While the > available features are symbolic at best, the scheme is completely > designed. Check cream-filetype-html.vim for an example. I'd propose > these are used to load mappings, too. That sounds like a sensible solution. I'd prefer that Shift-Space not pop up the HTML keywords box if I'm editing a Perl script. How about handling unmapping, though? Where should that take place? > So in the end, a large framework of keystroke possibilities fails in > my view because of the boundless alternatives and conflicts. One of > the chief goals of Cream from the beginning was to provide a > coordinated suite of editing functions, unlike the one-by-one approach > Vim OnLine offers. When you say "a large framework of keystroke possibilities fails", do you mean multiple meanings for different filetypes? Do I understand that your goal is to have a universal set of keystrokes for all filetypes? To me, that seems even more unmanageable because you end up having to add more keybindings as you add more features which is going to cause more and more overlap with addons. I'm starting to think we need to distinguish between keystroke shortcuts (like Ctl-F11 for opening the calendar) and macros which can be customized on a per-filetype and/or per-user basis. I can see how the framework for loading mappings for a specific filetype can be used to load common macros. Using a custom _vimrc, we do this on per-user basis as well. For starters, you could call the mappings in the file cream-keys the keystroke shortcuts and any mappings done by addons, like cream-filetype-html, macros. Does this make sense or add confusion? > I hope most of the discussion above resolves this. Filetype mappings > should be in filetype specific profiles, using <buffer> scopes to > avoid conflicts. We just need to have a good large view strategy of > how keystrokes can be coordinated across filetypes/suites. Well, it seems to me that what you want to have is for addons to not override any Cream-specific key mappings. That may or may not work depending on how extensive the overlap is and how willing users are to learn different keys. If we can avoid the overlap, then there is no need to unmap the addon, then remap Cream's keys. I think proceeding along the current path is fine so long as addons can be allowed to load and unload custom keybindings to facilitate their usability. Another issue we need to address is abbreviations. I think many of the addon libraries use abbreviations to add further functionality. Looking at cream-abbrev-eng, it looks like you're only using abbreviations to fix spelling typos. If that's the case, then I'd think that most addon library abbreviations should not interfere. I've discovered that Cream is removing my custom abbreviations even though I load them after loading Cream. I'll try to find out why that is happening later today or tomorrow. So, my action items are: - create the cream-keys-normal.vim - track down reason custom abbreviations are being removed Yours are: - decide which solution you think is best for handling creamlite behavior which supports custom key mappings - let me know if I can submit patches to the menu scripts that will allow "sensible" menu items to be used from normal mode - offer solution for how to handle unmapping keys that have been mapped by an addon tool Thanks, William -- Knowmad Services Inc. http://www.knowmad.com |
From: Steve H. <dig...@mi...> - 2003-04-10 07:54:20
|
William McKee wrote: > Hi Steve, > > Thanks for the reply and for working with me to get Cream functional > for us atypical users. I've learned more about using Vim in the past > couple of weeks than I've learned in the past six months! Do you subscribe to any of the Vim lists? The very brilliant people there pose great solutions to a lot of problems. It's good to lurk on just for the education. > I understand that Cream's current design is to load everything then > unload undesired settings depending on the selected mode. It's in > the unload that I'm experiencing problems (well, I've also got some > problems with custom abbreviations but I'll address that below <g>). > > [ three workaround solutions ] > I hope that these workarounds aren't required in the new Cream version (0.21). You will find that cream-user is now loaded last by autocmd which means it should properly take precedence. On top of the mode restoration bugs that I think we fixed, custom mappings in cream-user should be effective. Please let me know if not. > Now, getting back to normal mode key mappings, you mentioned a patch > at the beginning of your reply. After reading the rest of your > reply, if you are refering to the cream-keys-normal.vim then this > point may be no longer valid since I'll be submitting a completely > new file. However, if this is a patch for the menus that will enable > some of them to work in Normal mode, I'd be glad to submit patches. > Let me know. Sorry, "patch" was just a loose term to mean any additions, fixes or changes to Cream. Separate files please for this subject. > In your explanation of current key behaviors, you mentioned that you > are generally not in favor of allowing insert or visual modes to be > remapped. Does this include disallowing the behavior for plug-ins as > well? I'm guessing that's the case since you have wrapped them into > Cream instead of allowing them to be just dropped into the users > custom vimfiles directory. I'm guessing this gives you the ability > to maintain the same mappings throughout the editing environment. The coordination goes far beyond mappings. Rather it's a strategy of providing menus, user-defined mappings (through menus) retained across sessions, use of library functions, etc. > On a side note, one thing I'm learning from working with Cream is > how much effort is involved in getting several plugins to work > together. It is easy to undo the work of custom settings or those of > another module. I think the Cream project could come up with some > good guidelines for plugin writers that will improve the usability > of all these great tools. Indeed! Generally there are no standards and there is no attempt at coordination. The Vim Online site is thick with good ideas, but they need refinement, polishing and a usable front end in order for the average user to be productive with them out of the box. This project started with my realization that Vim could be made to do anything. Cream is now one example of a Vim suite of scripts that has a higher purpose than any particular editing action or routine. > > Cream already loads filetype specific environments. While the > > available features are symbolic at best, the scheme is completely > > designed. Check cream-filetype-html.vim for an example. I'd > > propose these are used to load mappings, too. > > That sounds like a sensible solution. I'd prefer that Shift-Space > not pop up the HTML keywords box if I'm editing a Perl script. The List feature definitely needs to be conditioned by filetype some how, much as the templates are. While I sometimes accidentally activate it, Shift+Space is a good map since it relates to some of the other completion features, like completion (Ctrl+Space, Ctrl+Shift+Space) and templates (Alt+Space). > How about handling unmapping, though? Where should that take place? I hope this is resolved by the fixes and adjustments in the new Cream so that cream-user can control. > > So in the end, a large framework of keystroke possibilities fails > > in my view because of the boundless alternatives and conflicts. > > When you say "a large framework of keystroke possibilities fails", > do you mean multiple meanings for different filetypes? Do I > understand that your goal is to have a universal set of keystrokes > for all filetypes? To me, that seems even more unmanageable because > you end up having to add more keybindings as you add more features > which is going to cause more and more overlap with addons. I think Cream solves the problem of keystrokes by keeping what mappings we have generic enough that they can be "universal" in most situations. The goal has always been to use the Ctrl/Alt+{letter} and Function keys for these types of things. But there aren't that many. Vim's approach, on the other hand, is to use key combinations and a command line, effectively allowing any number of keystrokes, sometimes followed by Enter. But the real problem with this strategy to me, is remembering all those commands. It might also help to say here that my real job is with an architect, using AutoCAD which probably rivals Vim for number of available keystrokes and commandline entries. In both applications, the typical user can remember only about 50 with several years of work... the rest are picked out of menus and toolbars. So I guess I'm trying to simplify. "Universal keystrokes" to me just means that similar broad strokes are logically related, across conditions. (Just as in the Space example above, and the Ctrl+B bold discussed previously.) Everything else can be performed via menus, lists, addons, templates, navigation, etc. > I'm starting to think we need to distinguish between keystroke > shortcuts (like Ctl-F11 for opening the calendar) and macros which > can be customized on a per-filetype and/or per-user basis. I can see > how the framework for loading mappings for a specific filetype can > be used to load common macros. Using a custom _vimrc, we do this on > per-user basis as well. For starters, you could call the mappings in > the file cream-keys the keystroke shortcuts and any mappings done by > addons, like cream-filetype-html, macros. Does this make sense or > add confusion? To me a macro is a collection or recording of a set of keystrokes or commands. F8 is reserved for a whole host of recordings, currently disabled but schematically functional in cream-macros. These will be user-defined collections of Cream commands, almost a program of sorts, but perhaps even able to be exchanged and distributed. To me, addons are a way to keep commands proper out of the normal menu structure. They're not intended to have keystrokes attached to them. They comprise actions used less frequently, in maybe more specific applications. The thought is that each addon is an action, so that a single user-defined F12 keystroke combination relates to each one. We don't want them to get complicated or a mouse pick or F12 key won't work. This filtering of commands into addons is almost an arbitrary process. My criteria is ill-defined and mostly subjective. The definition of special obviously relates to the user, but I hope these are mostly "cool things most other text editors can't do." If you'd expect a feature to be in a menu it should be... the rest are addons. For example, Sort looks suspiciously like a command for the Format menu. But it's probably not going to be used much by most users, although someone may find a way to use it hourly, in which case they could want a map for it. I'm not in favor of everything and anything being able to be remapped. My AutoCAD experience teaches me a good standard is better than customization. (By being a poor example!) A little benevolent dictatorship goes a long way. :) > > I hope most of the discussion above resolves this. Filetype > > mappings should be in filetype specific profiles, using <buffer> > > scopes to avoid conflicts. We just need to have a good large view > > strategy of how keystrokes can be coordinated across > > filetypes/suites. > > Well, it seems to me that what you want to have is for addons to not > override any Cream-specific key mappings. That may or may not work > depending on how extensive the overlap is and how willing users are > to learn different keys. If we can avoid the overlap, then there is > no need to unmap the addon, then remap Cream's keys. I think > proceeding along the current path is fine so long as addons can be > allowed to load and unload custom keybindings to facilitate their > usability. I don't think I'm for this. It almost sounds to me like you want to create what I call a "module", a full collection of functionalities related to some specific editing task. I'd need to see what you're planning to understand. > Another issue we need to address is abbreviations. I think many of > the addon libraries use abbreviations to add further functionality. > Looking at cream-abbrev-eng, it looks like you're only using > abbreviations to fix spelling typos. If that's the case, then I'd > think that most addon library abbreviations should not interfere. Addons probably shouldn't use abbreviations. I can't think of a reason to use them where a template completion isn't a better choice, simply because of the filetype flexibility already built into it and the user-controlled activation of them. Have you checked out the template completion code? > I've discovered that Cream is removing my custom abbreviations even > though I load them after loading Cream. I'll try to find out why > that is happening later today or tomorrow. As long as you run them from cream-user they should now work. Realize that loading order doesn't necessarily affect activation order. We use autocommands for numerous things because Vim doesn't make global variables available until very late in the load process, after all the scripts are in memory. It isn't until after this point that the GUI is able to be manipulated along with things like windows, fonts, etc. We then come back and set all the preferences based on the saved state. I'd guess your settings are being over-ridden by autocommand initializations, not load orders. See if it's fixed. > So, my action items are: > - create the cream-keys-normal.vim > - track down reason custom abbreviations are being removed => Solved by bug fixes, adjustments in latest version. > Yours are: > - decide which solution you think is best for handling creamlite > behavior which supports custom key mappings => Solved by bug fixes, adjustments in latest version. > - let me know if I can submit patches to the menu scripts that will > allow "sensible" menu items to be used from normal mode => Yes, although my use of "patches" was technically incorrect, we want them in their own file. > - offer solution for how to handle unmapping keys that have been > mapped by an addon tool => Still not clear what an addon would map. Need an example. -- Steve Hall [ dig...@mi... ] Try Cream... the usability project for Vim! http://cream.sourceforge.net |
From: William M. <wi...@kn...> - 2003-04-10 16:10:51
|
On Thu, Apr 10, 2003 at 04:49:36AM -0400, Steve Hall wrote: > Do you subscribe to any of the Vim lists? The very brilliant people > there pose great solutions to a lot of problems. It's good to lurk on > just for the education. Thanks for the suggestion. I'm so behind on my current mailing lists that adding another one is not going to be a good thing right now <g>. > I hope that these workarounds aren't required in the new Cream version > (0.21). You will find that cream-user is now loaded last by autocmd > which means it should properly take precedence. On top of the mode > restoration bugs that I think we fixed, custom mappings in cream-user > should be effective. Please let me know if not. Ok, placing my mappings and abbrev's into a cream-user.vim file is now working. However, it's not my favorite solution because it places an extra burden on the processor to do mappings and unmappings each time I change buffers (which will cause a serious performance issue on older systems or on lightweight systems running WinCE--yes I use Vim on my PDA). I've also already voiced my dislike of having custom mappings inside the cream/ directory which will get replaced by future editions. Finally, this solution does not allow individual users to maintain their own mappings when Cream is installed on a site-wide basis as I have done on my Linux server. All of the solutions that I suggested previously allow custom mappings in the personal vimrc while also removing the extra calls to the Cream_behave_init routines. Are you still convinced that using a cream-user.vim is the right approach? Do you use it? Does anyone else on this list use this file for custom settings? It seems not so difficult to support the existing standard of allowing personal configurations to be in the vimrc file. > The coordination goes far beyond mappings. Rather it's a strategy of > providing menus, user-defined mappings (through menus) retained across > sessions, use of library functions, etc. In other words, an universally consistent user interface? > Indeed! Generally there are no standards and there is no attempt at > coordination. The Vim Online site is thick with good ideas, but they > need refinement, polishing and a usable front end in order for the > average user to be productive with them out of the box. This project > started with my realization that Vim could be made to do anything. > Cream is now one example of a Vim suite of scripts that has a higher > purpose than any particular editing action or routine. And that is why I am so intrigued by the project and have spent so many hours trying to understand it and mold it to fit my needs as a power user. I think with some further refinement, Cream can become as effective for modal users as it can for insertmode users. > The List feature definitely needs to be conditioned by filetype some > how, much as the templates are. While I sometimes accidentally > activate it, Shift+Space is a good map since it relates to some of the > other completion features, like completion (Ctrl+Space, > Ctrl+Shift+Space) and templates (Alt+Space). Until I can better train my fingers to be more nimble, I've had to unmap it as I tend to continue holding the shift while typing a space. A bad habit <g>. > > How about handling unmapping, though? Where should that take place? > > I hope this is resolved by the fixes and adjustments in the new Cream > so that cream-user can control. Hmm, that's not quite what I meant. I was talking about addons which change key mappings being unmapped when no longer editing the specified filetype or being remapped (in the example you gave of Ctl-B) for the new filetype being handled. Remapping is already handled but unmapping seems more tricky. For example, if F5 compiles a Perl script for me, I wouldn't want Vim to try to compile the file if I accidentally hit F5 while editing an html file. It'd be best if the perl add-on (or whatever it's going to be called) unmaps the F5 key as I leave the buffer. > I think Cream solves the problem of keystrokes by keeping what > mappings we have generic enough that they can be "universal" in most > situations. The goal has always been to use the Ctrl/Alt+{letter} and > Function keys for these types of things. But there aren't that many. I'm starting to see what you mean. However, now that you're introducing the idea of filetypes, you've kinda opened up the possibility of different mappings meaning different things for different filetypes. I'm hearing from you that you're hesistant to allow this. Personally, I think this is one of the great strengths of Vim but needs to be used in moderation. By wrapping common modules in addons, cream can provide that moderation. In most cases, it sounds like you're going to have the addons be accessed via the menu unless there are functions which match the "universal keys" (such as Ctl-B). Are we coming any closer to the same wavelength? > To me a macro is a collection or recording of a set of keystrokes or > commands. F8 is reserved for a whole host of recordings, currently > disabled but schematically functional in cream-macros. These will be > user-defined collections of Cream commands, almost a program of sorts, > but perhaps even able to be exchanged and distributed. Yeah, this makes more sense than my attempt at differentiating between the universal keystrokes and the keystrokes added by addons. > To me, addons are a way to keep commands proper out of the normal menu > structure. They're not intended to have keystrokes attached to them. That's cool, but it'd be nice if you could allow the user to attach keystrokes via their personal vimrc file (using autocmd's or direct mappings if they desired). > This filtering of commands into addons is almost an arbitrary process. > My criteria is ill-defined and mostly subjective. The definition of > special obviously relates to the user, but I hope these are mostly > "cool things most other text editors can't do." If you'd expect a > feature to be in a menu it should be... the rest are addons. While agreeably arbitrary, this makes sense to me. I'm all for a benevolent dictatorship, esp. for newbies. I think that's what makes M$ software so appealing to the masses. However, benevolence lies in allowing the user to customize to the full extent of the application in question. With Vim, this is massive and requires solving some large design issues which is why we're having this exhaustive conversation about how to be firm with new users but allow improvisation by experts. I think that this may be where we have a difference of opinion based on your statement that "I'm not in favor of everything and anything being able to be remapped." Hopefully, even though you're not in favor of it, you'll allow that ability in an easy to use means as I have been trying to accomplish. > I don't think I'm for this. It almost sounds to me like you want to > create what I call a "module", a full collection of functionalities > related to some specific editing task. I'd need to see what you're > planning to understand. Hmm, I've been trying to define this functionality above. Basically, I think it would be beneficial to allow cream addons, esp. those that perform special actions like remapping Ctl-B to do something different in an html file, to map keys. However, these should be unmapped when going to a difference buffer, such as one with a C source file. It sounds like you're pretty firmly against allowing any other keys into the "univeral keystrokes" except as defined by the user. That's ok by me so long as I can put these settings into my personal vimrc file <g>. > > Another issue we need to address is abbreviations. I think many of > > the addon libraries use abbreviations to add further functionality. > > Looking at cream-abbrev-eng, it looks like you're only using > > abbreviations to fix spelling typos. If that's the case, then I'd > > think that most addon library abbreviations should not interfere. > > Addons probably shouldn't use abbreviations. I can't think of a reason > to use them where a template completion isn't a better choice, simply > because of the filetype flexibility already built into it and the > user-controlled activation of them. Have you checked out the template > completion code? No, I haven't yet. Going to read.... Ok, that seems like a good solution to abbreviations. I don't really use that feature much anyways. Is there a way to add custom completions to the list? > I'd guess your settings are being over-ridden by autocommand > initializations, not load orders. See if it's fixed. Indeed this is what is happening. I conceptually understand the problem you've overcome using autocommands, however in some cases, like key mappings, I can see a solution that doesn't entail having to use autocommands. That seems like a better way for all the reasons I listed above. I look forward to your feedback, William -- Knowmad Services Inc. http://www.knowmad.com |
From: Steve H. <dig...@mi...> - 2003-04-10 17:28:22
|
William McKee wrote: > On Thu, Apr 10, 2003 at 04:49:36AM -0400, Steve Hall wrote: > > > I hope that these workarounds aren't required in the new Cream > > version (0.21). You will find that cream-user is now loaded last > > by autocmd which means it should properly take precedence. On top > > of the mode restoration bugs that I think we fixed, custom > > mappings in cream-user should be effective. Please let me know if > > not. > > Ok, placing my mappings and abbrev's into a cream-user.vim file is > now working. However, it's not my favorite solution because it > places an extra burden on the processor to do mappings and > unmappings each time I change buffers (which will cause a serious > performance issue on older systems or on lightweight systems running > WinCE--yes I use Vim on my PDA). The autocmd event is VimEnter, it only happens once. > I've also already voiced my dislike of having custom mappings inside > the cream/ directory which will get replaced by future editions. cream-user is not shipped. It won't be overwritten. > Finally, this solution does not allow individual users to maintain > their own mappings when Cream is installed on a site-wide basis as I > have done on my Linux server. Good point, perhaps a check of %HOME%/.cream/cream-user.vim would be in order? Or maybe a $CREAM_USER? Gotta think about how that would work on Windows, too. > All of the solutions that I suggested previously allow custom > mappings in the personal vimrc while also removing the extra calls > to the Cream_behave_init routines. Are you still convinced that > using a cream-user.vim is the right approach? Do you use it? Does > anyone else on this list use this file for custom settings? It seems > not so difficult to support the existing standard of allowing > personal configurations to be in the vimrc file. I think a customized vimrc with Cream is the wrong way to go. There's just too much going on from vimrc to cream-user that can be broken. > > The coordination goes far beyond mappings. Rather it's a strategy > > of providing menus, user-defined mappings (through menus) retained > > across sessions, use of library functions, etc. > > In other words, an universally consistent user interface? Maybe. It's a single place to go to for non-standard commands. > I think with some further refinement, Cream can become as effective > for modal users as it can for insertmode users. I still think with some parallel normal mode mappings, Expert Mode might be all you need. > > The List feature definitely needs to be conditioned by filetype > > some how, much as the templates are. While I sometimes > > accidentally activate it, Shift+Space is a good map since it > > relates to some of the other completion features, like completion > > (Ctrl+Space, Ctrl+Shift+Space) and templates (Alt+Space). > > Until I can better train my fingers to be more nimble, I've had to > unmap it as I tend to continue holding the shift while typing a > space. A bad habit <g>. Once conditioned to filetype, it won't be so obnoxious. Besides, you should find that simply another repeat of the Space key closes it. > > > How about handling unmapping, though? Where should that take > > > place? > > > > I hope this is resolved by the fixes and adjustments in the new > > Cream so that cream-user can control. > > Hmm, that's not quite what I meant. I was talking about addons which > change key mappings being unmapped when no longer editing the > specified filetype or being remapped (in the example you gave of > Ctl-B) for the new filetype being handled. Remapping is already > handled but unmapping seems more tricky. For example, if F5 compiles > a Perl script for me, I wouldn't want Vim to try to compile the file > if I accidentally hit F5 while editing an html file. It'd be best if > the perl add-on (or whatever it's going to be called) unmaps the F5 > key as I leave the buffer. AHH! A real example! I'd suggest you create an addon to do this, make generic global variables to hold your command, path/file, alternative parameters, etc. Then you can add some combination of F12 as it's key or do Alt+T,A,mouse pick. And others will be able to make use of it, too. > > I think Cream solves the problem of keystrokes by keeping what > > mappings we have generic enough that they can be "universal" in > > most situations. The goal has always been to use the > > Ctrl/Alt+{letter} and Function keys for these types of things. But > > there aren't that many. > > I'm starting to see what you mean. However, now that you're > introducing the idea of filetypes, you've kinda opened up the > possibility of different mappings meaning different things for > different filetypes. I'm hearing from you that you're hesistant to > allow this. Personally, I think this is one of the great strengths > of Vim but needs to be used in moderation. By wrapping common > modules in addons, cream can provide that moderation. In most cases, > it sounds like you're going to have the addons be accessed via the > menu unless there are functions which match the "universal keys" > (such as Ctl-B). Are we coming any closer to the same wavelength? Yes, I think so. Filetype conditioning has to happen very smoothly or it will seem clunky. Syntax highlighting is a good example of this working well. What I don't want is for the user to have a million key combinations to remember, based on his particular filetype, which he may not even know or realize. By making an action active rather than passive, it is more easily controled and understood by the user. My bet is the average user can't find more than 8 custom items he needs mapped as long as it's also available from an easy-to reach menu. I certainly haven't, and I write vim, php, html, css, lisp, javascript, nsis, and bat every week. > > To me, addons are a way to keep commands proper out of the normal > > menu structure. They're not intended to have keystrokes attached > > to them. > > That's cool, but it'd be nice if you could allow the user to attach > keystrokes via their personal vimrc file (using autocmd's or direct > mappings if they desired). Heh, it's certainly allowed, we just can't support it. ;) > > This filtering of commands into addons is almost an arbitrary > > process. My criteria is ill-defined and mostly subjective. The > > definition of special obviously relates to the user, but I hope > > these are mostly "cool things most other text editors can't do." > > If you'd expect a feature to be in a menu it should be... the rest > > are addons. > > However, benevolence lies in allowing the user to customize to the > full extent of the application in question. I disagree with this. Customization is a privelidge entitled by open source, for those willing to learn how to code. But from a user's perspective, capability is what's important, not customization. If an application performs as expected no customization is necessary. This is one of the main tenants behind Apple software (and more recently, GNOME). It JustWorks. The goal with Cream is to give the user everything he needs in intuitive fashion so no customization is necessary. (But still possible, the script is open. ;) > With Vim, this is massive and requires solving some large design > issues which is why we're having this exhaustive conversation about > how to be firm with new users but allow improvisation by experts. I > think that this may be where we have a difference of opinion based > on your statement that "I'm not in favor of everything and anything > being able to be remapped." Hopefully, even though you're not in > favor of it, you'll allow that ability in an easy to use means as I > have been trying to accomplish. o cream-user should now be useful for adding custom mappings. o If you want to use nmaps these in combination with Cream Lite, comment out lines 102-103 in cream-behavior. (This will be default in the next version.) o You are going to provide us with duplicate mappings for normal mode where possible. o Customization can easily occur by experts, just by understanding a little of the project and knowing how to write Vim script. I'm sure we could have easily added all the normal mode mappings in the time we've spent on this discussion! o Customizations are supported via addons. Cream will automatcially load and menu-ize them, and also retain a user-defined mapping of one of eight F12 key combinations. o We are always willing to entertain new additions to the project in modules that get loaded on startup, as long as they conform to the project's goals and strategies, and function as expected. > > I don't think I'm for this. It almost sounds to me like you want > > to create what I call a "module", a full collection of > > functionalities related to some specific editing task. I'd need to > > see what you're planning to understand. > > Hmm, I've been trying to define this functionality above. Basically, > I think it would be beneficial to allow cream addons, esp. those > that perform special actions like remapping Ctl-B to do something > different in an html file, to map keys. However, these should be > unmapped when going to a difference buffer, such as one with a C > source file. It sounds like you're pretty firmly against allowing > any other keys into the "univeral keystrokes" except as defined by > the user. That's ok by me so long as I can put these settings into > my personal vimrc file <g>. I'd feel better about them in the cream-user. Why not just put a line there sourcing your scripts, in your $HOME somewhere? Then you don't need to worry about your vimrc getting overwritten on the next upgrade (Cream or Vim). > Is there a way to add custom completions to the list? Not unless there are errors. Mine are in cream-user. > > I'd guess your settings are being over-ridden by autocommand > > initializations, not load orders. See if it's fixed. > > Indeed this is what is happening. I conceptually understand the > problem you've overcome using autocommands, however in some cases, > like key mappings, I can see a solution that doesn't entail having > to use autocommands. That seems like a better way for all the > reasons I listed above. Since autocommands are required, they do add a level of complexity. See if commenting the ounmap and nunmap lines in cream-behavior help in combination with cream-user customizations. -- Steve Hall [ dig...@mi... ] Try Cream... the usability project for Vim! http://cream.sourceforge.net |
From: William M. <wi...@kn...> - 2003-04-10 19:04:37
|
On Thu, Apr 10, 2003 at 02:29:25PM -0400, Steve Hall wrote: > The autocmd event is VimEnter, it only happens once. Doh! I'm thinking BufEnter. Still, though it causes problems with any mappings in my personal vimrc. > > I've also already voiced my dislike of having custom mappings inside > > the cream/ directory which will get replaced by future editions. > > cream-user is not shipped. It won't be overwritten. But if someone deletes the old cream directory in order to install the new and forgets to save cream-user.vim, bye-bye personal settings. > > All of the solutions that I suggested previously allow custom > > mappings in the personal vimrc while also removing the extra calls > > to the Cream_behave_init routines. Are you still convinced that > > using a cream-user.vim is the right approach? Do you use it? Does > > anyone else on this list use this file for custom settings? It seems > > not so difficult to support the existing standard of allowing > > personal configurations to be in the vimrc file. > > I think a customized vimrc with Cream is the wrong way to go. There's > just too much going on from vimrc to cream-user that can be broken. In my limited testing on both Linux and WinNT, I've had no problems with using a custom vimrc and cream besides the overwriting of the keymappings which I can work around and the abbreviations for which I can also prob. find a workaround. I understand that you don't want to introduce more headaches by having to support custom vimrc files, but it seems like this is a perfectly good system for handling personal settings that you are tossing out for something that is more complicated (i.e., the cream-user.vim stuff which apparently noone is using based on the lack of feedback to my questions about it). I'm not suggesting that Cream should have to support all possible combinations of personal vimrc settings, but it does a pretty good job of handling my vimrc. So, it seems like we're probably at an impasse in regards to our opinions about this. Is there a way that we can both have what we want? The main problem I'm having with using my custom vimrc is the VimEnter autocommand. There a way to disable that if a flag is set in the cream-conf.vim; may I send you a patch? (but see below first) > > I think with some further refinement, Cream can become as effective > > for modal users as it can for insertmode users. > > I still think with some parallel normal mode mappings, Expert Mode > might be all you need. Perhaps so. When I finish building the cream-keys-normal mappings, I'll give that a try. > Once conditioned to filetype, it won't be so obnoxious. Besides, you > should find that simply another repeat of the Space key closes it. Ohh, I didn't realize that. Cool. > AHH! A real example! I'd suggest you create an addon to do this, make > generic global variables to hold your command, path/file, alternative > parameters, etc. Then you can add some combination of F12 as it's key > or do Alt+T,A,mouse pick. And others will be able to make use of it, > too. Sorry I was so slow to be more specific. Concrete examples really help, eh? I'm not sure I follow you on the suggestion. Is this documented in a step-by-step manner somewhere? Are there any add-ons I can look at to see what you are talking about? > Yes, I think so. Filetype conditioning has to happen very smoothly or > it will seem clunky. Syntax highlighting is a good example of this > working well. What I don't want is for the user to have a million key > combinations to remember, based on his particular filetype, which he > may not even know or realize. By making an action active rather than > passive, it is more easily controled and understood by the user. My > bet is the average user can't find more than 8 custom items he needs > mapped as long as it's also available from an easy-to reach menu. I > certainly haven't, and I write vim, php, html, css, lisp, javascript, > nsis, and bat every week. Ok, I'm in full agreement with you on this matter. > > That's cool, but it'd be nice if you could allow the user to attach > > keystrokes via their personal vimrc file (using autocmd's or direct > > mappings if they desired). > > Heh, it's certainly allowed, we just can't support it. ;) Yeah, I guess you're not really overriding any autocommands in Cream are you? > I disagree with this. Customization is a privelidge entitled by open > source, for those willing to learn how to code. But from a user's > perspective, capability is what's important, not customization. If an > application performs as expected no customization is necessary. This > is one of the main tenants behind Apple software (and more recently, > GNOME). It JustWorks. The goal with Cream is to give the user > everything he needs in intuitive fashion so no customization is > necessary. (But still possible, the script is open. ;) I think we're saying the same thing with different words. I agree with the benevolent dictator stuff that it should just work with lots of the great bells and whistles without any customization required. It sounds like we're both saying that customization should be allowed. > > With Vim, this is massive and requires solving some large design > > issues which is why we're having this exhaustive conversation about > > how to be firm with new users but allow improvisation by experts. I > > think that this may be where we have a difference of opinion based > > on your statement that "I'm not in favor of everything and anything > > being able to be remapped." Hopefully, even though you're not in > > favor of it, you'll allow that ability in an easy to use means as I > > have been trying to accomplish. > > o cream-user should now be useful for adding custom mappings. > o If you want to use nmaps these in combination with Cream Lite, > comment out lines 102-103 in cream-behavior. (This will be default > in the next version.) > o You are going to provide us with duplicate mappings for normal mode > where possible. > o Customization can easily occur by experts, just by understanding a > little of the project and knowing how to write Vim script. I'm sure > we could have easily added all the normal mode mappings in the time > we've spent on this discussion! > o Customizations are supported via addons. Cream will automatcially > load and menu-ize them, and also retain a user-defined mapping of > one of eight F12 key combinations. > o We are always willing to entertain new additions to the project in > modules that get loaded on startup, as long as they conform to the > project's goals and strategies, and function as expected. > > > > > I don't think I'm for this. It almost sounds to me like you want > > > to create what I call a "module", a full collection of > > > functionalities related to some specific editing task. I'd need to > > > see what you're planning to understand. > > > > Hmm, I've been trying to define this functionality above. Basically, > > I think it would be beneficial to allow cream addons, esp. those > > that perform special actions like remapping Ctl-B to do something > > different in an html file, to map keys. However, these should be > > unmapped when going to a difference buffer, such as one with a C > > source file. It sounds like you're pretty firmly against allowing > > any other keys into the "univeral keystrokes" except as defined by > > the user. That's ok by me so long as I can put these settings into > > my personal vimrc file <g>. > > I'd feel better about them in the cream-user. Why not just put a line > there sourcing your scripts, in your $HOME somewhere? Then you don't > need to worry about your vimrc getting overwritten on the next upgrade > (Cream or Vim). Nice suggestion, but Vim will only source a single vimrc which brings us full circle to where this long thread began. If I have a custom vimrc, the _vimrc that Cream puts into the $VIM directory does not get loaded, thus no Cream and no happiness. Therefore, using a custom vimrc, I have to source Cream's _vimrc directly which I like because it lets me easily set whether Cream is loaded or not OR I have to replace my custom vimrc with Cream's which feels intrusive and makes me think Cream is too dictatorial for my liking. If I keep my custom vimrc, your suggestion of having cream-user source my custom vimrc results in lots of errors due to resourcing cream again if I use my custom vimrc. So, my point of view, being an existing Vim user, is that Cream is difficult to install and use because it doesn't play well with a custom vimrc and overrides all my existing key mappings unless I copy these all into a new file called cream-user.vim which does not handle per-user customizations on a multi-user system. You are comfortable with the current settings and probably don't even use cream-user.vim because you have final say in how this system is designed which meets your exact needs (the benefits of being the dictator). New users who have never used Vim won't even understand what we're talking about. So, this is strictly a matter of making Cream usable for existing Vim users. I can keep commenting out that VimEnter autocommand in cream-autocmd.vim each time a new release comes out but would like to see a long-term solution that addresses the above problems in a way that is nice to those of us who have taken the time to build-up an arsenal of custom key mappings. > > Is there a way to add custom completions to the list? > > Not unless there are errors. Mine are in cream-user. So you do use cream-user after all. I don't understand your response to my question. Could you post some examples of your custom completions that you have in your cream-user file? > Since autocommands are required, they do add a level of complexity. > See if commenting the ounmap and nunmap lines in > cream-behavior help in combination with cream-user customizations. That may be all that is needed since looking at my custom vimrc, I don't see many insertmode keymappings to speak of. This technique should allow me to keep most of my custom key mappings in my custom vimrc and not lose them when switching into the creamlite mode. I can probably live with that solution. It certainly feels good to have some resolution over this issue. I agree we could have done a number of things in the time we've had this discussion, but I for one have learned a lot and come to a better understanding of how Cream is designed and implemented. I hope it hasn't been a complete waste of your effort. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com |
From: Steve H. <dig...@mi...> - 2003-04-10 20:07:50
|
William McKee wrote: > > The main problem I'm having with using my custom vimrc is the > VimEnter autocommand. There a way to disable that if a flag is set > in the cream-conf.vim; may I send you a patch? You keep trying to disable things. Create autocommands that load following so you get the desired effect. It's the exact approach cream-user uses. Just create a: autocmd VimEnter * call Cream_source("/my/file.vim") line following your sourcing of Cream in your vimrc. > I'd suggest you create an addon to do this....I'm not sure I follow > you on the suggestion. Is this documented in a step-by-step manner > somewhere? Are there any add-ons I can look at to see what you are > talking about? See the FAQ, cream-addon.vim, and any addon. > So, my point of view, being an existing Vim user, is that Cream is > difficult to install and use because it doesn't play well with a > custom vimrc Your reasoning baffles me. Why should it be a project requirement that core components be incapacitated while third-party scripts be perfectly functioning? > So, this is strictly a matter of making Cream usable for existing > Vim users. I assume that existing Vim users know how to make their scripts work with Cream if that is desired. Primarily, we want a user to be able to install and use Cream as easily as possible. > I can keep commenting out that VimEnter autocommand in > cream-autocmd.vim each time a new release comes out but would like > to see a long-term solution that addresses the above problems in a > way that is nice to those of us who have taken the time to build-up > an arsenal of custom key mappings. Again, we have suggested cream-user. We have also added a ToDo item to have Cream explore some alternative possible locations for this file. Didn't get any feedback from you on this. > > > Is there a way to add custom completions to the list? > > > > Not unless there are errors. Mine are in cream-user. > > So you do use cream-user after all. Certainly! I wouldn't have created it and suggested it unless I felt it would be helpful to others! We do try to practice the Golden Rule here. ;) I mostly have personal templates: call ProcessImapLeader("", "sig", "--\nSteve Hall [ dig...@mi... ]") and abbreviations: iabbrev Linux GNU/Linux > > Since autocommands are required, they do add a level of > > complexity. See if commenting the ounmap and nunmap lines in > > cream-behavior help in combination with cream-user customizations. > > That may be all that is needed since looking at my custom vimrc, I > don't see many insertmode keymappings to speak of. This technique > should allow me to keep most of my custom key mappings in my custom > vimrc and not lose them when switching into the creamlite mode. Yes, please try my suggestions! Without feedback on them, I'm unable to offer alternatives. -- Steve Hall [ dig...@mi... ] |
From: William M. <wi...@kn...> - 2003-04-11 14:41:46
Attachments:
Cream_for_Vim.txt
|
> Your reasoning baffles me. Why should it be a project requirement that > core components be incapacitated while third-party scripts be > perfectly functioning? That has not been my intention. I am simply trying to find a way for my customizations to live with Cream in a way that is logical for a long-time Vim user. However, I'm finally starting to see your point. By allowing personal customizations to overlay Cream's settings, the user ends up with a non-standard environment. This may be what is desired but may also cause confusion for new users. I agree that the system should just work for new users and be configurable for existing users. Part of my problem is that it's taken me awhile to wrap my head around the idea that Cream demands a very specific environment and does not get along easily with personalized settings unless the user takes the appropriate measures. The other part has been that I've also been avoiding the need to learn more about Vim so that I can keep my existing Vim settings and still use Cream. > > So, this is strictly a matter of making Cream usable for existing > > Vim users. > > I assume that existing Vim users know how to make their scripts work > with Cream if that is desired. Primarily, we want a user to be able to > install and use Cream as easily as possible. Well this whole thread has been about an existing Vim user learning how to make my scripts work with Cream. That is *not* an easy task without some level of understanding of both Cream and Vim that has taken me several days and many hours to come around to (despite having read the documentation on your website which is primarily focused towards new users). Based on the lack of feedback from others in the mailing list, I'm guessing that I'm the only one here who is suffering from a Vim mental model or else noone here has ever used Vim without Cream. To help other habituated Vim users and try to solidify my understanding, I have put together a document which describes setting up Cream with a pre-existing Vim setup, ways to overcome some of the obstacles that I encountered and the realization I've had that Cream needs much greater control of my Vim environment than I ever expected. Some of the items in the document should be added to the installation notes to save others the headaches I've encountered and to save you from having to go through another conversation like this one. > > I can keep commenting out that VimEnter autocommand in > > cream-autocmd.vim each time a new release comes out but would like > > to see a long-term solution that addresses the above problems in a > > way that is nice to those of us who have taken the time to build-up > > an arsenal of custom key mappings. > > Again, we have suggested cream-user. We have also added a ToDo item to > have Cream explore some alternative possible locations for this file. > Didn't get any feedback from you on this. I think your suggestion of having a custom $HOME/.cream/cream-user.vim makes sense. This would work fine for Win* users if they set $HOME in their environment as I have under WinNT (in Win9x there are a few more steps as I recall). Now, if that file was present in the $HOME directory, would the $VIM/cream/cream-user.vim file also load, if present? Or would it only load one of the two as Vim does with vimrc? I vote for the latter. > I mostly have personal templates: Thanks for the examples of your cream-user.vim. I'm getting some strange behavior with the Alt+Space key mapping which may be due to my half-baked version of cream-keys-normal.vim. The template substitution works but it removes the next character which, if at the end of the line as is often the case when doing completions, causes the sentence below to jump up. Ever seen this behavior? Regards, William -- Knowmad Services Inc. http://www.knowmad.com |