From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Suggestion: A fringe indicator that shows the last/first line before scrolling Date: Thu, 28 Feb 2008 23:33:40 -0500 Message-ID: References: <8763w9mhdm.fsf@member.fsf.org> <47C6D74C.6010501@gmail.com> <8e24944a0802280834v3cf8e2acxd7292feacd4c470b@mail.gmail.com> <47C6F4F8.5040703@gmail.com> <8e24944a0802281001l7022dedfg19846275cba15ef0@mail.gmail.com> <47C6F9A5.5050406@gmail.com> <8e24944a0802281018v6804526yad1bd02191ede989@mail.gmail.com> <47C6FE9F.1060800@gmail.com> <8e24944a0802281518x19bcbfd5ndf2ce1ca55a77dc@mail.gmail.com> <8e24944a0802281850l28ab99fcrc92f02d0399630aa@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204259647 20753 80.91.229.12 (29 Feb 2008 04:34:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Feb 2008 04:34:07 +0000 (UTC) Cc: David O'Toole , "Lennart Borgman \(gmail\)" , emacs-devel@gnu.org To: "David De La Harpe Golden" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 29 05:34:32 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JUwwy-0007I9-Ar for ged-emacs-devel@m.gmane.org; Fri, 29 Feb 2008 05:34:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUwwR-0000Nb-QF for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2008 23:33:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUwwN-0000NM-JF for emacs-devel@gnu.org; Thu, 28 Feb 2008 23:33:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUwwM-0000MH-5I for emacs-devel@gnu.org; Thu, 28 Feb 2008 23:33:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUwwL-0000M4-Tv for emacs-devel@gnu.org; Thu, 28 Feb 2008 23:33:45 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JUwwH-0000KX-SO; Thu, 28 Feb 2008 23:33:41 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABYax0dMCpz5Wmdsb2JhbACQZwEgnHeBAQ X-IronPort-AV: E=Sophos;i="4.25,424,1199682000"; d="scan'208";a="15381244" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 28 Feb 2008 23:33:41 -0500 Original-Received: from pastel.home ([76.10.156.249]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id JGK33041; Thu, 28 Feb 2008 23:33:41 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 068067FA7; Thu, 28 Feb 2008 23:33:41 -0500 (EST) In-Reply-To: <8e24944a0802281850l28ab99fcrc92f02d0399630aa@mail.gmail.com> (David De La Harpe Golden's message of "Fri, 29 Feb 2008 02:50:24 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:90825 Archived-At: >> It's neither. It's just the result of how the code is written: there's >> only one command (the mouse-drag) which happens to read several >> events waiting for the event that marks the end of the drag. > What events actually terminate the drag ? Martin said it was in That is yet-another-problem due to the way the code is written. Actually this part of the mouse-drag is really ugly. When the drag ends, the command doesn't end: it waits for the next event (i.e. the next command). This is because it want to know if the next event is one of mouse-region-delete-keys. I hope we can get rid of this madness at some point. E.g. by (re)using the delete-selection-code for this feature. >> There are other cases where scrolling can happen without running >> post-command-hook, e.g. scrolling triggered by process filters >> (e.g. scrolling in the *compilation* buffer or in tail-mode buffers). > Fair enough - means post-command-hook is a nonstarter like it was for > point movements. Not really. It just means it will only work 99%. For a more reliable result you'll probably want/need to hack the C code to introduce some kind of pre-redisplay-hook, since what you're looking for is linked to the display changes rather than to execution of commands. Stefan