From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: finding the face of a popup Date: Fri, 31 Aug 2007 15:04:07 +1000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <871wdki9bs.fsf@lion.rapttech.com.au> References: <87lkbwhur5.fsf@lion.rapttech.com.au> <87hcmiiuso.fsf@lion.rapttech.com.au> <878x7tig1j.fsf@lion.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188538938 6471 80.91.229.12 (31 Aug 2007 05:42:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2007 05:42:18 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 31 07:42:17 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IQzGp-0000uN-FM for geh-help-gnu-emacs@m.gmane.org; Fri, 31 Aug 2007 07:42:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQzGp-00065e-0l for geh-help-gnu-emacs@m.gmane.org; Fri, 31 Aug 2007 01:42:15 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news2.google.com!news.glorb.com!sn-xt-sjc-04!sn-xt-sjc-01!sn-xt-sjc-07!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) Cancel-Lock: sha1:VZcSFazf46PV3owhvHxR0lCg6pM= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 106 Original-Xref: shelby.stanford.edu gnu.emacs.help:151485 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:47006 Archived-At: Allan Gottlieb writes: > At Thu, 30 Aug 2007 18:26:48 +1000 Tim X wrote: > >> Allan Gottlieb writes: >> >>> >>> I believe that the description of a face given by placing point >>> over a field and typing C-u C-x = should tell you >>> the face of a popup that is triggered when the mouse is over that >>> field. >>> >> >> I think the problem with that is that you are mixing up two different >> levels of the application. The popup/tooltip is a function of the mouse >> location. The C-u C-x = describes what is around point and the tool tip is >> not really around point - in fact, technically, you could define a tool tip >> that pops up whenever the mouse enters the (buffer - its not done because >> that would be annoying, but it could be done). > > In that case info about the popup could be given whenever you execute > C-u C-x = in that buffer. I agree with you that such behavior would > be annoying, but it could be done. That is you could keep the rule > that C-u C-x = gives info about the current face and any popups that > are triggered. > >> With respect to your other point of list-faces-display not being good >> enough because you might have more than one face with the same color - I >> think thats a non-issue. There are only a couple of faces you cannot put >> point on - tooltip and modeline are two obvious ones. For the others, you >> can use the C-u C-x =. However, the main reason I think its a non-issue is >> that its not a common or frequent problem and when it is, you do have a >> solution - even if its not what you would want in your ideal >> world. > > I agree with you but would say "(very) unimportant issue" > >> Regardless of different opinions, the really good thing is that if you feel >> its important enough that C-u C-x = displays information about a tooltip >> which may be triggered nearby, then you can go and implement it. > > Agreed. I should point out that I mentioned the specific interface in > reply to Eli who asked for it. > At the risk of thrashing the issue within an inch of its life.... There was something bugging me about the issue of a better interface to communicate the tooltip info and then I realised what it was. The problem here isn't really an interface problem, but rather a terminology and communication problem. All of this occured because it wasn't obvious that the feature being observed was called a tooltip. It is likely that even if C-u C-x = did include information about tooltips that may appear near point, anyone who didn't know what a tooltip was or know that the popup was a tooltip is likely not to recognise that the additional bit of information being communicated related to the temporary popup - in the worst case, it might even create more confusion. The solution is likely much harder to achieve than making an addition to the interface as it is a much more difficult problem to define precisely - how do you ensure users are familiar with the names of all the interface components and what is the best way of communicating that information. Some would argue that it just needs to be made clearer in the manual or maybe suggest adding it to the FAQ etc. However, there are a large number of users who never bother with manuals/faqs. some would argue thats their problem then - if they don't read the odcs, they get the confusion they deserve. However, I think thats a bit of a cop out - we know there is a significant number of people who dont read docs, but part of a good interface design is to have an interface that doesn't need the user to read through a bunch of docs before they can start using it. I don't know the answer - not even sure if there is an answer. One addition, which I know is a bit tricky, that I would like to see in emacs is code that will either prevent or warn against face colour options that will be unreadable. This is tricky because of so many unknown variables, such as screen size, resolution, font, user eye sight etc. However, things could probably be improved by eliminating the really obvious cases, such as the original issue that started this thread - a tooltip with the same foreground and background colour. I suspect Allan wouldn't have had as difficult a time working out what the popup was if he had been able to at least read the text being displayed. He would have seen it was some form of help information, which may have either narrowed down the areas in the manual to search or jogged the memory enough that he would have been able to use things like apropos to find the face. While on this topic, I have a couple of questions about face colours. I actually don't worry about them anymore, but when I use to, I had issues because I always use to use a black background. However, often faces have defaults that are obviously based on white/light backgrounds, resulting in defaults that are often difficult or impossible to read. There is a variable that can be set to specify the type of default background i.e. 'dark, but it doesn't seem to do anything - you still get default faces that are dark on dark. is this problem due to people not using/defining faces correctly or is this a limitation of the way face properties are implemented. More specifically, what does the default-frame-mode variable actually do as it doesn't seem to have any real affect? Tim -- tcross (at) rapttech dot com dot au