Re: BOF Vim 8 - Suggestions
On 1/18/07, Bram Moolenaar [EMAIL PROTECTED] wrote: I do agree that good defaults are important. But backwards compatibility is also important. It's not always easy to make a choice. I think some things would be really sane to have on by default, such as :syntax on, but at the same time it's a whole hell of a lot easier to change the defaults by providing a .vimrc that gets sourced if the user doesn't have a .vimrc than change the defaults in the source (as that affects everyone). nikolai
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: VC8 makefile patch
On 18/01/2007 20:55, Bram Moolenaar wrote: Mike Williams wrote: Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Although MS keeps changing the arguments, the new ones mostly get used again in future versions. Thus this check: + !if $(_NMAKE_VER) != 8.00.50727.42 Should probably check if the version is greater than or smaller than this specific number. At least do the comparing with this specific number once and pass the result to further ifs. Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple of checks for VC4 so the file is a bit more more self documenting. Thanks, looks much better. I wonder what actually does. Is it a textual compare? Perhaps you can try out if using or works to avoid these magic build numbers. Some people must have different builds (otherwise they wouldn't include these numbers, right?). The doc states that strings should be compared with == and != but empirically (at least with VC8 ;-) ) the ordering relational operators seem to work. It is possible they don't in older versions, in which case they would need to be the equality operators only. Perhaps those with VC4/5/6/7 can try out the patch and see if it works or not. The numbers identify specific versions of VC. I believe early releases (MS's CTP, public betas etc.) have different numbers but I cannot find any reference list to discern a definitive pattern. HTH Mike -- If you're trying to drive me crazy, you're too late!
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: Make an easy way to encrypt a secret within a line. [Really complex scheme to implement this.] Why is it not enough to simply implement a function that encrypts/decrypts a range of text, much like g? ROT13s a range of text? Because the scheme needs to be simple to use. Once you have that, you have the danger that you will accidentally encrypt or decrypt twice ... then you can lose data. You need some safety checks from a carefully-written program ... although I suppose you could incorporate all that in your hypothetical function. John
Re: BOF Vim 8 - EncryptLine
Bram Moolenaar wwrote: Suggested new feature: Make an easy way to encrypt a secret within a line. This is very a specific feature. You should implement this in a script, this doesn't sound like something Vim should support internally. OK. I just thought I would mention the concept because I find it useful, and AFAIK it's a novel idea that might have appealed. John
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing Let's not start a religious war, but FWIW many authorities have changed their mind and no longer advocate the don't write down a password advice. In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). John
Re: BOF Vim 8 - Suggestions
Bram Moolenaar wrote: Mostly PageUp and PageDown do the reverse of each other. If you mean that the cursor has moved, that is a completely different thing. I'm not sure what completely different thing adds. I'm just trying to respond to your call for suggestions on how to make Vim more attractive to new users. I know a couple of people who don't like the fact that, in Vim, PageUp does not reverse PageDown. Naturally I am talking about the cursor moving. Switching off search highlighting is part of the tutor. People who skip the vimtutor are going to run into trouble anyway. OK - but you could make Vim more attractive if (when enabled by some new option) pressing Escape in Normal mode cleared search highlights and cleared the message line. I do agree that good defaults are important. But backwards compatibility is also important. It's not always easy to make a choice. Suggestion: Provide a simple way for a user to invoke a standard set of predefined mappings. In fact, there could be various predefined themes that insert useful settings into vimrc. Then, I could write an email to a friend saying Run gvim and do stuff to select a theme. Then you can press F11 to do clever thing. For example, perhaps F11 = :cn, Shift-F11 = :cp. Naturally there would be a lot of different opinion on what should be included. Anything would be better than the current situation where I have to convince a prospective new user to become a guru before they can use some of Vim's brilliant features. John
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: BOF Vim 8 - EncryptLine
On 1/19/07, John Beckett [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing Let's not start a religious war, but FWIW many authorities have changed their mind and no longer advocate the don't write down a password advice. In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. I don't understand what you're trying to say in the first part of your sentence. For the second part, see below. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. So it's better to use one good password/passphrase and stick with it. 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: BOF Vim 8 - EncryptLine
On 1/19/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. So it's better to use one good password/passphrase and stick with it. No, is not. Think in this if someone take one of you email password it only gonna have it not all you passwords. And if someone gonna try to take you password it will try are the password is used and gonna search for it not to the pass to open the file that have the pass. Yes, someone can do it, but this no defeat the whole point if having multiple passwords. -- «Dans la vie, rien n'est à craindre, tout est à comprendre» Marie Sklodowska Curie.
Re: BOF Vim 8 - EncryptLine
On Thu, 18 Jan 2007 11:04:00 +0100, Nicolas Weber
[EMAIL PROTECTED] wrote:
You are correct, I was thinking of this the other way around. My
suggestion would only be security in the sense that someone
reading over your shoulder would be prevented from seeing sensitive
content in the file (e.g. passwords) and would really only be an
extension to folding. No change would be made to the file on disk
(e.g. the file would need to be secured on disk using some other
external mechanism).
this can already been done with g?$ (or g?a{ )...so if you only want
to protect your data from people looking over your shoulders, that's
already there.
Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner.
--
Matthew Winn
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: BOF Vim 8 - EncryptLine
From: [EMAIL PROTECTED] On 1/19/07, Matthew Winn [EMAIL PROTECTED] wrote: Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner. Hm. I don't understand. Is that some sort of encryption you're using? Garbled, typo somewhere or spellchecker goofed! :-) ---Zdenek smime.p7s Description: S/MIME cryptographic signature
Re: BOF Vim 8 - Suggestions
John Beckett wrote: Bram Moolenaar wrote: Mostly PageUp and PageDown do the reverse of each other. If you mean that the cursor has moved, that is a completely different thing. I'm not sure what completely different thing adds. I'm just trying to respond to your call for suggestions on how to make Vim more attractive to new users. I know a couple of people who don't like the fact that, in Vim, PageUp does not reverse PageDown. Naturally I am talking about the cursor moving. The completely different thing is that this is not about scrolling but about moving the cursor so that it's in the visible text. I know this is different from most other editors and requires a bit of time getting used to. And it's something that will change the feeling of how the editor works, thus it's unlikely to change. I thought about this a few times, but still don't know a solution that won't cause trouble for people who are used to the vi behavior. And no, an option is not really an option. Switching off search highlighting is part of the tutor. People who skip the vimtutor are going to run into trouble anyway. OK - but you could make Vim more attractive if (when enabled by some new option) pressing Escape in Normal mode cleared search highlights and cleared the message line. No, I don't want that. Pressing ESC is to get back to Normal mode, it should not have side effects like this. It's always bad when one key does two or more things. If you only want one of them you have a problem. You appear to assume that what you want is what everybody wants. Many users think that way. But that is not so. It's very hard to figure out what works right for most people and doesn't work bad for some people. I do agree that good defaults are important. But backwards compatibility is also important. It's not always easy to make a choice. Suggestion: Provide a simple way for a user to invoke a standard set of predefined mappings. In fact, there could be various predefined themes that insert useful settings into vimrc. It's better to have the user get used to the existing commands. There is one theme for MS-Windows users, and it's already causing quite a bit of confusion. I don't think we want more of that. Imagine how may exceptions we need to handle in the documentation: if you use theme X then this doesn't work and you need to type XYZ. Then, I could write an email to a friend saying Run gvim and do stuff to select a theme. Then you can press F11 to do clever thing. For example, perhaps F11 = :cn, Shift-F11 = :cp. You can always tell someone to download your script and use it. That's quite simple, you only need to drop it in a specific directory. Naturally there would be a lot of different opinion on what should be included. Anything would be better than the current situation where I have to convince a prospective new user to become a guru before they can use some of Vim's brilliant features. No matter under what key you put something, you still need to know what key it is. -- Portable Computer: A device invented to force businessmen to work at home, on vacation, and on business trips. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: patch 182 and selectbuf [interferes with netrw plugin]
On Thu, 18 Jan 2007 17:22:24 +0100, A.J.Mechelynck [EMAIL PROTECTED] said: Denis Perelyubskiy wrote: hello, I briefly upgraded to patch 182 a little while back, and selectbuf script which I absolutely adore :) stopped working (http://vim.sourceforge.net/scripts/script.php?script_id=107) I am using version .178 right now. Something about those 4 patches (179.180.181.182) breaks the script. You may want to check the bottom lines of the patches' README file http://ftp.vim.org/pub/vim/patches/7.0/README to help you guess which of these patches might be breaking your favourite script. Thanks. While I can't tell what went wrong by just eye-balling the patches, I did find that the problem results from netrwPlugin.vim. Basically, netrw registers this autocommand: au BufEnter .* silent! call s:LocalBrowse(expand(amatch)) When it is executed on a buffer switch, sometimes this amatch is emty. I've no idea why. If I remove the netrw plugin, things go back to normal. I did notice that netrw plugin changed recently... -d -- // mailto: Denis Perelyubskiy lists at overwhelmTAKECAPITALSOUT dot net // icq : 12359698
Re: patch 182 and selectbuf [interferes with netrw plugin]
Denis Perelyubskiy wrote: Thanks. While I can't tell what went wrong by just eye-balling the patches, I did find that the problem results from netrwPlugin.vim. Basically, netrw registers this autocommand: au BufEnter .* silent! call s:LocalBrowse(expand(amatch)) When it is executed on a buffer switch, sometimes this amatch is emty. I've no idea why. If I remove the netrw plugin, things go back to normal. I did notice that netrw plugin changed recently... Can you give me an example? Also, what o/s are you using? The s:LocalBrowse() function checks if the name passed to it is a directory. Except for the Amiga, an empty string should be getting ignored (isdirectory() is zero). Regards, Chip Campbell
Re: BOF Vim 8 - Suggestions
John Beckett wrote: [...] Then, I could write an email to a friend saying Run gvim and do stuff to select a theme. Then you can press F11 to do clever thing. For example, perhaps F11 = :cn, Shift-F11 = :cp. [...] This sounds very like file types. When you are opening a file appropriate actions can be done automatically in order to adjust vim or you can do it yourself. So your do stuff to select a theme is spelled in vim like :set ft=file type. If you are writing an e-mail and you have vim set as your e-mail text editor it is possible that vim will detect you are writing an e-mail and will automatically adjust itself for e-mail editing. You may also add additional file types by downloading them from vim.org or somewhere else... So, most part of a file type specific settings should reside in a file type script. And if you have some general preferences them you should add them to your .vimrc. If a preference is file type specific you can add a FileType event to your .vimrc. I see no point in adding themes. As for me, everything that can be done using themes can already be done using things that already exists in vim. If you think that you can provide a better defaults for novice users you can just write a script that will adjust vim the way you see it and ask Bram to add it into the distribution along with a note in the tutor, like If you feel that vim is too difficult to master you may try another set of defaults specially crafted for novice users. In order to turn them on just add the following line to your .vimrc: here goes command to source your script.
Re: patch 182 and selectbuf [interferes with netrw plugin]
On Fri, 19 Jan 2007 16:14:59 -0500, Charles E Campbell Jr
[EMAIL PROTECTED] said:
Denis Perelyubskiy wrote:
If I remove the netrw plugin, things go back to normal. I did notice
that netrw plugin changed recently...
Can you give me an example? Also, what o/s are you using?
The s:LocalBrowse() function checks if the name passed to it is a
directory.
Except for the Amiga, an empty string should be getting ignored
(isdirectory()
is zero).
Charles, I am on WinXP. I think the problem is this:
If you look at the function I included below, there is an 'echomsg
dirname.dirname. '. When dirname is empty, this call fails.
Removing this call solves the problem as far as I can tell so far...
LocalBrowse: {{{2
fun! s:LocalBrowse(dirname)
unfortunate interaction -- debugging calls can't be used here;
the BufEnter event causes triggering when attempts to write to
the DBG buffer are made.
echomsg dirname.dirname.
if has(amiga)
The check against '' is made for the Amiga, where the empty
string is the current directory and not checking would break
things such as the help command.
if a:dirname != '' isdirectory(a:dirname)
silent! call netrw#LocalBrowseCheck(a:dirname)
endif
elseif isdirectory(a:dirname)
echomsg dirname.dirname. isdir
silent! call netrw#LocalBrowseCheck(a:dirname)
endif
not a directory, ignore it
endfun
--
// mailto: Denis Perelyubskiy lists at overwhelmTAKECAPITALSOUT dot net
// icq : 12359698
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: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. I don't understand what you're trying to say in the first part of your sentence. I promise the list that I won't post about this again, but FWIW I'm not telling you how I work, I'm describing how most people in the business say they work (from talking to people, and following lists etc). Most networks have lots of devices which require accounts. A router, a firewall, a mail server, ten other servers, etc. Then there are your various email accounts - some important, some junk. Single sign-on can integrate many, or even most of these. But not all. So, most network admins need to record all the account details, possibly with notes, e.g. just how do you log on to that wireless access point that you last configured six months ago. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. Given that you're going to reveal the password to anyone with a knife, there doesn't seem to be much point in having bullet proof security. I'm sure many people do as you suggest, but take it from me that many other people do not use the same password on their firewall and their mail server etc. So it's better to use one good password/passphrase and stick with it. Diceware is a really nice system: http://www.diceware.com/ John
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: BOF Vim 8 - Suggestions
Ilya Bobir wrote: If you think that you can provide a better defaults for novice users you can just write a script that will adjust vim the way you see it and ask Bram to add it into the distribution along with a note in the tutor OK. Perhaps that would handle the issue. I don't care how it's done, my aim is just to make the suggestion that to popularise Vim, it would be helpful to provide easily-accessible and well-thought-out defaults for some of Vim's more clever features. John
Re: BOF Vim 8 - Suggestions
Bram Moolenaar wrote: No, I don't want that. Pressing ESC is to get back to Normal mode, it should not have side effects like this. OK. But my suggestion was not that ESC would go to Normal mode _and_ clear highlighting. My proposal was that if I start in Insert mode, then press ESC I would be in Normal mode (as normal :), but if I press ESC again then highlighting and message text would be cleared. I'm happy so long as you've heard my idea. A couple of people here seem to think that _I_ want these suggestions. Not at all. I'm fluent in Vim and don't need any of my proposals for myself. But my recent experience of trying to make Vim attractive to a programmer moving into Linux showed me that some simple changes to Vim might make it a lot more attractive to new users. You appear to assume that what you want is what everybody wants. No! For posterity let me record that I am not one of those people. I'm only making these suggestions because I know you want to promote Vim usage, and some way to easily invoke a pre-defined set of behaviour for a modern PC would help IMHO. Imagine how many exceptions we need to handle in the documentation: if you use theme X then this doesn't work and you need to type XYZ. I take your point and agree. But I will make one final suggestion: Do not hide how Vim works. Tell users about vimrc, and what a mapping is, etc. People who would use Vim are smart, and can instantly understand that there is a config file, and that keys can be mapped. But a new user will probably not want to take the time to work out the details and their optimum settings right now. Take the wonderful quickfix window (which I use mainly for vimgrep). Using quickfix with ':copen' etc just doesn't work for me. I don't mind typing a few commands, but in this situation, the commands interfere too much with my thoughts. Once I mapped keys for :copen, :cn and :cp, quickfix was a magnificent feature. My vague concept about a theme is that it would insert text into vimrc. The user would be told this, and they could modify the text to taste. Right now, it is pretty easy to get BufExplorer working, and then \be is the default key sequence to start it. That's like what I am proposing for other killer features of Vim. You can always tell someone to download your script and use it. There are too many tips and scripts already. I was hoping (*not* for me!) to integrate some of the best work procedures into one or two pre-defined behaviours. John
Re: BOF Vim 8 - Suggestions
John Beckett wrote: Bram Moolenaar wrote: No, I don't want that. Pressing ESC is to get back to Normal mode, it should not have side effects like this. OK. But my suggestion was not that ESC would go to Normal mode _and_ clear highlighting. My proposal was that if I start in Insert mode, then press ESC I would be in Normal mode (as normal :), but if I press ESC again then highlighting and message text would be cleared. I'm happy so long as you've heard my idea. A couple of people here seem to think that _I_ want these suggestions. Not at all. I'm fluent in Vim and don't need any of my proposals for myself. But my recent experience of trying to make Vim attractive to a programmer moving into Linux showed me that some simple changes to Vim might make it a lot more attractive to new users. You appear to assume that what you want is what everybody wants. No! For posterity let me record that I am not one of those people. I'm only making these suggestions because I know you want to promote Vim usage, and some way to easily invoke a pre-defined set of behaviour for a modern PC would help IMHO. Imagine how many exceptions we need to handle in the documentation: if you use theme X then this doesn't work and you need to type XYZ. I take your point and agree. But I will make one final suggestion: Do not hide how Vim works. Tell users about vimrc, and what a mapping is, etc. People who would use Vim are smart, and can instantly understand that there is a config file, and that keys can be mapped. But a new user will probably not want to take the time to work out the details and their optimum settings right now. Take the wonderful quickfix window (which I use mainly for vimgrep). Using quickfix with ':copen' etc just doesn't work for me. I don't mind typing a few commands, but in this situation, the commands interfere too much with my thoughts. Once I mapped keys for :copen, :cn and :cp, quickfix was a magnificent feature. It took me quite some time to get around to finding out how to use the quickfix window. I would venture that a beginning user can blissfully ignore it and concentrate on the basic :help keyword command, the normal-mode yank, put and delete command, and on switching between Normal, Insert and maybe Replace modes. Then Visual. Then 'wildmode', 'wildmenu' and filename / helptag completion. Once the usefulness of :helpgrep reaches consciousness, then it's time to read quickfix.txt more attentively. My solution is just :map F2 :cnCR :map S-F2 :cNCR but what is best for me is not necessarily best for the next guy. My vague concept about a theme is that it would insert text into vimrc. The user would be told this, and they could modify the text to taste. Right now, it is pretty easy to get BufExplorer working, and then \be is the default key sequence to start it. That's like what I am proposing for other killer features of Vim. Rather than insert text into vimrc, source the script from the vimrc. The result is the same, but it's much easier to implement -- and to undo if, six months or two years later, you decide it's not so great after all. You can always tell someone to download your script and use it. There are too many tips and scripts already. I was hoping (*not* for me!) to integrate some of the best work procedures into one or two pre-defined behaviours. John This approach has already been attempted, not just once as Bram said, but at least twice (evim and mswin.vim), and the results are far from convincing: easy vim is actually harder to use, and mswin.vim makes some useful Vim features inacessible, and for others, forces constant reminders everywhere in the help and in support mailing lists: If you use Ctrl-V to paste, use Ctrl-Q instead whenever the help says to use Ctrl-V. Cream for Vim may be a third attempt but I'm not sure, I haven't looked into it. Best regards, Tony.
