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: can we please define a face for compile.el mouseover? Date: Sat, 19 Feb 2011 16:11:25 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1298149902 4317 80.91.229.12 (19 Feb 2011 21:11:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 19 Feb 2011 21:11:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 19 22:11:38 2011 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.69) (envelope-from ) id 1Pqu5Y-0003wm-82 for ged-emacs-devel@m.gmane.org; Sat, 19 Feb 2011 22:11:36 +0100 Original-Received: from localhost ([127.0.0.1]:58143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pqu5W-0005le-MB for ged-emacs-devel@m.gmane.org; Sat, 19 Feb 2011 16:11:34 -0500 Original-Received: from [140.186.70.92] (port=36782 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pqu5Q-0005lO-Np for emacs-devel@gnu.org; Sat, 19 Feb 2011 16:11:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pqu5P-0004dg-0R for emacs-devel@gnu.org; Sat, 19 Feb 2011 16:11:27 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39563 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pqu5O-0004dJ-UZ for emacs-devel@gnu.org; Sat, 19 Feb 2011 16:11:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADrAX01MCqhK/2dsb2JhbACmOHS5UoVeBIUNj1E X-IronPort-AV: E=Sophos;i="4.62,192,1297054800"; d="scan'208";a="92327393" Original-Received: from 76-10-168-74.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.74]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 19 Feb 2011 16:11:25 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 59A9E58B97; Sat, 19 Feb 2011 16:11:25 -0500 (EST) In-Reply-To: (Drew Adams's message of "Tue, 15 Feb 2011 20:03:23 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:136239 Archived-At: > When mouse-face highlighting is on a full line I find simple > underlining better than a flashy background. That's my preference, > but the point is that mouseover highlighting on a long line has > a different effect visually than it does on a short name or a button. I see what you mean and I partly agree. So part of the reason you want a different face is because you mouse-highlight the whole line. But admittedly, the regexps we use in compile.el seem to cover potentially long chunks of text, even without extending them to cover the whole line. Maybe we should add a new face `long-highlight', inheriting from highlight and use it in compilation, or on the contrary maybe we should try and reduce the size of the mouse-highlighted text. > rows and code lines, (c) buttons, and (d) mode-line constructs (treated > generally as buttons, but worth treating as a separate case - as they in > fact are). BTW, the reason why mode-line-highlight is different is very simple: the mode-line face is very different from the default face, so using `highlight' for mouse-over on the mode line looks bad in most configurations, including the default one. >> So if there's a good reason why this particular case is likely to >> happen to many users, a customization variable might be justified, but >> otherwise having a generic solution (e.g. face-remapping) seems quite >> sufficient. > Sigh. Same song you've sung previously to defend hard-coding > `highlight'... Of course, it's the leading theme of software maintenance. Stefan