From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Frame ordering Date: Sat, 12 Jun 2010 10:01:35 +0200 Message-ID: <4C133EDF.8070407@gmx.at> References: <8F18E079-3351-4398-B76B-6CF9169ACE9E@gmail.com> <4C123889.5060801@gmx.at> <597D28BE-ABE3-4FFF-84B1-1FBF9931293C@gmail.com> <4C126EA5.1050509@gmx.at> <4DF4317D-522E-4948-9C19-ED1252BF36B2@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276329716 7554 80.91.229.12 (12 Jun 2010 08:01:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 08:01:56 +0000 (UTC) Cc: Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 10:01:54 2010 connect(): No such file or directory 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 1ONLf6-0000LP-TB for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 10:01:53 +0200 Original-Received: from localhost ([127.0.0.1]:49162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONLf5-0000mS-N9 for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 04:01:51 -0400 Original-Received: from [140.186.70.92] (port=45744 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONLev-0000mA-4R for emacs-devel@gnu.org; Sat, 12 Jun 2010 04:01:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONLet-0006EU-Vz for emacs-devel@gnu.org; Sat, 12 Jun 2010 04:01:40 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:43788) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1ONLet-0006EC-Lh for emacs-devel@gnu.org; Sat, 12 Jun 2010 04:01:39 -0400 Original-Received: (qmail invoked by alias); 12 Jun 2010 08:01:37 -0000 Original-Received: from 62-47-40-208.adsl.highway.telekom.at (EHLO [62.47.40.208]) [62.47.40.208] by mail.gmx.net (mp067) with SMTP; 12 Jun 2010 10:01:37 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+p2g9G9NipxsSVjMn2LolYYknGXejL+FswGAd8ux wRAiQvCO6/sLCc User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4DF4317D-522E-4948-9C19-ED1252BF36B2@gmail.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:125786 Archived-At: >> I'd write a simple function to reorder frames, make it callable from >> Lisp, and test it from there first. > > OK, that works. > What next? > `handle-switch-frame' could be defined in Lisp anyway, calling the current Fhandle_switch_frame primitive. I don't think so. IIUC it's purpose is to hide do_switch_frame from Elisp. > That said, why did the same not work in do_switch_frame, and why did my other variant (that I posted) lead to hangs and crashes? [...] > (defun my-handle-switch-frame ( event) > (interactive "e") > (handle-switch-frame event) > (set-latest-frame (selected-frame))) I can only guess. do_switch_frame handles an event and when the frame list is in the state of restructuring and an event occurs, you might end up with a broken frame list (or a broken window or buffer list given the fact that do_switch_frame calls `select-window'). In addition, as I recently noticed in the buffer list handling routines, frame/window/buffer lists are frequently updated via Fdelq and that function can quit. I suppose that in all these cases we'd have to use delq_no_quit (and similar functions) instead to be on the safe side. Your `my-handle-switch-frame' seems safe because you serialized `set-latest-frame' with do_switch_frame - so you won't suffer any of the problems above. If, however, you were able to interrupt a call to `set-latest-frame' somehow (maybe by running it in an infinite loop), you might be able to produce a crash too. martin