From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "David De La Harpe Golden" Newsgroups: gmane.emacs.devel Subject: Re: Suggestion: A fringe indicator that shows the last/first line before scrolling Date: Fri, 29 Feb 2008 02:50:24 +0000 Message-ID: <8e24944a0802281850l28ab99fcrc92f02d0399630aa@mail.gmail.com> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1204253441 6341 80.91.229.12 (29 Feb 2008 02:50:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Feb 2008 02:50:41 +0000 (UTC) Cc: David O'Toole , "Lennart Borgman \(gmail\)" , emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 29 03:51:07 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 1JUvL0-0000b2-Ci for ged-emacs-devel@m.gmane.org; Fri, 29 Feb 2008 03:51:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUvKU-0005zS-1Y for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2008 21:50:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUvKO-0005z8-Kt for emacs-devel@gnu.org; Thu, 28 Feb 2008 21:50:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUvKM-0005x9-Rr for emacs-devel@gnu.org; Thu, 28 Feb 2008 21:50:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUvKM-0005wy-Oo for emacs-devel@gnu.org; Thu, 28 Feb 2008 21:50:26 -0500 Original-Received: from wf-out-1314.google.com ([209.85.200.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JUvKM-0003ih-Cv for emacs-devel@gnu.org; Thu, 28 Feb 2008 21:50:26 -0500 Original-Received: by wf-out-1314.google.com with SMTP id 29so3840281wff.24 for ; Thu, 28 Feb 2008 18:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=uqxXORahBRlWk6SAP1ZLlzt5fJvDyNdOHNuSMTcM6OY=; b=EA02kTykZTsLhs13Xc1GKHiFZcg15Dv2lZO0H6zqg04C0Z8q8x19NAIcXR4ySO4mQbbtzmX68VM39uurZZhx968G365z8HDJ6qfSJ2ZsOD4Wio0qa5Klq4Q5awbYf4QG31Q8nxUUym9DMEIKwPx+DHhcU1XifzkviKx6wj2SSBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vFazyuKtCaRmnUUjVr4JyAkQ15jblVwuU+y57h+tNSWPvoEKkzxhQ0nbxVuP2sS1wZkcCyXlg1JSSjNpS8x11Dv38D0Ti+vSnvP5q0+36jdeJJsKa6JMq1SiUa0gsCoGSyr8IfeE/hqqspEk/V0dYch0LFbWPrjdk2QEPq2MOzE= Original-Received: by 10.142.246.8 with SMTP id t8mr6642960wfh.31.1204253425023; Thu, 28 Feb 2008 18:50:25 -0800 (PST) Original-Received: by 10.142.111.4 with HTTP; Thu, 28 Feb 2008 18:50:24 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:90816 Archived-At: On 29/02/2008, Stefan Monnier wrote: > 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 mouse-show-mark the problem arises, and it seems that that is called by mouse-drag-track, and you are deliberately handling scroll-bar events there - think that means that when the mouse-drag is "almost over" and mouse-show-mark is happening, the scroll-bar scrolling is atypically not causing post-command-hooks? Of course, and I only just noticed this since I usually use transient mark mode, that post-drag-scrolling mouse-highlight behaviour is also different depending on whether transient-mark-mode-is on or not - when it is off, the mouse selected region is still highlighted and independent of point when scrolling. I'm not sure, but that may be one of the major intents of mouse-show-mark? Is the call to mouse-show-mark in mouse-drag-track useful when transient-mark-mode is t? When I wrap it in an (unless (eq transient-mark-mode 't) (mouse-show-mark)), I get perhaps more like naively expected behaviour - ending the mouse drag (mouse-1-up) causes a post-command-hook, and post-mouse-drag scroll-bar scrolling causes a post-command-hook. All pretty irrelevant given below, but anyway. > 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.