Mouse control in a "Quick Edit mode" Windows console
Jean Johner
Mouse control is lost in Windows console Vim when "Quick Edit mode" is
activated (see vim_use: "Is there a way to have mouse control in a
"Quick Edit mode" Windows console?").
Could a modification in Vim code solve this problem or is it hopeless?
Best regards.
Jean Johner
Bram Moolenaar
Jean Johner wrote:
> Mouse control is lost in Windows console Vim when "Quick Edit mode" is
> activated (see vim_use: "Is there a way to have mouse control in a
> "Quick Edit mode" Windows console?").
>
> Could a modification in Vim code solve this problem or is it hopeless?
I guess that in this mode Vim doesn't get the mouse events. If that is
indeed so there is nothing we can do.
What system has this mode? My XP system only has Edit/Mark, Edit/Paste
and thelike.
--
hundred-and-one symptoms of being an internet addict:
58. You turn on your computer and turn off your wife.
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
Jean Johner
> What system has this mode? My XP system only has Edit/Mark, Edit/Paste
> and thelike.
>
I have Windows XP SP3 (French version).
Clicking the "C:\" icon at the left top corner of a cmd.exe console
window proposes Properties/Options/Edition Options with Quick Edit
mode and Insert mode check boxes.
With Quick Edit mode activated, copy/paste is simply obtained by
double-click + right mouse twice (comparable to unix behaviour).
You mention yourself this "Quick Edit mode" in Help/os_win32.txt, line
112 !
I am afraid this option completely captures mouse events.
Best regards
Jean Johner
Benjamin R. Haskell
>
> Jean Johner wrote:
>
> > Mouse control is lost in Windows console Vim when "Quick Edit mode"
> > is activated (see vim_use: "Is there a way to have mouse control in
> > a "Quick Edit mode" Windows console?").
> >
> > Could a modification in Vim code solve this problem or is it hopeless?
>
> I guess that in this mode Vim doesn't get the mouse events. If that
> is indeed so there is nothing we can do.
That's what it seems like from testing (as stated in the vim_use thread)
via i_Ctrl-Q. My mention of code modification was probably optimistic.
I just thought 'cmd' might have some kind of mouse-related terminal
control sequences.
> What system has this mode? My XP system only has Edit/Mark,
> Edit/Paste and thelike.
I don't have an XP system handy. Windows 7 and Windows Server 2003 have
it.
You have to right-click the 'cmd' window's title bar, and choose
'Properties' to get to the 'Edit Options' section. (Right-clicking in
the text area gives choices similar to what you mention.)
--
Best,
Ben
John Beckett
> Mouse control is lost in Windows console Vim when "Quick Edit
> mode" is activated (see vim_use: "Is there a way to have mouse
> control in a "Quick Edit mode" Windows console?").
You have had some "probably not" replies, so let me be more
definite. You are talking about Windows command prompt, where
you can right-click a command prompt title bar and choose
Properties, Options tab, "QuickEdit Mode".
The whole point of QuickEdit Mode is that the operating system
will handle mouse events, and will NOT pass them to the
application runnning in the command prompt window. There is
NOTHING an application like Vim can do to use the mouse under
those conditions.
You can make a Windows shortcut that opens command prompt with
QuickEdit mode off, and makes the window the size you want, and
uses something like Ctrl-Alt-V to open, then do all your editing
there (other command prompts can have QuickEdit mode on).
BTW using gvim is better once you choose a suitable color scheme
and get used to it.
John
Jean Johner
>
> You have had some "probably not" replies, so let me be more
> definite. You are talking about Windows command prompt, where
> you can right-click a command prompt title bar and choose
> Properties, Options tab, "QuickEdit Mode".
>
> The whole point of QuickEdit Mode is that the operating system
> will handle mouse events, and will NOT pass them to the
> application runnning in the command prompt window. There is
> NOTHING an application like Vim can do to use the mouse under
> those conditions.
>
> You can make a Windows shortcut that opens command prompt with
> QuickEdit mode off, and makes the window the size you want, and
> uses something like Ctrl-Alt-V to open, then do all your editing
> there (other command prompts can have QuickEdit mode on).
>
> BTW using gvim is better once you choose a suitable color scheme
> and get used to it.
>
> John
Thank you John, that is clear.
1/ However, as a user, I see that a "QuickEdit mode" command prompt
windows behaves more or less like all unix terminals (plus Mintty in
Cygwin). With these terminals, mouse selection is active at the
command prompt (allowing quick copy/paste of file names), but these
terminals are able to give back mouse control to Vim when the later
is
launched inside the terminal with "set mouse=a".
Why is Windows "QuickEdit mode" command prompt unable to do the same?
That seems incredible.
2/ Thank you for the tips. However using multiple consoles is
complicated for me (see below).
3/ I use Windows command prompt to launch Cygwin ssh to connect to a
distant unix server over a slow ADSL connection. In these conditions,
Vim is quick if it launched in the original command prompt.
Of course, I could launch gvim if I connect with ssh -X (with XWin
active), but as you know, X11 is very, very slow on Mbps range
connections.
That the reason why I am bound to console Vim (which colors I like,
except the blue) and why I would like to have both the comfort of
QuickEdit mode and mouse control in Vim.
BTW, I found recently that doing the same with Mintty yields all the
desired features.
The reason of my thread is that I was amazed that it was not possible
with cmd console (which is the default console in Cygwin).
Best regards
Jean Johner
John Little
> Why is Windows "QuickEdit mode" command prompt unable to do the same?
> That seems incredible.
requests mouse events to be passed to the app as escape sequences.
cmd.exe presumably lacks such a mechanism. It seems to be a bare-
bones terminal emulator; the solution would be to find a better one,
or use gvim.
Regards, John
Matt Wozniski
I'd personally highly recommend PuTTY over cmd.exe + cygwin ssh.
Cygwin is great for a lot of things, but setting up a Cygwin
environment just for ssh is like using a cruise missile to light a
cigarette. If you really want to work with Cygwin, I'd go with Cygwin
+ X11 + xterm + ssh... if you've got a full unix environment set up,
might as well use it. xterm is a much more feature-filled terminal
emulator than cmd.exe, and mouse support will Just Work for you with
both Cygwin/X + xterm and with PuTTY.
As far as colors go, CSApprox[1] is a great plugin. (Full disclosure,
I am the author). Assuming you have a 256 color terminal (both xterm
and PuTTY are), it does a fantastic job of making colorschemes in the
terminal look almost identical to how they look in gvim. If your
$TERM variable already advertises 256 color support, things usually
Just Work, and if not the only setup required is to get your terminal
to correctly set $TERM (or to kludge vim's setup to assume that $TERM
== 'xterm' always means 256 colors are available, for instance).
~Matt
Christian J. Robinson
> If you really want to work with Cygwin, I'd go with Cygwin + X11 +
> xterm + ssh... if you've got a full unix environment set up, might
> as well use it. xterm is a much more feature-filled terminal
> emulator than cmd.exe, and mouse support will Just Work for you with
> both Cygwin/X + xterm and with PuTTY.
Incidentally, I like to use Cygwin but I don't like running the X
server under Cygwin unless I have to, so I tend to use PuTTYCyg,
rather than X11 + xterm, found here:
https://code.google.com/p/puttycyg/
It has some quirks, but for the most part it works well for me--better
than using Cygwin's rxvt that can run with or without the X server.
Basically it's just PuTTY with the ability to run your Cygwin shell as
well as ssh/telnet/whatever.
For gVim, I usually just use a native Windows install.
- Christian
--
Christian J. Robinson <hep...@gmail.com> -- http://christianrobinson.name/
Corinna Vinschen
> On Sun, 15 Aug 2010, Matt Wozniski wrote:
>
> >If you really want to work with Cygwin, I'd go with Cygwin + X11 +
> >xterm + ssh... if you've got a full unix environment set up, might
> >as well use it. xterm is a much more feature-filled terminal
> >emulator than cmd.exe, and mouse support will Just Work for you
> >with both Cygwin/X + xterm and with PuTTY.
>
> Incidentally, I like to use Cygwin but I don't like running the X
> server under Cygwin unless I have to, so I tend to use PuTTYCyg,
> rather than X11 + xterm, found here:
> https://code.google.com/p/puttycyg/
>
> It has some quirks, but for the most part it works well for
> me--better than using Cygwin's rxvt that can run with or without the
> X server.
>
> Basically it's just PuTTY with the ability to run your Cygwin shell
> as well as ssh/telnet/whatever.
I suggest to take a look at mintty.
http://code.google.com/p/mintty/
It's an official part part of the Cygwin distro and the latest version
can always simply be updated to using the Cygwin installer at
http://cygwin.com
Mintty is an excellent replacement for the very old, very unsupported,
and very not-UTF-8 capable rxvt.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Jean Johner
> On Sat, Aug 14, 2010 at 10:27 PM, John Little wrote:
>
> I'd personally highly recommend PuTTY over cmd.exe + cygwin ssh.
> Cygwin is great for a lot of things, but setting up a Cygwin
> environment just for ssh is like using a cruise missile to light a
> cigarette. If you really want to work with Cygwin, I'd go with Cygwin
> + X11 + xterm + ssh... if you've got a full unix environment set up,
> might as well use it. xterm is a much more feature-filled terminal
> emulator than cmd.exe, and mouse support will Just Work for you with
> both Cygwin/X + xterm and with PuTTY.
Thank you Matt.
1/ Of course I tried PuTTY first, but I had the following problems for
which I found no work-arounds.
a/ When you launch Vim in you PuTTY terminal and want to go to the top
or bottom of your file in insert mode (with CTRL-Home, CTRL-End keys),
you quickly realize that these two essential keys are completely mute
(they do not even generate escape sequences that you could map).
Very annoying for me to type CTRL-O/gg and CTRL-O/G each time (I love
insert mode!).
b/ When you open a second tab with :tabe file2 and want to switch
quickly between the tabs, you type CTRL-PageUp or CTRL-PageDown and
you realize that these 2 essential keys are captured by PuTTY to show
the lines preceding the Vim information (not very useful in my
opinion).
Not very comfortable to click on the tabs (with Vim you become mouse
phobic!)
For the above 2 reasons, I abandonned PuTTY when I discovered its
cousin Mintty which does not suffer from the above flaws.
Following Corinna, I strongly recommend Mintty (a plus is that its
author, Andy Koppe, answers to all questions within 10 mns).
2/ Thank you for your suggestions concerning colors, I will have a
look.
3/ Cygwin X11 + xterm + ssh works but is a bit slower than Mintty and
has a little imperfection when launching Vim (on a slow connection,
you see characters displaying rapidly at the cursor position: not very
clean).
Best regards,
Jean Johner
Craig Barkhouse
It's possible to programmatically toggle QuickEdit mode. I think it would be quite reasonable for Vim to disable QuickEdit mode so that it has more complete control over the mouse. See if you like the following ptach. It disables QuickEdit when entering termcap mode if the mouse is enabled; and restores QuickEdit to its original value when leaving termcap mode.
diff.exe -c3 \TEMP\os_win32.c os_win32.c
*** \TEMP\os_win32.c 2010-08-19 12:22:28.580270500 -0700
--- os_win32.c 2010-09-01 14:20:08.999897000 -0700
***************
*** 1962,1967 ****
--- 1962,1969 ----
static ConsoleBuffer g_cbNonTermcap = { 0 };
static ConsoleBuffer g_cbTermcap = { 0 };
+ static DWORD g_cmiNonTermcap = 0;
+
#ifdef FEAT_TITLE
#ifdef __BORLANDC__
typedef HWND (__stdcall *GETCONSOLEWINDOWPROC)(VOID);
***************
*** 3433,3438 ****
--- 3435,3441 ----
return;
SaveConsoleBuffer(&g_cbNonTermcap);
+ GetConsoleMode(g_hConIn, &g_cmiNonTermcap);
if (g_cbTermcap.IsValid)
{
***************
*** 3462,3476 ****
resettitle();
#endif
! GetConsoleMode(g_hConIn, &cmodein);
#ifdef FEAT_MOUSE
if (g_fMouseActive)
cmodein |= ENABLE_MOUSE_INPUT;
else
cmodein &= ~ENABLE_MOUSE_INPUT;
#endif
cmodein |= ENABLE_WINDOW_INPUT;
! SetConsoleMode(g_hConIn, cmodein);
redraw_later_clear();
g_fTermcapMode = TRUE;
--- 3465,3484 ----
resettitle();
#endif
! cmodein = g_cmiNonTermcap;
#ifdef FEAT_MOUSE
if (g_fMouseActive)
+ {
cmodein |= ENABLE_MOUSE_INPUT;
+ cmodein &= ~ENABLE_QUICK_EDIT_MODE;
+ }
else
+ {
cmodein &= ~ENABLE_MOUSE_INPUT;
+ }
#endif
cmodein |= ENABLE_WINDOW_INPUT;
! SetConsoleMode(g_hConIn, cmodein | ENABLE_EXTENDED_FLAGS);
redraw_later_clear();
g_fTermcapMode = TRUE;
***************
*** 3483,3489 ****
static void
termcap_mode_end(void)
{
- DWORD cmodein;
ConsoleBuffer *cb;
COORD coord;
DWORD dwDummy;
--- 3491,3496 ----
***************
*** 3493,3501 ****
SaveConsoleBuffer(&g_cbTermcap);
! GetConsoleMode(g_hConIn, &cmodein);
! cmodein &= ~(ENABLE_MOUSE_INPUT | ENABLE_WINDOW_INPUT);
! SetConsoleMode(g_hConIn, cmodein);
#ifdef FEAT_RESTORE_ORIG_SCREEN
cb = exiting ? &g_cbOrig : &g_cbNonTermcap;
--- 3500,3506 ----
SaveConsoleBuffer(&g_cbTermcap);
! SetConsoleMode(g_hConIn, g_cmiNonTermcap | ENABLE_EXTENDED_FLAGS);
#ifdef FEAT_RESTORE_ORIG_SCREEN
cb = exiting ? &g_cbOrig : &g_cbNonTermcap;
Jean Johner
>
> It's possible to programmatically toggle QuickEdit mode. I think it would be quite reasonable for Vim to disable QuickEdit mode so that it has more complete control over the mouse. See if you like the following ptach. It disables QuickEdit when entering termcap mode if the mouse is enabled; and restores QuickEdit to its original value when leaving termcap mode.
So a code modification could solve the problem !
Congratulations Craig.
Best regards
Jean Johner