From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: PJ Weisberg Newsgroups: gmane.emacs.devel Subject: Re: threads and kill-buffer Date: Thu, 6 Sep 2012 13:49:29 -0700 Message-ID: References: <87a9x55xvd.fsf@fleche.redhat.com> <5046D668.4010105@yandex.ru> <50471EEB.9030405@gmx.at> <837gs8e8n7.fsf@gnu.org> <50484E88.4080804@gmx.at> <83lignd1o8.fsf@gnu.org> <5048B623.9050802@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1346964583 25187 80.91.229.3 (6 Sep 2012 20:49:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2012 20:49:43 +0000 (UTC) Cc: tromey@redhat.com, Eli Zaretskii , dmantipov@yandex.ru, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 22:49:42 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T9j19-0005Zx-Q3 for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 22:49:39 +0200 Original-Received: from localhost ([::1]:36648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9j16-0005rU-Rh for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 16:49:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9j14-0005rP-Fk for emacs-devel@gnu.org; Thu, 06 Sep 2012 16:49:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9j13-00065i-Gj for emacs-devel@gnu.org; Thu, 06 Sep 2012 16:49:34 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:51310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9j11-00065R-Fu; Thu, 06 Sep 2012 16:49:31 -0400 Original-Received: by lbon3 with SMTP id n3so1600220lbo.0 for ; Thu, 06 Sep 2012 13:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UyZtdvZgfMHxsEyAq6OkZXHw1UGIA7pAwP2WLQ7/FAI=; b=Dw8uyzeu1aUcUsyOcN8ILYWymED51krLzoS4+X04I1deGjlvH7UAPDVT5eJURxaY5y UW2Vky8ydTnisGJu1jG+xPrzKb///48gKrokDbSGLc138a5CQeWGX/PBEIPc6PAXh6xP CxLZGgscCwxqTx93TA4jLz0469tirezJ+pInln4Bv8I1IFJLul2LAvS7XSuEeHiLh6Tg KSTW/sQ0Fmkgauiyc7ncmxvlsN+nEQ9H5qcQT2nZQ0fDd9TEJw6EXC8DaefU1JtVeiBV GNWyRTNTISnDwaxh/6e9iQxa4p7RSO8GcbGrQBM/5t9mKHiR2YFXx2ApLGnFrd9sjLGh XxDw== Original-Received: by 10.112.84.199 with SMTP id b7mr1332371lbz.29.1346964569631; Thu, 06 Sep 2012 13:49:29 -0700 (PDT) Original-Received: by 10.112.48.6 with HTTP; Thu, 6 Sep 2012 13:49:29 -0700 (PDT) In-Reply-To: <5048B623.9050802@gmx.at> X-Google-Sender-Auth: W4ToX9FfKzD9_r5gDxQjwOszmM0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.217.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153128 Archived-At: On Thu, Sep 6, 2012 at 7:41 AM, martin rudalics wrote: >>> >> ... and what if this buffer was meanwhile revived by another thread? >>> > >>> > No other thread can revive that buffer, because the buffer is >>> > invisible to any buffer but those who have it as current. >>> > >>> > The "revived" buffer will be a different buffer, perhaps with the same >>> > name. >>> >>> How could that work with buffers like *Help* or *Backtrace* which are >>> revived all the time? Do you want to clone them? >> >> I don't understand the problem that bothers you. Please elaborate. > > Suppose *Backtrace* is current in thread A and gets killed by thread B. > Before making another buffer current for A, a debugger buffer must be > revived for B. Would that be a different buffer from the *Backtrace* > seen in A? A more interesting question is, what does (get-buffer "*Backtrace*") return in thread A? I can think of a few commands in Magit that would not behave properly if (get-buffer-create some-string) returned a buffer that couldn't be displayed after the command finished. (Though I'm having a much harder time imagining how one of those functions could be called with a current-buffer that's in the process of being killed.) -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced.