CTRL-F should NOT be redefined by default in mswin.vim

[plbowers]

Reference #1457 (comment)

CTRL-F is a vital keystroke to control vim - it provides the page-down behavior and without that I have to find the actual page-down key which takes my fingers off the home row.

Giving some way of easily configuring this for those that want to use CTRL-F for find is great, but don't make it the default.

If I want a full windows experience I will choose Notepad++ or something along those lines. Vim is for vimmers. Don't take away the beauty/elegance/efficiency of vim just because someone is used to a different keystroke on a non-vim platform.

[chrisbra]

mswin.vim is for providing typical windows shortcuts and it was specifically requested to add those key bindings there (see #1457). So we did that. If you don't like them, either do not use the provided mswin.vim or unmap your key bindings later. Sorry there is no best solution here, that pleases everybody.

[k-takata]

@chrisbra I don't have preference whether Ctrl-F should be mapped or not. However, unfortunately it doesn't work as intended on vim.exe as reported at #1457 (comment). It only works on gvim.exe.
What do you think of this?

[chrisbra]

Oh yes, forgot about this problem.
yeah, perhaps :promptfind should only be used in the gui. The question is then, should it be mapped to / in the console? or not at all?

[tonymec]

mswin.vim indeed adds several "Windows-like" mappings which hide very useful classical Vim key bindings, Ctrl-F is not the only one. For instance Ctrl-V becomes Paste instead of Blockwise-Visual, Ctrl-A becomes Select-All instead of Increment, Ctrl-X becomes Cut instead of Decrement, and so on and so forth.

IMHO mswin.vim is antipedagogical because it slows down acquisition of "standard" Vim reflexes, and therefore (still IMHO) its invention was a misguided idea. If anyone's vimrc invokes it, I would recommend to delete that source command.

This said, of course, do as you want; but under your own responsibility and at your own risk: don't come back weeping in my jacket if use of a misguided script gives unwanted results. ;-)

[chrisbra]

How about this patch to mswin.vim:

diff --git a/runtime/mswin.vim b/runtime/mswin.vim
index 6dff7e771..46d15f2cf 100644
--- a/runtime/mswin.vim
+++ b/runtime/mswin.vim
@@ -105,14 +105,15 @@ onoremap <C-F4> <C-C><C-W>c

 if has("gui")
   " CTRL-F is the search dialog
-  noremap <C-F> :promptfind<CR>
-  inoremap <C-F> <C-\><C-O>:promptfind<CR>
-  cnoremap <C-F> <C-\><C-C>:promptfind<CR>
-
-  " CTRL-H is the replace dialog
-  noremap <C-H> :promptrepl<CR>
-  inoremap <C-H> <C-\><C-O>:promptrepl<CR>
-  cnoremap <C-H> <C-\><C-C>:promptrepl<CR>
+  noremap  <expr> <C-F> has("gui_running") ? ":promptfind\<CR>" : "/"
+  inoremap <expr> <C-F> has("gui_running") ? "\<C-\>\<C-O>:promptfind\<CR>" : "\<C-\>\<C-O>/"
+  cnoremap <expr> <C-F> has("gui_running") ? "\<C-\>\<C-C>:promptfind\<CR>" : "\<C-\>\<C-O>/"
+
+  " CTRL-H is the replace dialog,
+  " but in console, it might be backspace, so don't map it there
+  nnoremap <expr> <C-H> has("gui_running") ? ":promptrepl\<CR>" : "\<C-H>"
+  inoremap <expr> <C-H> has("gui_running") ? "\<C-\>\<C-O>:promptrepl\<CR>" : "\<C-H>"
+  cnoremap <expr> <C-H> has("gui_running") ? "\<C-\>\<C-C>:promptrepl\<CR>" : "\<C-H>"
 endif

 " restore 'cpoptions'

It should be self-explaining, the point is, to only map <C-F> and <C-H> when the gui is running. That means for <C-F> in the console, we map it to a simple find command /, while for <C-H> we do not map it, since <C-H> might be backspace (at least this was on my cmd.exe) and backspace would then break terribly and unexpectedly.

[k-takata]

Sorry, I misunderstood something.
The comment #1457 (comment) says:

if I stroke ctrl+f in insert mode nothing happened and if I stroke ctrl+f in normal mode it displays :promptfind in the command line

However, when I try vim.exe v8.0.1067, Ctrl-f is not mapped and it works as next page.
has("gui") returns 0 on vim.exe.

[plbowers]

The difference is the level of expertise someone has to have in vim before they encounter these remapped commands. I used to teach vi and I started with the movement commands - j/k/h/l first, then ctrl-f/ctrl-b, then w/0/$, then counts, then on into insert/append, etc. In other words this CTRL-f is the 5th command someone learns in vi/vim - it's BASIC. Applied to engineering, replacing ctrl-x and ctrl-a is like quantum mechanics while replacing ctrl-f is like gravity. The one is something that people encounter and work with on a daily basis; the other is a relatively specialized command used by people who have achieved a fairly notable level of expertise. So if I use increment and decrement a couple times a week I use ctrl-f twice a minute while I'm editing. What process is used to determine what goes in here? Was there a process of checking with the community? Or did one person suggest it (I have no idea of #1457's level of expertise or involvement in the community) and it just got brought in because it was suggested?

…

-Peter

On Fri, Sep 15, 2017 at 12:54 PM, Tony Mechelynck ***@***.***> wrote: mswin.vim indeed adds several "Windows-like" mappings which hide very useful classical Vim key bindings, Ctrl-F is not the only one. For instance Ctrl-V becomes Paste instead of Blockwise-Visual, Ctrl-A becomes Select-All instead of Increment, Ctrl-X becomes Cut instead of Decrement, and so on and so forth. IMHO mswin.vim is antipedagogical because it slows down acquisition of "standard" Vim reflexes, and therefore (still IMHO) its invention was a misguided idea. If anyone's vimrc invokes it, I would recommend to delete that source command. This said, of course, do as you want; but under your own responsibility and at your own risk: don't come back weeping in my jacket if use of a misguided script gives unwanted results. ;-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2093 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUEIyy31I5xl5A7kc72qIvbOoRaO0fxAks5sildtgaJpZM4PYsWs> .

[chrisbra]

well at least 2 persons did suggest it and I don't think one has to provide some kind of proficiency with Vim before one is allowed to suggest an improvement. It seemed like a good idea to add some more windows like commands, so I suggested the patch which got finally included.

Back when this was suggested I basically thought nobody uses mswin.vim (or only when making the switch to Vim and later one does not use it anymore) so my reasoning was it would be beneficial for those few users that are too much used to the Windows shortcuts.

Now you are the second or third person complaining. Now let's see what we can do here.

Perhaps you can suggest how to make this whole interface more useful. Perhaps before remapping those keys, we can check, if a variable g_mswin_nomap_ctrl-f exists, so you could set it in your .vimrc and be done. I am actually not really sure, this would work because I don't know in which order your vimrc and mswin.vim are sourced.

So that should be found out first. And of course if we can come to an agreement here, a patch with corresponding documentation can be suggested.

That would still mean one has to read the documentation first before sourcing mswin.vim. So not sure if this would actually improve the situation.

Are there other opinions?

Disclaimer: I as many Vim users do not user mswin.vim, so I don't really care

[tonymec]

Well, I use Ctrl-A and Ctrl-X constantly (for instance when adding or removing a numbered item between two others) but I didn't even know what Ctrl-F was for until I looked it up a few minutes ago and found that it is a synonym for PgDown. When I want to page down, I use PgDown which is also a default binding of vanilla Vim.

IOW: YMMV

Best regards,
Tony.

[plbowers]

I just installed vim on a new computer - that's when I found out about this change. I didn't do anything to include msvim.vim - so at this point these changes are occurring by default on any new install (unless I did something weird that I don't remember during my installation procedure). One option would be to have this as an option intentionally chosen during the installation wizard. This has powerful potential, but obviously would have to be careful to not get carried away with it so that installation became a chore rather than something quick and easy. Always you have to go with the best defaults which I would say would probably not include mswin.vim, but that's my thought. Lots of installs have the "basic" or "custom" install where the custom gives a lot more options - that would seem to make sense for something like this. Another option would be to distribute/install a default ~/.vimrc - something that gives various popular options with some description before and some things commented in and some things commented out. So when people are installing on mswin and went in to look at their .vimrc it would be very obvious how to turn on these options (uncomment that line). If more people do like the ctrl-f to be search then similarly when someone went in to look at their .vimrc it would be very obvious how to go back to the standard - just read the descriptive comments and comment out that line. Another option could be mswin.vim and mswin2.vim where the first took it to a certain extent and the 2nd went beyond there. (Of course, there's gonna be differences of opinion of what is "beyond" - I would tend to say that since mswin.vim hasn't had a lot added in the last year then we should look for backwards compatibility to the greatest extent possible.) That gives "permission" for people to go crazy on making vim look just like editor X if they want it to... (Then 2-3 years down the line people will get used to mswin2.vim and when a change is made they won't like it, so this may not be a very scalable approach). Putting these mswin options in a separate gui menu might be a good way to move in that direction in a very user friendly way. Those who want to use raw vim never need to know about it, but those looking for the "softer" experience can easily look it up with the rest of the preference setting menus. So there's 3-4 options off the top of my head. I'll sleep on it and see if I can come up with some other ideas. I do think it would be worthwhile to have some kind of voting/polling mechanism in place to get some feedback from the community before changes to previous defaults occur. People expect their editors to continue to act the same unless there is a clear release note that announces/explains what/why the change is - the editor is such a basic piece it's a bit shocking to have unexpected changes thrown in without any notice...

…

-Peter

On Fri, Sep 15, 2017 at 5:47 PM, Christian Brabandt < ***@***.***> wrote: well at least 2 persons did suggest it and I don't think one has to provide some kind of proficiency with Vim before one is allowed to suggest an improvement. It seemed like a good idea to add some more windows like commands, so I suggested the patch which got finally included. Back when this was suggested I basically thought nobody uses mswin.vim (or only when making the switch to Vim and later one does not use it anymore) so my reasoning was it would be beneficial for those few users that are too much used to the Windows shortcuts. Now you are the second or third person complaining. Now let's see what we can do here. Perhaps you can suggest how to make this whole interface more useful. Perhaps before remapping those keys, we can check, if a variable g_mswin_nomap_ctrl-f exists, so you could set it in your .vimrc and be done. I am actually not really sure, this would work because I don't know in which order your vimrc and mswin.vim are sourced. So that should be found out first. And of course if we can come to an agreement here, a patch with corresponding documentation can be suggested. That would still mean one has to read the documentation first before sourcing mswin.vim. So not sure if this would actually improve the situation. Are there other opinions? Disclaimer: I as many Vim users do not user mswin.vim, so I don't really care — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2093 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUEIy24IrMEjgO7tNseqDw6-g9Gt1MYWks5sipwmgaJpZM4PYsWs> .

[plbowers]

I did a little code-reading and found that there is code (https://github.com/vim/vim/blob/master/src/dosinst.c) to ask the user if they want to install mswin.vim but it doesn't appear to be called during my install (I tried "Typical" which is the default and also "Custom" which I expected to give me lots of options - didn't give me anything).

[plbowers]

Another option would be to have instructions like this in the README that is presented upon installation.

I note that most of the current README is how to download/compile/install vim - that makes sense in a certain context, but when I just installed it and as the last step in the install I said I agreed to look at the README it doesn't make a lot of sense to talk about how to get/compile/install it on various platforms.

When an install is done on the MSWIN platform it would make sense to have a section in the README which talked about how to turn on/off various compatibility efforts. And there should be clear instructions how to pick and choose between them rather than an all-or-nothing type of approach.

[plbowers]

I confirm that after doing a complete uninstall and reinstall of vim (without making any choices wrt mswin.vim) I have c:\Program Files (x86)\Vim\_vimrc which contains the sourcing of mswin.vim.

Thus this is NOT a case of "most people will never be impacted by a change in mswin.vim" but rather "every user who installs on the mswin platform will either have to live with the decisions made in mswin.vim or else will have to explore/google to find out how to turn them off".

So the question becomes ... when someone comes to download and install vim should they get straight vim or should they get a modified vim? I would argue that people coming to get vim are looking for vim and should get it - at least there should be a question about it during the installation before we modify away from vanilla.

[plbowers]

I note the presence of vimrc_example.vim and defaults.vim - either of these could be places to include documentation about likely desirable changes based on mswin.vim.

However, probably most people will start looking in their own home directory rather than going into c:\Program Files...\ so I think that ~/.vimrc (or ~/_vimrc) is the better place to document these potentially desired configurations. I think that the actual sourcing of mswin.vim should occur there as well rather than in "C:\Program Files (x86)\Vim_vimrc" which is (a) hard to find, (b) not likely to be backed up/restored, and (c) requires admin privilege to edit it.

I note again that there is code in https://github.com/vim/vim/blob/master/src/dosinst.c to ask if the installer should create ~/.vimrc but it doesn't seem to be used in the windows installer. At least in my test install with Typical and with Custom (I didn't try minimal or full) there was no prompt for this. (Incidentally it's somewhat surprising that Typical and Custom seem to use the identical process - I saw no change at all between the 2 installatino procedures. That seems weird to the point of probably being a bug.)