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 19:24:22 +0300 Message-ID: <83pph03snd.fsf@gnu.org> References: <20140719.173203.1998048028110686770.tak.kunihiro@gmail.com> <20140720.085224.514514587.tak.kunihiro@gmail.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1405873502 18501 80.91.229.3 (20 Jul 2014 16:25:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Jul 2014 16:25:02 +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 18:24:55 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 1X8tuu-0003Mv-86 for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Jul 2014 18:24:52 +0200 Original-Received: from localhost ([::1]:58346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8tur-0005oh-Kg for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Jul 2014 12:24:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8tuc-0005oZ-GN for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 12:24:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X8tuW-0007lj-Gk for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 12:24:34 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8tuW-0007lX-8M for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 12:24:28 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N9000400QPFAN00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 19:24:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N90004BKQWQ6O20@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sun, 20 Jul 2014 19:24:26 +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:98823 Archived-At: > From: Stefan Monnier > Date: Sun, 20 Jul 2014 11:37:34 -0400 > > > That's the "silly iteration" I had in mind: the 2nd part of this is > > the tricky one, because all we know from posn-at-x-y and its ilk is > > the pixel width of the object at the coordinates we pass to the > > function; we don't know the coordinates where the object starts. > > 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?). In any case, we cannot rely on glyph matrices alone, because that would severely limit the usefulness of such an API. 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. Also, some modes, like linum-mode, never let you have an up-to-date glyph matrix. For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but instead simulate display. > > Actually, I disagree: every other GUI app I could try behaves like the > > OP asked by default, so I see no reason for Emacs to offer an option > > here. > > They do, but not for all operations. E.g. if you click on the rightmost > pixel of a hyperlink, your browser will happily consider that the click > was on the hyperlink, not on the position right after that one. I think hyperlinks are the odd one out, and not directly related to the issue here, which is where to put point given a click, especially in the context of highlighting the region.