[vim/vim] CTRL-F should NOT be redefined by default in mswin.vim (#2093)
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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Christian Brabandt
Closed #2093.
Christian Brabandt
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?
Christian Brabandt
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?
Tony Mechelynck
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. ;-)
Christian Brabandt
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
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 <notifi...@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. ;-)
>
> —
> Reply to this email directly, view it on GitHub
> the thread
> <https://github.com/notifications/unsubscribe-auth/AUEIyy31I5xl5A7kc72qIvbOoRaO0fxAks5sildtgaJpZM4PYsWs>
Tony Mechelynck
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 When I want to page down, I use which is also a default binding of vanilla Vim.
IOW: YMMV
Best regards,
Tony.
Christian Brabandt
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
plbowers
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
> Reply to this email directly, view it on GitHub
> 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.)
plbowers
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)
mswin_windows.vim (c-tab, c-f4)
mswin_system.vim (M-Space)
mswin_undo.vim (c-z, c-y)
mswin_selectall.vim (c-a)
mswin_find.vim (c-f, c-h)
mswin_save.vim (c-s)
And then mswin.vim itself contained this text:
===(snip)===
" This file (mswin.vim) controls various aspects of Microsoft Windows compatibility in terms of mapping
" keys to actions that may feel more "normal" to MS Win users.
" To comment a line out (make it inactive), place a double-quote on the line at the very beginning
" To uncomment a line (make it active), remove the 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
" lost by making these key mappings active.
" 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
" source $VIMRUNTIME/mswin_clipboard.vim
" 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
" source $VIMRUNTIME/mswin_save.vim
" 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
" source $VIMRUNTIME/mswin_windows.vim
" 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
" source $VIMRUNTIME/mswin_system.vim
" 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
" source $VIMRUNTIME/mswin_undo.vim
" 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
" source $VIMRUNTIME/mswin_selectall.vim
" If you want CTRL-f to open a search dialog and CTRL-h to open a search/replace dialog then either uncomment the line below or copy it into your ~/.vimrc - without this CTRL-f executes a page-down and CTRL-H edits the file or directory hiding list
" source $VIMRUNTIME/mswin_find.vim
behave mswin
===(snip)===
And then in the ~/.vimrc start with a default something like this:
===(snip)===
" Some keystrokes operate fairly consistently across many MS Win programs but work differently in
" vim. If you wish to redefine these key mappings so they reflect normal MS Win usage then please
" edit $VIMRUNTIME/mswin.vim and follow the instructions there.
" (Note that $VIMRUNTIME in windows is typically "C:\Program Files (x86)\Vim\Vim80")
" (Note that $VIMRUNTIME/mswin.vim normally requires administrative access to edit it and will
" often not be backed up and so you may prefer the option of copying lines here from that file
" rather than editing that file.)
source $VIMRUNTIME/mswin.vim
" If you wish to change the font for your gVim windows, uncomment this line and edit it to match
" the font-face and font-size that you prefer (the setting below is suitable for high-res monitors such
" as the MS Surface Pro or others)
" set guifont=Consolas:h12
" If you wish to remove the row of icons in gVim (on high-res monitors these are often too small
" to be useful) you can uncomment the following line:
" set guioptions-=T
===(snip)===
Undoubtedly there are numerous other potential lines (with a concise bit of documentation above) which may be helpful to have in the default ~/.vimrc.
plbowers
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.
Bram Moolenaar
> I confirm that after doing a complete uninstall and reinstall of vim
> (without making any choices wrt mswin.vim) I have c:\Program Files
>
> 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.
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 -- Br...@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 ///
Christian Brabandt
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.
Bram Moolenaar
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 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 -- Br...@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 ///
—
fritzophrenic
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 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.
Tony Mechelynck
@brammool wrote:
I doubt anyone would still want to run the DOS installer directly.
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 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.
I used to say that too, starting with just
runtime vimrc_example.vim
then adding customizations as the need was felt. Now that defaults.vim is sourced if no vimrc is found, however, creating one's own vimrc is still useful (with the same starting point, since the present vimrc_example.vim has become hardly more than a wrapper around defaults.vim), but it is much less necessary. It could even be argued that only power users need a vimrc nowadays, though I would encourage every Vim user to learn as much about Vim as (s)he can, and, with time and perseverance, to become more and more a power user without really feeling any definite threshold.
Christian Brabandt
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:
K.Takata
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.
You can download the installer from here: https://ci.appveyor.com/project/k-takata/vim-win32-installer/build/job/eadgvp3tubki421t/artifacts
If a user select "Create a _vimrc if it doesn't exist" in the "Installation Options" page:
the following page will be shown:
-
Key remapping
- Do not remap keys for Windows behavior
If this is selected, mswin.vim is not sourced. - Remap a few keys for Windows behavior (<C-V>, <C-C>, etc)
If this is selected, mswin.vim is sourced.
- Do not remap keys for Windows behavior
-
Mouse behavior
- Right button extends selection (unix)
If this is selected,behave unixis added to the default _vimrc. - Right button has a popup menu, Left button starts selection (mswin)
If this is selected,behave mswinis added to the default _vimrc. - Right button has a popup menu, Left button starts visual mode
If this is selected,behaveis not added to the default _vimrc.
- Right button extends selection (unix)
(I'm not sure which settings should be the default. Currently, they are the same as the official installer.)
K.Takata
Patches are available at here:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/2241683617e8eb6ee1491164eeb5bfa832542745/win32-install-gvimext3264.patch?at=default
https://bitbucket.org/k_takata/vim-ktakata-mq/src/2241683617e8eb6ee1491164eeb5bfa832542745/win32-installer-vimrc-options.patch?at=default
Actually, the former patch is a patch for another purpose, but this is needed to apply the latter one.
K.Takata
Created an issue for the former patch: vim/vim#2144
K.Takata
The "_vimrc setting" page is created by the Install Options 2 plugin.
Christian Brabandt
Reopened #2093.
Christian Brabandt
I would say, make "do not remap keys for windows behaviour" the default.
plbowers
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 (, , 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 that had me concerned and the 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!
OldSoldier
发自网易邮箱大师
On 9/15/2017 18:54，Tony Mechelynck<notifi...@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. ;-)
—
K.Takata
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
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)
plbowers
-Peter
On Tue, Oct 3, 2017 at 7:02 PM, K.Takata <notifi...@github.com> 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]
>
> 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
> the thread
> <https://github.com/notifications/unsubscribe-auth/AUEIy2XVbLhKzpR99Mu3uLwlN-TqY2Fhks5somipgaJpZM4PYsWs>
> .
K.Takata
Bram Moolenaar
Closed #2093.
Bram Moolenaar
Taken care of by patch 8.0.1232
Thomas Michaud
mswin.vim deleted causes a popup error when starting vim. But other than that...problem fixed.
Christian Brabandt
mswin.vim deleted causes a popup error when starting vim. But other than that...problem fixed.
You could have added a simple :finish at the top of the file :) However with newer versions mswin.vim is fixed.
Hugo Toledo
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!
Michael Brown
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). This was a bad idea from the start.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
K.Takata
remapping CTRL-F to PgDwn in gvim is HORRIBLE.
Do you mean remapping CTRL-F to find?
This just happened in vim 8.2 right?
No, it happened before 8.1.
mswin.vim was changed to map Ctrl-F to find, and the installer was changed not to source mswin.vim in the system _vimrc by default.
IMO, mswin.vim is mainly for beginners who don't know how to write .vimrc.
If an intermediate user still want to use Windows style key mappings, they should source mswin.vim in the .vimrc explicitly, and if they don't want to remap only Ctrl-F, they should add unmap <C-F> after sourcing mswin.vim.
Expert users may not need mswin.vim anymore.
Christian Brabandt
@mbrown9764 if you do not want standard windows keybindings, do not source mswin.vim.
fritzophrenic
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.
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.
Mat Bess
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.
This is how Vim is supposed to work. Stop using it wrong 😆
Mat Bess
@mbrown9764 if you do not want standard windows keybindings, do not source mswin.vim.
Use notepad if you want windows keybindings 😂