CTRL-F should NOT be redefined by default in mswin.vim #2093
Comments
|
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. |
|
@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. |
|
Oh yes, forgot about this problem. |
|
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 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. ;-) |
|
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 |
|
Sorry, I misunderstood something.
However, when I try vim.exe v8.0.1067, Ctrl-f is not mapped and it works as next page. |
|
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>
.
|
|
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 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 |
|
Well, I use IOW: YMMV Best regards, |
|
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>
.
|
|
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). |
|
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. |
|
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. |
|
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.) |
|
This is the solution I would vote for... If $VIMRUNTIME/mswin.vim were divided into these pieces: mswin_clipboard.vim (c-c, c-x, c-v) And then mswin.vim itself contained this text: ===(snip)=== " To comment a line out (make it inactive), place a double-quote on the line at the very beginning " Read the comments carefully to understand what any changes will do and what key mappings will be " If you wish to use CTRL-x for cut, CTRL-c for copy, and CTRL-v for paste then either uncomment the following line or copy it into your ~/.vimrc - without this CTRL-x decrements the next number on the current line, CTRL-c interrupts an ongoing search, and CTRL-V enters visual block mode " If you want CTRL-s to save your file then either uncomment the line below or copy it into your ~/.vimrc - without this CTRL-s is not mapped to anything " If you want ctrl-tab to move to the next tab/window and ctrl-f4 to close the current tab/window then either uncomment the line below or copy it into your ~/.vimrc - without this CTRL-tab will toggle a netrw window and CTRL-f4 is not defined " If you want ALT-Space to open the system menu on your vim window then either uncomment the line below or copy it into your ~/.vimrc - without this ALT-space is not defined " If you want CTRL-z to undo and CTRL-y to redo then either uncomment the line below or copy it into your ~/.vimrc - without this CTRL-z either suspends vim (like :stop) or inserts a normal ctrl-z character and CTRL-y scrolls the current window (n) lines up in the buffer " If you want CTRL-a to select all then either uncomment the line below or copy it into your ~/.vimrc - without this CTRL-a will increment the next number on the current line behave mswin And then the ~/.vimrc would be initialized upon installation with a default something like this: ===(snip)=== " If you wish to change the font for your gVim windows, uncomment this line and edit it to match " If you wish to remove the row of icons in gVim (on high-res monitors these are often too small Undoubtedly there are numerous other potential lines (with a concise bit of documentation above) which may be helpful to have in the default ~/.vimrc. Maybe even a source of some education - showing how to map a keystroke, etc - probably following the tutorial (assuming it delves into settings). |
|
I note that the help screens (:help behave, :help mswin) indicates that mswin.vim modifies ONLY C-c, C-v, C-x for clipboard operations. If any other operations are added into mswin.vim then these should be appropriately documented in the help text. |
|
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.
Makes sense. It's very hard to predict if the user wants an MS-Windows
like editor, or the "real Vim". Asking seems to be the only way.
The dos installer already has the choice, but the NSIS one does not have
it. It only has "-create-vimrc". A similar choice for "use MS-Windows
key mappings for CTRL-C, CTRL-V, CTRL-F, etc."
…--
There are three kinds of persons: Those who can count and those who can't.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
I would rather say, remove the -create-vimrc from the installer at all. And perhaps mention that you can change defaults by running install.exe manually. |
|
Christian wrote:
I would rather say, remove the -create-vimrc from the installer at
all. And perhaps mention that you can change defaults by running
install.exe manually.
I doubt anyone would still want to run the DOS installer directly.
I think it's good to create a vimrc if there isn't one. It's a better
starting point when installing Vim on a new system.
…--
Fingers not found - Pound head on keyboard to continue.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
I still call it directly after self-compiling Vim. I don't remember why I started doing that but I know there was something that just copying files wasn't doing that the installer fixed. |
|
@brammool wrote:
If I were still on Windows, and not compiling my own, then of course I would use an installer, but Steve Hall's, which is slightly different from yours.
I used to say that too, starting with just then adding customizations as the need was felt. Now that |
|
For what its worth, I have just being bitten by this bug myself when using the installer a couple of times when installing Vim on several virtual machines. That behaviour is really confusing and unexpected for users. Perhaps we can for now at least disable sourcing the mswin.vim by default on Windows. diff --git a/src/dosinst.c b/src/dosinst.c
index 05398be..5bf1bd2 100644
--- a/src/dosinst.c
+++ b/src/dosinst.c
@@ -1159,14 +1159,6 @@ install_vimrc(int idx)
fprintf(fd, "source $VIMRUNTIME/vimrc_example.vim\n");
break;
}
- switch (remap_choice)
- {
- case remap_no:
- break;
- case remap_win:
- fprintf(fd, "source $VIMRUNTIME/mswin.vim\n");
- break;
- }
switch (mouse_choice)
{
case mouse_xterm: |
|
Shouldn't be this issue reopened? BTW, I'm working on this so that a user can select whether the default _vimrc should source mswin.vim. If a user select "Create a _vimrc if it doesn't exist" in the "Installation Options" page: the following page will be shown:
(I'm not sure which settings should be the default. Currently, they are the same as the official installer.) |
|
Patches are available at here: Actually, the former patch is a patch for another purpose, but this is needed to apply the latter one. |
|
Created an issue for the former patch: #2144 |
|
The "_vimrc setting" page is created by the Install Options 2 plugin. |
|
I would say, make "do not remap keys for windows behaviour" the default. |
|
Thanks, k-takata - the direction you're going looks great! Thanks for the time and effort! The current wording specifically mentions "Remap a few keys for Windows behavior (C-V, C-C, etc.)". I will mention again that being able to choose more specifically (I want clipboard-oriented remapping but not find nor system mapping) would be nice. I do, however, recognize that this could represent a lot more work if an elegant approach is not possible and the way it's going is much better than where it was. I would recommend that perhaps a longer list of keys be mentioned, including the C-F that had me concerned and the C-A that had others concerned. By adding just a few additional characters it will prevent people from being taken by surprise. Also I'll suggest again that whatever _vimrc (or .vimrc) is created during installation that it has a commented-out example of how to turn off this behavior for specific keys. That way someone can choose this behavior during installation but they can turn off the parts they don't like without a great deal of effort. Thanks again for your efforts on this, k-takata! Greatly appreciated! |
|
发自网易邮箱大师
On 9/15/2017 18:54，Tony Mechelynck<notifications@github.com> 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 are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I have updated the patch. Messages and defaults are changed.
|
|
Looks great to me!
…-Peter
On Tue, Oct 3, 2017 at 7:02 PM, K.Takata ***@***.***> wrote:
I have updated the patch.
https://bitbucket.org/k_takata/vim-ktakata-mq/src/
58b660d680cad20efae09eb82b4a208bbbb4cfb8/win32-installer-
vimrc-options.patch?at=default&fileviewer=file-view-default
[image: gvim-installer-page2-2]
<https://user-images.githubusercontent.com/840186/31137810-4ae05d98-a8a7-11e7-9ffb-fe8b689086e7.png>
Messages and defaults are changed.
-
Key remapping
- Do not remap keys for Windows behavior (Default)
- Remap a few keys for Windows behavior (<C-V>, <C-C>, <C-A>,
<C-S>, <C-F>, etc)
-
Mouse behavior
- Right button extends selection, left button starts visual mode (Unix)
- Right button has a popup menu, left button starts select mode
(Windows)
- Right button has a popup menu, left button starts visual mode
(Default)
—
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/AUEIy2XVbLhKzpR99Mu3uLwlN-TqY2Fhks5somipgaJpZM4PYsWs>
.
|
|
Taken care of by patch 8.0.1232 |
Problem: MS-Windows users are confused about default mappings.
Solution: Don't map keys in the console where they don't work. Add a choice
in the installer to use MS-Windows key bindings or not. (Christian
Brabandt, Ken Takata, closes #2093)
|
mswin.vim deleted causes a popup error when starting vim. But other than that...problem fixed. |
You could have added a simple |
Problem: MS-Windows users are confused about default mappings.
Solution: Don't map keys in the console where they don't work. Add a choice
in the installer to use MS-Windows key bindings or not. (Christian
Brabandt, Ken Takata, closes vim#2093)
Problem: MS-Windows users are confused about default mappings.
Solution: Don't map keys in the console where they don't work. Add a choice
in the installer to use MS-Windows key bindings or not. (Christian
Brabandt, Ken Takata, closes vim/vim#2093)
vim/vim@c3fdf7f
|
If I know my github well, I think I can post this without breaking anything. I'm just chiming in to say, you guys rock! I have thoroughly enjoyed reading this page. Sincerely. I've used vi since 1982 and can appreciate the passion folks have for it. I was surprised by CTRL-F behavior myself but it was easy -at least on 2018-08-29- to see where to disable the dialog box. Anyway, I just wanted to sneak in a thank you to all who use, comment on, contribute, develop, and otherwise support this great program. (I was just today asking how anyone goes through a day without using vi. :-) Cheers! |
|
Just my $0.02 - remapping CTRL-F to PgDwn in gvim is HORRIBLE. This just happened in vim 8.2 right? Used to work fine as it was in 8.1. Stupid change - the windows search is much less useful than standard regex (standard vim search). IMO this was a bad (misguided?) idea from the start. To anyone who uses standard vim key mappings CTRL-F / CTRL-U are absolutely essential for fast navigation. Please find something else to map the windows search dialog to by default. |
Do you mean remapping CTRL-F to find?
No, it happened before 8.1.
IMO, mswin.vim is mainly for beginners who don't know how to write .vimrc. |
|
@mbrown9764 if you do not want standard windows keybindings, do not source mswin.vim. |
Just to clarify, this isn't a "Windows search", it's a built-in command, ":promptfind". Which as others have pointed out, isn't actually mapped by default, unless you chose the installer option to do so. It's possible you have something in your .vimrc to source mswin.vim from back before this was added which you should now revisit. |
This is how Vim is supposed to work. Stop using it wrong 😆 I honestly end up using vim in the gitbash terminal most of the time because the gVim key remappings have been so obnoxious and it's easier to just open a terminal than it is to fix the bindings. Glad the decision was made to default to NOT remapping the keys during installation. EDIT: Ahh.. you meant mapping CTRL+F to opening a windows search dialog. Yes that is horrible -but- that means you are using the Windows keybindings. You should consider switching to the real Vim keybindings and use "/" for search. Stop torturing yourself with those messed-up Windows bindings, you'll be glad in the long run 😃 |
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.
The text was updated successfully, but these errors were encountered: