Re: Odp: BOF Vim 8 - Suggestions
Hi Stefano Zacchiroli, you wrote: The solution of being compatible when invoked as 'vi' and being nocompatible when invoked in a different way made everybody happy. The (trivial) patch we are using to implement this behaviour is available at: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim/debian/tiny/vimrc.tiny.diff?op=filerev=0sc=0 FWIW we also set a lot of other default values when not invoked as 'vi'. This really seems to be a good option. -- Alexei Alexandrov
Re: Odp: BOF Vim 8 - Suggestions
A.J.Mechelynck wrote: I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: ... Good advice, as always, Tony. But I am trying to crack a different nut. In the BOF talk, Bram really was asking for ideas on what would make new users flock to Vim. These days there are a lot of really good editors. No one is going to spend a couple of hours methodically working through vimtutor (sorry Bram!). A new user is just going to try Vim as an editor. If the default Vim behaviour confuses or upsets the user, Vim will never be used again. I sense an attitude here that it's just the luser's loss if they don't learn how to use Vim. Fair enough, but there should be a way for a non-vi user to enter a command telling Vim I'm one of those 95% of people who use a modern PC - please switch to a useful mode. I had the experience of advising a very competent programmer who got a job working on virtual memory in the Linux kernel (previously he had only dabbled in Linux, and had developed under Windows). At the time, we couldn't meet, and I was restricted to providing advice via email. Let me tell you, it is pretty well impossible to convince someone to use Vim via email. The guy wanted to do stuff right now, and I would send some 100-line email with instructions on how he could do this and that to vimrc, and then everything would be simple. One problem was how search highlighting is persistent (which is great), but it is very distracting to some people when you want to turn your attention to another issue. Telling him how to map a key to do ':nohl' is just unnecessary mumbo jumbo. John
Re: Odp: BOF Vim 8 - Suggestions
On 1/19/07, John Beckett [EMAIL PROTECTED] wrote: One problem was how search highlighting is persistent (which is great), but it is very distracting to some people when you want to turn your attention to another issue. Telling him how to map a key to do ':nohl' is just unnecessary mumbo jumbo. Which, presumably, is why 'hlsearch' is off by default. If you don't want to tell him about :nohl, then it doesn't make sense to enable 'hlsearch'. Perhaps a better way is to leave 'hlsearch' off and provide a binding that toggles it on and off. That way you don't get the distracting highlighting until you actually request it. Actually, I'm going to try that out, because I find myself always following a search command with a ',h', which is what I have :nohl bound to. nikolai
Re: Odp: BOF Vim 8 - Suggestions
On Thu, Jan 18, 2007 at 05:46:55PM +0100, A.J.Mechelynck wrote: Vim defaults to 'compatible' mode everywhere, except where it finds a user _vimrc or .vimrc (system vimrc doesn't count). I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: This isn't really applicable to *nix-like systems, where you have tons of users, and packages as vim are usually installed system-wide. As a sysadm, should I install .vimrc on the home of every user? Should I modify the /etc/skel/ dir so that every new user get a .vimrc upon account creation? Ok that vim is my second most used command (after ls :-)), but this is really too much to ask for just an editor. Rather, time is probably mature to ship vim with 'compatible' mode off by default, explaining ancient *nix lovers how to turn it *on*. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: Odp: BOF Vim 8 - Suggestions
John Beckett wrote: A.J.Mechelynck wrote: I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: ... Good advice, as always, Tony. But I am trying to crack a different nut. In the BOF talk, Bram really was asking for ideas on what would make new users flock to Vim. These days there are a lot of really good editors. No one is going to spend a couple of hours methodically working through vimtutor (sorry Bram!). A new user is just going to try Vim as an editor. If the default Vim behaviour confuses or upsets the user, Vim will never be used again. I sense an attitude here that it's just the luser's loss if they don't learn how to use Vim. Fair enough, but there should be a way for a non-vi user to enter a command telling Vim I'm one of those 95% of people who use a modern PC - please switch to a useful mode. Easy Vim and mswin.vim were written for exactly that purpose, and IMHO they cripple Vim to almost complete _un_usefulness. Vim is a very powerful editor, but to be able to use it, you need at the very least to understand the difference between Normal mode and Insert mode. To use it like the fine tool it is, you need to study, just like one needs to study to become a concert pianist. If you're one of those 95% of users who need to be led by the hand by their OS and editor, and are too dumb for a modal editor, go use Notepad and stop bugging us. I had the experience of advising a very competent programmer who got a job working on virtual memory in the Linux kernel (previously he had only dabbled in Linux, and had developed under Windows). At the time, we couldn't meet, and I was restricted to providing advice via email. Let me tell you, it is pretty well impossible to convince someone to use Vim via email. The guy wanted to do stuff right now, and I would send some 100-line email with instructions on how he could do this and that to vimrc, and then everything would be simple. One problem was how search highlighting is persistent (which is great), but it is very distracting to some people when you want to turn your attention to another issue. Telling him how to map a key to do ':nohl' is just unnecessary mumbo jumbo. John Why not just type :noh at the keyboard then, if you can't use a mapping? Best regards, Tony.
Re: Odp: BOF Vim 8 - Suggestions
Nikolai Weibull wrote: Perhaps a better way is to leave 'hlsearch' off and provide a binding that toggles it on and off. That way you don't get the distracting highlighting until you actually request it. OK but I imagine most people would like hlsearch on while they are searching (I certainly do). I am trying to make a slightly different point: 1. Bram has asked for ideas on how to popularise Vim. 2. I think better default behaviour would be best. IMHO it is quite idiotic that Vim has the really great feature of globally highlighting searches, but the user has to learn how to map keys to make it work in a sensible way. I suppose there are people who don't mind the distracting highlights once they've finished looking at them, but I'm pretty confident that most people here have a mapping to deal with the situation. All of what I am saying it totally irrelevant if there is no desire to popularise Vim. John
Re: Odp: BOF Vim 8 - Suggestions
A.J.Mechelynck wrote: I sense an attitude here that it's just the luser's loss if they don't learn how to use Vim. Fair enough, but there should be a way for a non-vi user to enter a command telling Vim I'm one of those 95% of people who use a modern PC - please switch to a useful mode. Easy Vim and mswin.vim were written for exactly that purpose, and IMHO they cripple Vim to almost complete _un_usefulness. Vim is a very powerful editor, but to be able to use it, you need at the very least to understand the difference between Normal mode and Insert mode. To use it like the fine tool it is, you need to study, just like one needs to study to become a concert pianist. If you're one of those 95% of users who need to be led by the hand by their OS and editor, and are too dumb for a modal editor, go use Notepad and stop bugging us. I accidentally said mode with the unintended suggestion that I was whining about Normal mode etc. Sorry. I totally agree that a Vim user has to work with Vim, and not try to pretend it is something different. Normal and Insert modes are fine by me. By a useful mode I meant a more accessible implementation of core features. Take searching. Incremental search and global search highlighting are sensational. But new users are going to want to turn the highlighting off (gedit has a menu item for this). It's obvious that most people are going to want a key mapping. So why not provide a standard mapping? OK, I can understand that you may not want the standard mappings enabled by default. So provide some new command to enable them. Why not just type :noh at the keyboard then, if you can't use a mapping? Are you suggesting this in the context of my proposal to improve the experience for new Vim users, in order to popularise Vim? There has to be an EASY way to turn off search highlights! John
Re: Odp: BOF Vim 8 - Suggestions
On 1/19/07, John Beckett [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: Perhaps a better way is to leave 'hlsearch' off and provide a binding that toggles it on and off. That way you don't get the distracting highlighting until you actually request it. OK but I imagine most people would like hlsearch on while they are searching (I certainly do). Well, hlsearch only kicks in /after/ you've completed your search, whether you're using 'incsearch' or not. I once thought this was a nice feature, but I've realized that I rarely need to have other matches highlighted. I mean, either I've found what I want using 'incsearch', or I have failed to find the text location that I wanted, and highlighting the other matches won't really help much. Narrowing your search using 'incsearch' is often a lot quicker than doing a quick search and pressing 'n' a bunch of times to get to the right match. IMHO it is quite idiotic that Vim has the really great feature of globally highlighting searches, but the user has to learn how to map keys to make it work in a sensible way. I suppose there are people who don't mind the distracting highlights once they've finished looking at them, but I'm pretty confident that most people here have a mapping to deal with the situation. Well then, how should it work? One solution would be to disable it as soon as the mode changes. That way it's on while you're looking for matches and is turned of as soon as you start making changes. nikolai
Re: Odp: BOF Vim 8 - Suggestions
On Fri, Jan 19, 2007 at 01:09:41PM +0100, Martin Stubenschrott wrote: First and most important thing would be to enable nocompatible by default when the executable name is (g)vim, compatible should still be on, when the executable name is vi. Enabling/disabling by an (non-)existing That's precisely what we do in Debian. In the past we used to have 'nocompatible' set per default, but a non-negligible amount of users asked for vim to behave more similarly to the plain old Vi when we switched from nvi to vim in the default debian installation. The solution of being compatible when invoked as 'vi' and being nocompatible when invoked in a different way made everybody happy. The (trivial) patch we are using to implement this behaviour is available at: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim/debian/tiny/vimrc.tiny.diff?op=filerev=0sc=0 FWIW we also set a lot of other default values when not invoked as 'vi'. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: Odp: BOF Vim 8 - Suggestions
Matthew Winn wrote: In other products I've seen where search highlighting is always on, it generally takes users no more than a couple of seconds to realise that if the highlighting is distracting them all they have to do is enter a search that won't work, typically by dragging their fingers across the keyboard to create a string like sdzdxfchgjbnk, and the highlighting has gone. I used to do this with vim, until I was working on some very large files, and got of waiting for the bogus search to finish. Then I finally looked up how to disable the highlighting. I've never bound it to anything finding: :nohlCR easy enough to type. Dave
Re: Odp: BOF Vim 8 - Suggestions
Martin Stubenschrott wrote: On Fri, Jan 19, 2007 at 07:28:51PM +1100, John Beckett wrote: In the BOF talk, Bram really was asking for ideas on what would make new users flock to Vim. Biggest changes would really be defaults imho. And that should be done without really compromising compatible mode. First and most important thing would be to enable nocompatible by default when the executable name is (g)vim, compatible should still be on, when the executable name is vi. Enabling/disabling by an (non-)existing .vimrc file is not the right way, because if you make your own .vimrc file, you want to add some usefull behavior and in exchange you get less optimal behavior in many cases, and probably don't know why that is happening, just because you created a .vimrc with some mappings. It's really crazy that you can't even press Tab after :e to complete filenames in compatible mode. Remember: vi used to have, not a vimrc but an exrc. If your settings file is called exrc, Vim won't set 'nocompatible'. Second would be to enable :syntax on by default in nocompatible mode. Every bullshit-editor (sorry for the word), has syntax highlighting now, and even a Pentium 200 should be fast enough to deal with syntax highligthing. Third, I would enable isearch by default, but keep hlsearch off (as it is now). Most other options are right for experts and newbies as well, or at least have another reason for their default setting. -- Martin I would leave the defaults as they are. The vimrc_example.vim already sets filetype plugin indent on and syntax on, BTW. Sourcing that script from your vimrc is IMHO no great hassle, and gives the benefit of many better settings, not only syntax highlights but e.g. going back to the latest edit position whenever you enter a file. IIUC, there _are_ vimrc scripts out there (I'd guess there are many of them) which don't bother to explicitly set any settings to what is currently their default. Changing such defaults would break those scripts. Best regards, Tony.
Re: Odp: BOF Vim 8 - Suggestions
Stefano Zacchiroli wrote: On Thu, Jan 18, 2007 at 05:46:55PM +0100, A.J.Mechelynck wrote: Vim defaults to 'compatible' mode everywhere, except where it finds a user _vimrc or .vimrc (system vimrc doesn't count). I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: This isn't really applicable to *nix-like systems, where you have tons of users, and packages as vim are usually installed system-wide. As a sysadm, should I install .vimrc on the home of every user? Should I modify the /etc/skel/ dir so that every new user get a .vimrc upon account creation? Ok that vim is my second most used command (after ls :-)), but this is really too much to ask for just an editor. Rather, time is probably mature to ship vim with 'compatible' mode off by default, explaining ancient *nix lovers how to turn it *on*. Cheers. As a sysadmin, you have every right, even that of making users angry at you, calling them lusers, and answering them with a 2-by-4 like any bad-tempered BOFH. Seriously now, you can setup /usr/share/vim/vimrc (or something) to invoke the vimrc_example.vim (which sets 'nocompatible' explicitly) and that would be system-wide without interfering with every user's right to set up his own ~/.vimrc the way he liked -- or not at all. It /would/ interfere with the expectation that vi (when called as vi) should start in 'compatible' mode, I suppose; but there might be ways to care for that too, maybe through an alias from 'vi' to 'vim -u NONE'. Best regards, Tony.
Re: Odp: BOF Vim 8 - Suggestions
Nikolai Weibull wrote: Well, hlsearch only kicks in /after/ you've completed your search, whether you're using 'incsearch' or not. I once thought this was a nice feature, but I've realized that I rarely need to have other matches highlighted. I mean, either I've found what I want using 'incsearch', or I have failed to find the text location that I wanted, and highlighting the other matches won't really help much. Narrowing your search using 'incsearch' is often a lot quicker than doing a quick search and pressing 'n' a bunch of times to get to the right match. What you describe works well in many circumstances. But I find that the global highlighting is invaluable when programming. Built-in to Vim is the fact that pressing * searches for the current word. Programmers love this. IMHO they would appreciate a simple way to clear the highlights _and_ the message line when turning attention to something else. Searching for non-existent junk is just too distracting to my mental process. John
Re: Odp: BOF Vim 8 - Suggestions
Mikołaj Machowski wrote: I won't say more now. If Bram feels that improved defaults would be worth investigating, a discussion here would probably be best. OTOH people who dream in Vim script may not be the best source of ideas on how Vim should be configured to win new converts. I suppose this apply for me also ;), but: 1. Persistence of search highlighting is IMO good thing. 2. Star behaviour of keys much depends on packager. If Vim starts in compatible mode there is nothing which can be done. In nocompatible mode everything works as newbie can expect. AFAIR on Win32 default Vim mode is nocompatible, on Linux distributions it depends on packager but I think apart from redhattish vim-minimal for admin purposes everywhere is nocompatible. m. Ania - Kilka historii na ten sam temat - trasa koncertowa: Wrocław, Zielona Góra, Warszawa, Ełk, Lublin... Sprawdź: Sprawdź:http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fbytom.htmlsid=993 Vim defaults to 'compatible' mode everywhere, except where it finds a user _vimrc or .vimrc (system vimrc doesn't count). I personally recommend to create the following as $HOME/_vimrc (or $HOME/.vimrc) immediately after first installation, and to add tweaks as one gets going: quote runtime vimrc_example.vim /quote Bram says it's better to _copy_ the vimrc_example rather than _source_ (or :runtime) it. My personal opinion is that the vimrc_example will give headaches if one tries to understand it too soon, and that leaving it unmodified (with user tweaks in a different, hopefully simpler and smaller, file) keeps things more orderly. It's always possible (and educational) to use :view $VIMRUNTIME/vimrc_example.vim when one feels relaxed and curious. Changes to the menu/messages language should go before invoking the vimrc_example; most any other tweaks should go after it. Best regards, Tony.
Odp: BOF Vim 8 - Suggestions
I won't say more now. If Bram feels that improved defaults would be worth investigating, a discussion here would probably be best. OTOH people who dream in Vim script may not be the best source of ideas on how Vim should be configured to win new converts. I suppose this apply for me also ;), but: 1. Persistence of search highlighting is IMO good thing. 2. Star behaviour of keys much depends on packager. If Vim starts in compatible mode there is nothing which can be done. In nocompatible mode everything works as newbie can expect. AFAIR on Win32 default Vim mode is nocompatible, on Linux distributions it depends on packager but I think apart from redhattish vim-minimal for admin purposes everywhere is nocompatible. m. Ania - Kilka historii na ten sam temat - trasa koncertowa: Wrocław, Zielona Góra, Warszawa, Ełk, Lublin... Sprawdź: Sprawdź:http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fbytom.htmlsid=993
