delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2012/10/08/08:15:43

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <5072C3D9.6010301@cs.utoronto.ca>
Date: Mon, 08 Oct 2012 08:15:21 -0400
From: Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RFE: make non-x11 emacs mouse-aware
References: <5069E59E DOT 606 AT cs DOT utoronto DOT ca> <5069ECE7 DOT 1030704 AT cornell DOT edu> <5069FD14 DOT 8040705 AT cs DOT utoronto DOT ca> <506A10F8 DOT 5090201 AT cornell DOT edu> <5071A1C0 DOT 70403 AT cornell DOT edu> <5072B1F6 DOT 6000409 AT cs DOT utoronto DOT ca> <CAHWeT-adkGVOMhNDrJ==s81NoPAJDoG-b8iVoiuPJvU+DPCXeA AT mail DOT gmail DOT com>
In-Reply-To: <CAHWeT-adkGVOMhNDrJ==s81NoPAJDoG-b8iVoiuPJvU+DPCXeA@mail.gmail.com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 08/10/2012 7:54 AM, Andy Koppe wrote:
> On 8 October 2012 11:59, Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca> wrote:
>> On 07/10/2012 11:37 AM, Ken Brown wrote:
>>> On 10/1/2012 5:54 PM, Ken Brown wrote:
>>>> On 10/1/2012 4:29 PM, Ryan Johnson wrote:
>>>>> On 01/10/2012 3:20 PM, Ken Brown wrote:
>>>>>> On 10/1/2012 2:49 PM, Ryan Johnson wrote:
>>>>>>> Hi all, esp. emacs maintainer(s),
>>>>>>>
>>>>>>> I'd like to request that the non-x11 emacs be made mouse aware. Right
>>>>>>> now, terminal mouse mode is broken in normal emacs because the emacs
>>>>>>> core doesn't recognize the resulting mouse events. You can use
>>>>>>> emacs-x11
>>>>>>> in terminal mode as a heavyweight workaround, but it turns out that
>>>>>>> mouse awareness is controlled by the src/config.h file created by
>>>>>>> ./configure:
>>>>>>>> /* Define if you have mouse support. */
>>>>>>>> /* #undef HAVE_MOUSE */
>>>>>>>
>>>>>>> There doesn't seem to be an explicit configure switch for it (it's
>>>>>>> enabled indirectly by --with-x11 or --with-ns), but editing directly
>>>>>>> produced the desired results on a headless linux machine, with no
>>>>>>> undesirable side effects so far. I see no reason it shouldn't also
>>>>>>> work
>>>>>>> under cygwin.
>>>>>>
>>>>>> I'd be happy to do it if I could be sure there were no bad side
>>>>>> effects.  But I never use emacs-nox, so it isn't easy for me to test
>>>>>> it on a long-term basis.  Maybe you should build it yourself and
>>>>>> report back.
>>>>> As noted, I have tested on a headless linux machine, with no problems so
>>>>> far (several days). There seems to be a clean division between the
>>>>> window management and the mouse handling code. This makes sense, because
>>>>> the mouse events themselves are handled by keymaps and such, in elisp
>>>>> land, while the generation of those events is deeper and varies
>>>>> depending on their source (X11, NS, terminal).
>>>>>
>>>>> If you worry that cygwin might behave differently than linux, I could
>>>>> build emacs locally and test as well, but I don't expect any difference.
>>>>>
>>>>>> And can you be more specific about what you expect emacs to do with
>>>>>> mouse events when it's running in a terminal?  I thought mintty
>>>>>> captured mouse events.  In particular, when I run emacs-x11 under
>>>>>> mintty, C-h k <mouse-click> produces no response; the cursor stays in
>>>>>> the minibuffer, and emacs continues to wait for me to press a key.
>>>>>> Running under X, however, emacs does see the mouse click in that same
>>>>>> situation.  For another example, if I run emacs-x11 under mintty, I
>>>>>> can highlight text with the mouse and then paste it with
>>>>>> shift-insert.  But again it's mintty doing the work, not emacs.
>>>>> On any emacs, xterm-mouse-mode puts the terminal in mouse-reporting mode
>>>>> and starts watching stdin for the xterm mouse escape sequences: left,
>>>>> right, scroll, modifier keys, anything the terminal makes available
>>>>> (most xterm-like terminals intercept shift + mouse, for example). You
>>>>> can peek in xt-mouse.el to see how mouse escapes are turned into
>>>>> appropriate mouse events, but that's not really important here. The
>>>>> issue is that emacs-nox doesn't know what to do with '<mouse-1>' etc
>>>>> that it suddenly starts receiving. I suppose you could manually wire up
>>>>> all the various events by hand, but on emacs-x11 they're already there
>>>>> (even in terminal mode) and terminal-generated mouse events work out of
>>>>> the box.
>>>>
>>>> I didn't know about xterm-mouse-mode.
>>>>
>>>> OK, I've built emacs-nox with mouse support, and it works, as far as I
>>>> can tell.  I'll upload it as a test release after I've tested it a
>>>> little more.
>>>
>>> Before going ahead with this, I decided to ask for comments on the
>>> emacs-devel list, to make sure no one could see a downside.  This led to a
>>> question about your tests on Linux.  The default on Linux is to provide
>>> mouse support in a terminal via GPM (which is not available on Cygwin).  Did
>>> you explicitly disable GPM when you built emacs for Linux?  If not, then
>>> your tests may not be an accurate indication of what will happen on Cygwin.
>> I'm sorry, my test machine was actually running Solaris, so GPM was
>> definitely disabled... mixed up which VM guest on my laptop I was using,
>> sorry. I redid the tests with a non-VM Ubuntu 11 machine, and AFAICT GPM is
>> *not* the default, at least with emacs-24.2. Neither HAVE_GPM nor HAVE_MOUSE
>> was defined, and (unsurprisingly) mouse clicks under xterm-mouse-mode mouse
>> give the error: "<mouse-1> is undefined." Manually defining HAVE_MOUSE and
>> recompiling fixed the problem.
>>
>> In any case, I thought GPM was only useful in console mode?
> Apparently the gpm client library can not only connect to a gpm server
> handling mouse events in a Linux console, but it can also translate
> xterm mouse events, and present the same API with both approaches.
> Alas, there's no gpm client library package for Cygwin, and I don't
> know whether it can be built for Cygwin.
AFAICT, we don't strictly need it in cygwin, at least not for emacs. GPM 
wraps up xterm sequences to look like console mouse events, but (a) 
there's no console in cygwin and (b) emacs is perfectly happy to consume 
the xterm sequences directly.

There is one potential benefit to GPM support, though: IIUC, it would 
make terminal mouse events into first-class citizens (= processed by 
hard-wired C code before the GUI and keyboard events are merged into the 
generic event stream the lispy side of emacs sees). As it stands, 
xterm-mouse mode can emulate selection via mouse drag, but cannot easily 
replicate double-click semantics; further, emacs' keymap abstraction is 
completely incompatible with URXVT mouse-mode events, so that mode will 
probably never be supported directly (though SGR mouse mode, which emacs 
*can* be made to handle, is superior anyway IMO).

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019