From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Selection threshold with mouse Date: Sun, 20 Jul 2014 20:21:38 +0300 Message-ID: <83oawk3pzx.fsf@gnu.org> References: <20140719.173203.1998048028110686770.tak.kunihiro@gmail.com> <20140720.085224.514514587.tak.kunihiro@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1405876942 22075 80.91.229.3 (20 Jul 2014 17:22:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Jul 2014 17:22:22 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jul 20 19:22:11 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X8uoM-0002D4-TF for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Jul 2014 19:22:11 +0200 Original-Received: from localhost ([::1]:58463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8uoM-0005GN-D6 for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Jul 2014 13:22:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8uo6-0005GG-Bt for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 13:22:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X8unv-0008Db-UY for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 13:21:54 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:36902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8unv-0008DL-MG for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 13:21:43 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N9000400THQW000@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 20:21:42 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N90004LXTK6HV70@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 20:21:42 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98826 Archived-At: > From: Stefan Monnier > Date: Sun, 20 Jul 2014 12:44:22 -0400 > > >> Hmm... but don't the display matrices contain the needed info (i.e. the > >> "left-pixel boundary position"), since it's needed to react to an > >> expose event? > > Not sure I follow (what does an expose event have to do with the issue > > at hand?). > > An expose event comes with pixel coordinates and we need to respond by > drawing chars at the proper pixel positions, so we clearly need to be > able to find the chars placed at those pixel positions as well as their > pixel boundaries. Yes, but in these cases we can always err on the safe side, i.e. redraw more than strictly needed. We cannot use this strategy in the case in point. > > E.g., you will be unable to use it in a function that is called > > several times in a row, like via a numeric argument or from a keyboard > > macro. > > We could make it update glyph matrices if/when needed. That would make Emacs much slower than it is now, because now we never enter redisplay as long as a command runs. You suggest to interrupt a running command by doing a large portion of redisplay, which will slow us down. > > For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but > > instead simulate display. > > Then I don't understand why the precise pixel position is not available. Because the existing methods are glyph-granular, not pixel-granular. When you tell them to stop at pixel coordinate X, they move one "display element" (e.g., character or image) at a time, and they stop when they are _at_or_after_ the glyph whose pixel width includes the coordinate X. This doesn't reliably tell you where the glyph at X starts on display. These methods were never designed to return the kind of information and with the kind of accuracy that is required for implementing the requirement we are discussing.