From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: pop-up tool-bar Date: Fri, 08 Oct 2004 19:12:30 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1097278325 30155 80.91.229.6 (8 Oct 2004 23:32:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Oct 2004 23:32:05 +0000 (UTC) Cc: Miguel Frasson , Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 09 01:31:54 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CG4DJ-0003zq-00 for ; Sat, 09 Oct 2004 01:31:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CG4K8-0000OJ-40 for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2004 19:38:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CG4Jr-0000Lo-IW for emacs-devel@gnu.org; Fri, 08 Oct 2004 19:38:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CG4Jq-0000L1-7c for emacs-devel@gnu.org; Fri, 08 Oct 2004 19:38:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CG4Jq-0000KJ-0q for emacs-devel@gnu.org; Fri, 08 Oct 2004 19:38:38 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CG4BL-0002K6-4G for emacs-devel@gnu.org; Fri, 08 Oct 2004 19:29:51 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by mx20.gnu.org with esmtp (Exim 4.34) id 1CG3xf-0008E3-Ln for emacs-devel@gnu.org; Fri, 08 Oct 2004 19:15:43 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id A7CE48282CD; Fri, 8 Oct 2004 19:12:33 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 2BE3A4AC5AA; Fri, 8 Oct 2004 19:12:31 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 803938CA23; Fri, 8 Oct 2004 19:12:30 -0400 (EDT) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Fri, 8 Oct 2004 12:03:37 -0700") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28105 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28105 > What else have I tried? Well, I tried the code you offered, but it didn't > work for me, as I mentioned previously. Sorry, I thought the problem was obvious enough: just add an `&optional' before the last two args of add-hook-once. > You never replied to my report of those pbs and my request for info on > what I might be doing wrong (copied below). Did you actually _run_ your > code successfully? No, my code was 100% untested, of course ;-). It was only shown to give you a hint of a possible other approach, not necessarily about the implementation (I just used Elisp instead of English). I don't even know whether the approach might work. And as for the "Note", it only referred to my suggested code, in your case the frame should still be guaranteed to be live. > If you have another suggestion, let's try it. But please _try_ this code > too, before dismissing it out of hand. Please pound on it, so we can see > just how brittle it is. I'm sure it works. But the approach used is brittle in the face of the fact that scroll-down might fail, or in the face of variable height lines, or in the face of changes to the scrolling behavior, or in the presence of other events like mouse-4, or ... I.e. it's brittle. > I'm curious: just what part of the quoted mouse-click fix do you find to be > a "really super ugly nasty brittle dark hack"? What makes it so? Are you > speaking in terms of the code being brittle or the user experience (e.g. > being nonintuitive), or both? > You raise (I guess) two issues: > - bad code > - bad user interface Neither: it simply relies on way too many unguaranteed assumptions. A good rule of thumb is that if a code works around a problem by reverting a bad action rather than by eliminating it, it's a "nasty ugly brittle hack" because reverting an action is usually not 100% possible and because it will break every time the bad action changes. Doesn't mean such code doesn't deserve to exist, but just that it "should be kept for extreme circumstances where there's really no other possible option". > Abstractly name-calling the code or the UI doesn't help, > I think. Please be specific. I'm sure that you can come up with good, > concrete improvements, just as you did with the Info quotes > highlighting. You already did offer a concrete suggestion about > `make-variable-frame-local', which I used. OK, you're right, I'm sorry, I should have been more diplomatic. All the suggestion I can think of is to try and remove the tool-bar from a timer function or from a post-command-hook so that it happens at a moment of relative quietness. Basically my suggestion decomposed in two parts: 1 - use post-command-hook in place of read-event to wait for the next event. 2 - use post-command-hook to delay the "remove tool-bar" to after the next command is executed. I think point 2 is the one that holds promise of solving your problem (tho it'll probably come with its own set of problems). Stefan