cream-general Mailing List for Cream (for Vim) (Page 75)
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(7) |
Nov
(17) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(7) |
Feb
|
Mar
(34) |
Apr
(34) |
May
(3) |
Jun
(9) |
Jul
(29) |
Aug
(22) |
Sep
(36) |
Oct
(43) |
Nov
(15) |
Dec
(3) |
2004 |
Jan
(13) |
Feb
(25) |
Mar
(72) |
Apr
(45) |
May
(47) |
Jun
(36) |
Jul
(25) |
Aug
(33) |
Sep
(22) |
Oct
(68) |
Nov
(58) |
Dec
(30) |
2005 |
Jan
(46) |
Feb
(46) |
Mar
(34) |
Apr
(65) |
May
(24) |
Jun
(13) |
Jul
(12) |
Aug
(21) |
Sep
(19) |
Oct
(12) |
Nov
(25) |
Dec
(65) |
2006 |
Jan
(23) |
Feb
(15) |
Mar
(36) |
Apr
(47) |
May
(47) |
Jun
(51) |
Jul
(23) |
Aug
(14) |
Sep
(23) |
Oct
(47) |
Nov
(33) |
Dec
(10) |
2007 |
Jan
(4) |
Feb
(6) |
Mar
(2) |
Apr
(10) |
May
(27) |
Jun
(8) |
Jul
(12) |
Aug
(52) |
Sep
(17) |
Oct
(7) |
Nov
(3) |
Dec
(42) |
2008 |
Jan
(21) |
Feb
(22) |
Mar
(7) |
Apr
(6) |
May
(13) |
Jun
(5) |
Jul
(4) |
Aug
(5) |
Sep
|
Oct
|
Nov
(22) |
Dec
(4) |
2009 |
Jan
(2) |
Feb
(16) |
Mar
(5) |
Apr
(1) |
May
(6) |
Jun
(3) |
Jul
(6) |
Aug
(8) |
Sep
|
Oct
(36) |
Nov
(4) |
Dec
(4) |
2010 |
Jan
(3) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
|
2011 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
(7) |
May
(14) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2013 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(2) |
2014 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Peter C. L. <si...@co...> - 2003-06-14 05:20:06
|
Hi - I'm a new user to cream+vim. How do I remap or disable the function associated with 'shift-space'? It is annoying to see the HTML/CSS tag list dialog pop up every time I don't release the shift key while trying to use the space bar. Thanks. pete -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ |
From: sven v. <sv...@ap...> - 2003-05-27 12:54:08
|
With Cream 0.21a I seem to be unable to keep non-cream (vim) colour themes between sessions. I can change the theme and as long as it is cream theme, it will remember my preferences for next time too but vim schemes get kept only through current session, next time starting it defaults back to last used cream theme. Is there a way to rectify this situation? sven |
From: Ryan H. <rh...@cs...> - 2003-05-20 23:10:34
|
Hey guys, I just stumbled across your project, and having been a loyal vim junkie for a few years now, I thought I would give it a try. Your windows installer is very slick, but it complained about not being able to write to vimext.dll . This was fixed by running 'regsvr32 /u vimext.dll', and then re-running the installer. I'd suggest that you add this to the installer, perhaps after warning the user or something (and shutting down open vim processes, I suppose). Thanks, and keep up the good work. - Ryan |
From: Jones, N. <Nathan.Jones@Sodexho-uk.com> - 2003-05-12 11:49:08
|
Hi, Thanx very much for cream. It makes Vim just what I need for my job. However I have noticed one or two things that don't seem to work right. I am running on XP pro. I also have my task bar on auto-hide. If I maximise Vim and then shut it down the next time I run Vim it has moved down the screen by the width of the task bar, rather than maximised to the full screen. The second is that the paste on the menu option does not work. It keeps on coming up with an error message to say not enough parameters passed. I have modified my copy of the cream-menu-edit.vim file as follows "paste "anoremenu <silent> 20.360 &Edit.&Paste<Tab>Ctrl+P :call Cream_paste()<CR> imenu <silent> 20.360 &Edit.&Paste<Tab>Ctrl+P <C-o>:call Cream_paste("i")<CR> vmenu <silent> 20.360 &Edit.&Paste<Tab>Ctrl+P :<C-u>call Cream_paste("v")<CR> I hope this helps. I am not very fluent in Vim's scripting language so if I am barking up the wrong tree then let me know. Again many thanx for a wonderful bit of software/scripting. Nathan Jones ABAP Developer Em@il: nat...@so... This electronic transmission is strictly confidential and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please delete it and notify us as soon as possible. The Internet cannot guarantee the integrity of this message, Sodexho Alliance (and its subsidiaries) will not therefore be liable for the message if modified. |
From: <dig...@mi...> - 2003-04-16 16:04:55
|
It has come to our attention that the latest Cream 0.21 manual installation (.zip) package shipped with the developer profile live. This results in three side effects: o The Cream Developer menu is exposed o A few developer addons are exposed o Vim's script encoding is forced to UTF-8 While the first two items are completely harmless, the last may pose minor on-screen problems, especially when interacting with third-party applications that aren't UTF-8 compliant such as in a cut/paste operation. If you feel comfortable understanding how this impacts your use of Vim, there is no reason to change any aspect of Cream. (We use it this way daily.) However we have uploaded a revised manual installation package: http://prdownloads.sourceforge.net/cream/cream-0-21a.zip which corrects the issue. You can also repair it yourself simply by placing a double quote character (") before line 55 in cream.vim. Again, many users may not notice this being an issue since some distributions (e.g., Red Hat) default to &encoding=utf-8 in the first place, and we consider this a beta Cream feature that might become our standard in the near future. But we apologize if this undocumented behavior has caused any inconveniences. -- Steve Hall [ dig...@mi... ] |
From: <dig...@mi...> - 2003-04-16 14:14:43
|
From: Christian G=C3=B6bel, Wed, 16 Apr 2003 10:04:45 +0200 > A 23:21 15/04/2003 -0400, vous avez =C3=A9crit : > > Christian Goebel wrote: > > >=20 > > > [encoding problems] > >=20 > > Somewhere around line 90 in cream.vim, you'll find a line that > > forces &encoding =3D utf-8, conditioned upon the developer var being > > set. Uncomment that single line and restart to force this and let > > me know if that solves the problem. You might also force the file > > encoding for any specific file giving you problems, too, > > especially if it was created in some other app. >=20 > The line was uncommented - instead I commented it. Everything seems > to work fine again. Thanks a lot. I have never set the developer > var - this seems to be the default setting? (I installed cream > manually) UGH! I apparently forgot to comment out the developer var, so *everybody* who is using the manual install will have that enabled. Meaning that the Cream Developer menu is exposed and script encoding is forced to utf-8. A new fixed version is posted which simply comments out what you found.=20 > By the way: The old text files work fine with the new utf-8 > encoding. That means when I open a file with accents everything > looks normal. The described problems appear when typing new text or > when I try to copy/paste text from other programs. I think that what has happened for you is that your digraphs changed. Vim makes different ones available based on encoding. I'd appreciate if you can test the &encoding=3Dutf-8 for me: o Does the digraph listing under the Insert menu help at all?=20 o Does changing font help? (Is your font utf-8 compliant?) o What is the result of :echo &encoding with the dev var commented? > > UTF-8 encoding may become official next release. I wanted to wait > > to test this for a while myself before making it official. The > > next alpha already indicates &fileencoding in the status line and > > has the beginnings of a menu for over-ride, too. UTF-8 will > > someday solve a lot of problems, but many apps, fonts and docs use > > other standards now so this may shock some people. ;) (Similar to > > what I believe you are now experiencing! For example, the > > "prettier" invisible characters will regress to "$" and ">". :( ) >=20 > This is what I got, too with the utf-8 encoding - this is quite a > pitty - because there are no indicators for blank spaces anymore > (something I found quite useful for 'cleaning' the structure of a > file) Hmm... this works for me, it's now simply a period (".") character. > Perhaps it would be useful for some people (like me) to offer the > 'old' enconding in the settings - menue ? The problem decribed in > my 'bug' report is quite anoying at least when you are working with > French text on a Belgium keyboard. Next release will have a menu to set fileencoding to any number of selections (but not script encoding). It may be that your "other" programs don't properly handle utf-8 and that we can't solve this in Vim. Then letting you pick encoding via Cream would help, right? (But I'd still be in favor of keeping script encoding to utf-8.) BTW, what version/patch level of Vim are you using? There were some encoding-paste fixes just a short while ago. -- Steve Hall [ dig...@mi... ] |
From: Steve H. <dig...@mi...> - 2003-04-16 02:20:18
|
Christian Goebel wrote: > Hello, > > I use Cream on a Win2000. > Since I installed (manually) the latest release of > Cream 0.21 I have the following problem (unconvenient > behaviour): > > To get a "á" I have to type ´and then 3 times the a > to get a "é" I have to type ´ and then 3 times the e > to get an "ó" I have to type ´ and then 4 times the o > to get an "ú" I have to type ´ and then 5 times the u > > The same thing holds when I use these accents: > ^ ´ ` > > When I copy/paste text with accents into vim I get the following (in > the display): > "allocations de ch<f4>mage d<e9>pend de votre > derni<e8>re r<e8>mun<e9>ration" > instead of : > "allocations de chômage dépend de votre dernière > rémunération" > > However when I copy/paste the text back to another program I have my > accents back. > > In the elder versions of Cream I never had a problem like this. Sounds like an encoding problem. What do :echo &encoding :echo &fileencoding produce? Do you have any other scripts running or any specific customizations you've added? Somewhere around line 90 in cream.vim, you'll find a line that forces &encoding = utf-8, conditioned upon the developer var being set. Uncomment that single line and restart to force this and let me know if that solves the problem. You might also force the file encoding for any specific file giving you problems, too, especially if it was created in some other app. UTF-8 encoding may become official next release. I wanted to wait to test this for a while myself before making it official. The next alpha already indicates &fileencoding in the status line and has the beginnings of a menu for over-ride, too. UTF-8 will someday solve a lot of problems, but many apps, fonts and docs use other standards now so this may shock some people. ;) (Similar to what I believe you are now experiencing! For example, the "prettier" invisible characters will regress to "$" and ">". :( ) -- Steve Hall [ dig...@mi... ] Cream... a familiar feel for the famous Vim text editor! http://cream.sourceforge.net |
From: Milan K. <ko...@vo...> - 2003-04-14 13:00:04
|
Hi, JFYI on my PC there are no problems with accented characters in Cream 0.21 and W2k (and in Czech thtere is a lot of accented characters :)). Best regards, Milan -----Original Message----- Monday, April 14, 2003, 2:20:48 PM : CG> Hello, CG> I use Cream on a Win2000. CG> Since I installed (manually) the latest release of=20 CG> Cream 0.21 I have the following problem (unconvenient CG> behaviour): CG> To get a "=E1" I have to type =B4and then 3 times the a CG> to get a "=E9" I have to type =B4 and then 3 times the e CG> to get an "=F3" I have to type =B4 and then 4 times the o CG> to get an "=FA" I have to type =B4 and then 5 times the u CG> The same thing holds when I use these accents: CG> ^ =B4 ` CG> When I copy/paste text with accents into vim I get the CG> following (in the display): CG> "allocations de ch<f4>mage d<e9>pend de votre CG> derni<e8>re r<e8>mun<e9>ration" CG> instead of : CG> "allocations de ch=F4mage d=E9pend de votre derni=E8re CG> r=E9mun=E9ration" CG> However when I copy/paste the text back to another CG> program I have my accents back. CG> In the elder versions of Cream I never had a problem CG> like this. CG> Thanks CG> Christian CG> __________________________________________________ CG> Do you Yahoo!? CG> Yahoo! Tax Center - File online, calculators, forms, and more CG> http://tax.yahoo.com CG> ------------------------------------------------------- CG> This sf.net email is sponsored by:ThinkGeek CG> Welcome to geek heaven. CG> http://thinkgeek.com/sf CG> _______________________________________________ CG> cream-general mailing list CG> cre...@li... CG> https://lists.sourceforge.net/lists/listinfo/cream-general -------------------------------- |
From: Christian G. <go...@ya...> - 2003-04-14 12:21:00
|
Hello, I use Cream on a Win2000. Since I installed (manually) the latest release of Cream 0.21 I have the following problem (unconvenient behaviour): To get a "á" I have to type ´and then 3 times the a to get a "é" I have to type ´ and then 3 times the e to get an "ó" I have to type ´ and then 4 times the o to get an "ú" I have to type ´ and then 5 times the u The same thing holds when I use these accents: ^ ´ ` When I copy/paste text with accents into vim I get the following (in the display): "allocations de ch<f4>mage d<e9>pend de votre derni<e8>re r<e8>mun<e9>ration" instead of : "allocations de chômage dépend de votre dernière rémunération" However when I copy/paste the text back to another program I have my accents back. In the elder versions of Cream I never had a problem like this. Thanks Christian __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com |
From: William M. <wi...@kn...> - 2003-04-11 14:41:46
|
> 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 |
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-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 18:23:29
|
William McKee wrote: > On Thu, Apr 10, 2003 at 02:39:24PM -0400, Steve Hall wrote: > > > > the lhs (:help lhs) is re-defined to perform the action of the rhs. > > But what if the rhs is redefined like: > > Right, I read about this problem in the help file last week. Are you > concerned that a rhs in a normalmode mapping may cause problems in > insertmode? I notice some module writers always use noremap when > doing mappings to avoid this possibility. Do you see any reason not > to always use inoremap, vnoremap, nnoremap or noremap? Hmm... probably not, but I'd like to do some testing first. Early on, we thought the notion of being able to call our own mappings attractive, now days not so much. -- Steve Hall [ dig...@mi... ] |
From: William M. <wi...@kn...> - 2003-04-10 18:05:14
|
On Thu, Apr 10, 2003 at 02:39:24PM -0400, Steve Hall wrote: > the lhs (:help lhs) is re-defined to perform the action of the rhs. > But what if the rhs is redefined like: Right, I read about this problem in the help file last week. Are you concerned that a rhs in a normalmode mapping may cause problems in insertmode? I notice some module writers always use noremap when doing mappings to avoid this possibility. Do you see any reason not to always use inoremap, vnoremap, nnoremap or noremap? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com |
From: Steve H. <dig...@mi...> - 2003-04-10 17:41:19
|
simprix wrote: > > When i install cream to .cream and copy _gvimrc and _vimrc over when > i load up gvim with the gtk2 patch none of the buttons load they > just show a picture icon with a red x in it > Thanks alot. Sounds like Daniel hasn't yet considered custom icons in his patch, I know he said he was working on it but perhaps it isn't implemented yet. You might subscribe to the vim-dev list for more discussion. I've not really done any testing on G2 yet and don't have a box to try. :( -- Steve Hall [ dig...@mi... ] |
From: Steve H. <dig...@mi...> - 2003-04-10 17:38:18
|
William McKee wrote: > On Thu, Apr 10, 2003 at 12:28:45PM -0400, Steve Hall wrote: > > > > > I'm not sure I follow why a re-mapped normal mode key would mean > > > that you'd need to adjust the calls in insertmode. > > > > Just to make sure we've got dependencies covered, e.g., probably > > quite a few imaps will need to be replaced with inoremaps. (If > > Ctrl+Down is imapped to normal mode <C-e>, then normal mode <C-e> > > needs to still do what it is supposed to do. > > You're definitely way ahead of my fledgling knowledge of key > mappings so please bear with me. Is the replacing of imaps to > inoremaps what you said in the first paragraph you're not inclined > to do? If not, please explain. Also, is the reason you're not > inclined to adjust the calls at insertmode because of time or > adverse interactions with normalmode? I'm not clear on how you > perceive these key mappings to be dependent on one another. In the form: imap <key1> <key2> the lhs (:help lhs) is re-defined to perform the action of the rhs. But what if the rhs is redefined like: imap <key2> <key3> Then we effectively have imap <key1> <key3> If this is undesirable (our case most times), you can use inoremap <key1> <key2> imap <key2> <key3> Since most of our calls are imaps, we need to be sure their rhs portions haven't been remapped, too. I've tried to be careful in never calling one map from another, but I know this has happened at least once or twice. -- Steve Hall [ dig...@mi... ] Try Cream... the usability project for Vim! http://cream.sourceforge.net |
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: simprix <si...@si...> - 2003-04-10 16:43:57
|
When i install cream to .cream and copy _gvimrc and _vimrc over when i load up gvim with the gtk2 patch none of the buttons load they just show a picture icon with a red x in it Thanks alot. == 12:42:01 up 2:13, 1 user, load average: 0.46, 0.47, 0.37 Linux gandalf 2.4.20-gaming-r1 #2 Sun Mar 30 05:04:30 EST 2003 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz GenuineIntel GNU/Linux |
From: William M. <wi...@kn...> - 2003-04-10 16:18:13
|
On Thu, Apr 10, 2003 at 12:28:45PM -0400, Steve Hall wrote: > It looks like you're not installing it in the default $HOME, so I > believe this is documented in the lower items in the FAQ section > "Advanced Vim Users". Thanks, I just found that section as I was reading about Template completions. > > Why not just follow suit and offer a standard means of generating > > tags rather than making Cream users track down how to run an > > external program > > You'll find a beta of that idea in Tools.Addons.Ctags Generate. Still > could use some improvements though. Excellent! I'll take a look at it. > > > I find at least 6 remappings just in insert mode (search > > > cream-keys for "nore"). But you'll probably come across many more > > > in normal mode, simply because there's no point in remapping them > > > if we're only using insertmode. (e.g., <C-f>, <C-e>, <C-w>, > > > <C-q>). Also, a re-mapped normal mode key means adjusting the > > > calls at insertmode, too, something I'm not inclined to do. > > > > I'm not sure I follow why a re-mapped normal mode key would mean > > that you'd need to adjust the calls in insertmode. > > Just to make sure we've got dependencies covered, e.g., probably quite > a few imaps will need to be replaced with inoremaps. (If Ctrl+Down is > imapped to normal mode <C-e>, then normal mode <C-e> needs to still do > what it is supposed to do. You're definitely way ahead of my fledgling knowledge of key mappings so please bear with me. Is the replacing of imaps to inoremaps what you said in the first paragraph you're not inclined to do? If not, please explain. Also, is the reason you're not inclined to adjust the calls at insertmode because of time or adverse interactions with normalmode? I'm not clear on how you perceive these key mappings to be dependent on one another. > > The noremap function maps normal, insert and visual. We could > > instead use the nnoremap or, as I'm doing with the > > cream-keys-normal.vim, use the nmap function both of which only map > > normal mode keys. > > Yes, nmap/nnoremap is much better, since frequently imap and vmap for > the same function have slightly different call arguments to handle > selection/no selection conditions when activated. Good, then I've started down the right track with the cream-keys-normal.vim file. > > You have created a lot of mappings, many of which seem reasonable > > even though they are not Vim defaults. It will take me another night > > or two to finish up my editing and testing of the > > cream-keys-normal.vim. > > Looking forward to seeing it. Thanks, that's encouraging to hear. William -- Knowmad Services Inc. http://www.knowmad.com |
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 15:27:39
|
William McKee wrote: > On Thu, Apr 10, 2003 at 03:28:29AM -0400, Steve Hall wrote: > > That works! > > FYI, to install Cream for all users on a Linux system, you need to > manually set the $CREAM directory variable to the system location of > $VIM. For me, running Debian Woody, it is set in my global vimrc > before I source cream as: > > let $CREAM='/usr/share/vim/cream/' It looks like you're not installing it in the default $HOME, so I believe this is documented in the lower items in the FAQ section "Advanced Vim Users". > > We don't generate tags since it is difficult across platforms and > > because it is impossible to guess what other directories might > > also be involved. > > Why not just follow suit and offer a standard means of generating > tags rather than making Cream users track down how to run an > external program You'll find a beta of that idea in Tools.Addons.Ctags Generate. Still could use some improvements though. > > I find at least 6 remappings just in insert mode (search > > cream-keys for "nore"). But you'll probably come across many more > > in normal mode, simply because there's no point in remapping them > > if we're only using insertmode. (e.g., <C-f>, <C-e>, <C-w>, > > <C-q>). Also, a re-mapped normal mode key means adjusting the > > calls at insertmode, too, something I'm not inclined to do. > > I'm not sure I follow why a re-mapped normal mode key would mean > that you'd need to adjust the calls in insertmode. Just to make sure we've got dependencies covered, e.g., probably quite a few imaps will need to be replaced with inoremaps. (If Ctrl+Down is imapped to normal mode <C-e>, then normal mode <C-e> needs to still do what it is supposed to do. > The noremap function maps normal, insert and visual. We could > instead use the nnoremap or, as I'm doing with the > cream-keys-normal.vim, use the nmap function both of which only map > normal mode keys. Yes, nmap/nnoremap is much better, since frequently imap and vmap for the same function have slightly different call arguments to handle selection/no selection conditions when activated. > You have created a lot of mappings, many of which seem reasonable > even though they are not Vim defaults. It will take me another night > or two to finish up my editing and testing of the > cream-keys-normal.vim. Looking forward to seeing it. -- Steve Hall [ dig...@mi... ] Try Cream... the usability project for Vim! http://cream.sourceforge.net |
From: William M. <wi...@kn...> - 2003-04-10 14:41:12
|
On Thu, Apr 10, 2003 at 03:28:29AM -0400, Steve Hall wrote: > > That still didn't help. I looked at the loaded files via the :script > > command and saw a file named cream-colors.vim being loaded. This > > file does not have the Sig or EQuote settings. Do I need to remove > > this file? Does the cream-colors-default.vim replace this file? > > Hmm... try the new version of Cream: That works! FYI, to install Cream for all users on a Linux system, you need to manually set the $CREAM directory variable to the system location of $VIM. For me, running Debian Woody, it is set in my global vimrc before I source cream as: let $CREAM='/usr/share/vim/cream/' > I use ctags (ctags.sf.net). We don't generate tags since it is > difficult across platforms and because it is impossible to guess what > other directories might also be involved. (For example, the Cream > developer generator considers both the main functions and the addons.) > Since we consider this a programmer's feature, we leave it up to the > individual to generate them. As do I. I'm not sure I follow your logic here. Vim comes with a build tags icon in the toolbar which works for probably 90% of the users. Why not just follow suit and offer a standard means of generating tags rather than making Cream users track down how to run an external program (I had to look it up b/c I don't use it that often) then figure out the commands necessary to generate the tags and finally type in the commands to perform the tag generation? I'd think that at least half of the target audience of a text editor would be programmers of some ilk. Otherwise, I find that folks are using word processors. > I find at least 6 remappings just in insert mode (search cream-keys > for "nore"). But you'll probably come across many more in normal mode, > simply because there's no point in remapping them if we're only using > insertmode. (e.g., <C-f>, <C-e>, <C-w>, <C-q>). Also, a re-mapped > normal mode key means adjusting the calls at insertmode, too, > something I'm not inclined to do. I'm not sure I follow why a re-mapped normal mode key would mean that you'd need to adjust the calls in insertmode. The noremap function maps normal, insert and visual. We could instead use the nnoremap or, as I'm doing with the cream-keys-normal.vim, use the nmap function both of which only map normal mode keys. You have created a lot of mappings, many of which seem reasonable even though they are not Vim defaults. It will take me another night or two to finish up my editing and testing of the cream-keys-normal.vim. 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-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: <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... ] |