From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27141 invoked by alias); 13 Aug 2010 22:24:17 -0000 Received: (qmail 27131 invoked by uid 22791); 13 Aug 2010 22:24:16 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_05,TW_RX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from BACHE.ECE.CMU.EDU (HELO bache.ece.cmu.edu) (128.2.129.23) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Aug 2010 22:24:11 +0000 Received: from [192.168.0.2] (153-43.77-83.cust.bluewin.ch [83.77.43.153]) by bache.ece.cmu.edu (Postfix) with ESMTP id 8707EA1; Fri, 13 Aug 2010 18:24:09 -0400 (EDT) Message-ID: <4C65C607.8050008@ece.cmu.edu> Date: Fri, 13 Aug 2010 22:48:00 -0000 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Thomas Dickey CC: cygwin-xfree Subject: Re: Re: xterm and 7-bit control codes References: <20100812163131.V73121@mail101.his.com> In-Reply-To: <20100812163131.V73121@mail101.his.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2010-08/txt/msg00094.txt.bz2 On 8:59 PM, Thomas Dickey wrote: > As far as I know, xterm's never sent more than one byte for either x/y in > a button event. Ditto for rxvt. It sounds like a useful idea, except > that it would of course be incompatible with the existing applications. > So it would have to be enabled by a new control sequence. Hehe... very true about breaking existing apps. All those years ago the extra octet kick-started everything by confusing emacs (well, xterm-mouse-mode, really). I started looking at the character stream and reverse-engineered the above formula while trying to get rid of all the ascii garbage that polluted my buffers after stray mouse clicks. Only then did I realize I could exploit (rather than suppress) the extra octets to make large terminals behave better... > > (On the other hand, whatever application you were using at the time may > have translated the characters in that manner). I dug up an old .emacs, and it actually mentions gnu screen. If so, that's definitely been "fixed" because I specifically tested screen on several machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) before posting here. Any ideas what other terminal emulators I might test? Side note: how much pain would it be asking for if I tried to add the double-octet behavior to xterm as a feature? Would it be better to tackle rxvt? Or would it be man-weeks of work no matter what and I should just drop it? Thanks, Ryan *** testing gnome terminal was hilarious: enabling mouse support and clicking on the wrong position sends a control sequence containing ^Z, which duly backgrounds the app! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/