From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Mention mouse-face changes mouse pointer shape Date: Thu, 22 Feb 2007 08:54:05 -0800 Message-ID: References: <45DDC639.5020002@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: sea.gmane.org 1172163332 17025 80.91.229.12 (22 Feb 2007 16:55:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Feb 2007 16:55:32 +0000 (UTC) To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 22 17:55:17 2007 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 1HKHDw-00073W-AC for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2007 17:55:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HKHDv-0003zq-VS for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2007 11:55:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HKHDj-0003yr-UX for emacs-devel@gnu.org; Thu, 22 Feb 2007 11:55:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HKHDi-0003x7-8Q for emacs-devel@gnu.org; Thu, 22 Feb 2007 11:55:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HKHDi-0003x1-1z for emacs-devel@gnu.org; Thu, 22 Feb 2007 11:55:02 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HKHDh-0006n0-HN for emacs-devel@gnu.org; Thu, 22 Feb 2007 11:55:01 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1MGswuJ010424 for ; Thu, 22 Feb 2007 10:54:59 -0600 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l1MGWs9G023686 for ; Thu, 22 Feb 2007 09:54:58 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by rcsmt250.oracle.com with ESMTP id 2470577981172163251; Thu, 22 Feb 2007 09:54:11 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <45DDC639.5020002@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 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:66624 Archived-At: > >> But shouldn't the cursor change to a hand cursor rather > >> than an arrow cursor when hoovering over a mouse-face? > >> > >> I think the change was a mistake, instead we should have arranged the > >> relevant areas to have both mouse-face and pointer text properties. But > >> I don't know how much effort it will be now to go back and change this. > > > > I haven't followed this thread closely, but this does indeed > > sound like a (design) mistake. The two, mouse-face and pointer > > shape, should be independent, by default. If some particular code > > wants to couple them for some purpose, that's fine, but such a > > coupling should not be hard-coded or the default behavior. > > Something like 'mouse-face, 'mouse-link-face, 'mouse-pointer with > appropirate priorities? I don't know what you're proposing concretely, but any such proposals should be discussed after the release. I might have misunderstood, but I interpreted Jason's message to say that these two properties are now coupled generally, instead of them both just having been applied to the "relevant mode line areas". Perhaps the coupling is not so general, and is limited to the mode line as a whole, but the same argument still applies: they should be coupled only as needed, as particular code sees fit. My point was that, if these two properties are now coupled in a general way, then that is a mistake. That would represent a change from the traditional behavior, apparently slipped in as a bug fix, and it should be pulled out, IMO. That's all I meant to say.