From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ami Fischman Newsgroups: gmane.emacs.devel Subject: Re: display-buffer vs. current-buffer vs. post-command-hook Date: Tue, 04 Oct 2016 15:49:14 +0000 Message-ID: References: <57F3C212.3020401@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1145f56a437844053e0c011e X-Trace: blaine.gmane.org 1475596360 9243 195.159.176.226 (4 Oct 2016 15:52:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2016 15:52:40 +0000 (UTC) To: martin rudalics , "emacs-devel@gnu.org" , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 04 17:52:33 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brS0n-00079W-Tu for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 17:52:10 +0200 Original-Received: from localhost ([::1]:43849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brS0m-0001Ix-E2 for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 11:52:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brRyC-000867-75 for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:49:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brRyA-0004zB-2k for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:49:27 -0400 Original-Received: from mail-io0-x22c.google.com ([2607:f8b0:4001:c06::22c]:35467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brRy9-0004yy-SI for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:49:26 -0400 Original-Received: by mail-io0-x22c.google.com with SMTP id i202so76659637ioi.2 for ; Tue, 04 Oct 2016 08:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fischman-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HR6NQRnNIffWqpxnjWfEJi7JmAdWqTRs666DAdb99CM=; b=mmp0P1sHTJL+QNPbdSrsnvtwARi2+ppLTQ5tTRdxVGY9mJtXGu1fp75JjnXHMx2YHi ehDzI7Ca8ydqbmsW9ifawLSOyry+mMutUzI8iQXG9LYEC9QaZEKqhvIl81k4cWK2vHJT VvMzNaoRN6asny+j1Tq8ZMunB6H3Libun8JThW9NQaGcgtOCOjcZMSbr2MNRppYWM74h F5ZLtbVgPHHyQw5ve6axg7a3WKkEnZSoi75r3fgbPX85rys0zvzUD9sHhDWW3VH/1uMx hkR34YS/JnizKc+blp5NQJoFCL6bgu784iF0x7gNbILzIdQHDrj1IFNbqIdd233vgcUu xDyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HR6NQRnNIffWqpxnjWfEJi7JmAdWqTRs666DAdb99CM=; b=T6mGT0XF0Mv4DpuHCrL92FfghY0/sSiIhHp+lncqrtfvXlt6bUvLS5md2mz4r+GtL3 eSzmBq4rgG508IMF4gtRbW+JEhT7aEVBeJ5sAwnbkukI+sfXcJ2gwZQ9qx53ivH6tdOl /yXm2t+KTNhicZQAA53yjna2p6tURmxiGFqK21mKVCr03hq6JujB9LlGHVWzxtLW3ade Sctx1V3ZkHNzIZVcb6OMs+Tc51gUdsjMmtHqWfhYHYeZNSnq6+LawAVV5wGDcMuWtR5R +pFigIbL3PE6X8LV/wfBsuijl9+nJtvkXYSypIBQi2gPqaqBHUdUSwV34GJ/ObE7HbuK uf9Q== X-Gm-Message-State: AA6/9RnG+FwH0sFk1J/G+fPjFLSD9jvdPN1cueKrDHdfijKg1dbWSzX7n225QFapRXL8D8dfsyBBDozbrChVvw== X-Received: by 10.107.156.137 with SMTP id f131mr4807591ioe.83.1475596165277; Tue, 04 Oct 2016 08:49:25 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c06::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:207981 Archived-At: --001a1145f56a437844053e0c011e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, just saw Stefan's reply on the mailing list archive (I'm not subscribed to emacs-devel anymore). Yes, I think you're right that I was confusing current-buffer and selected-window. I'm still a bit curious about the expected semantics of current-buffer, in particular which built-in commands should I expect to cause c-b to change asynchronously, in case that's easy to explain. Cheers, -a On Tue, Oct 4, 2016 at 8:45 AM Ami Fischman wrote: > =E2=80=98describe-key=E2=80=99 is based on =E2=80=98with-temp-buffer-wind= ow=E2=80=99 which tries very > hard to restore the current buffer after doing its work. So what you > see here is not a stale value but one that has been correctly preserved. > > > I'm sorry but I don't understand your statement. Should there not be an > expectation that (current-buffer)'s return value does not change between > the second and third call in my original snippet? > Put another way, under what circumstances should one expect > current-buffer's return value to be stable in user-written elisp? > Put a third way, what about describe-keys documentation should lead an > elisp author to understand that current-buffer will not reflect its effec= t > until after a [run-at-time 0]? > (sorry for the barrage of questions; I feel there's a fundamental > something I'm missing in play here and trying to see if you know what it = is > :)) > > Please tell us what you want to accomplish. Then we might be able to > tell you how to do that. > > > My original goal was to resolve a bug in the interaction between two > add-on libraries (see the link in my original email). That bug has been > fixed by replacing the uses of current-buffer with window-buffer so my > original goal is now moot. Now my goal is to understand the intended > semantics of interaction between current-buffer and describe-key (and its > impl). > > Cheers, > -a > --001a1145f56a437844053e0c011e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, just saw Stefan's reply on the mailing list archiv= e (I'm not subscribed to emacs-devel anymore).=C2=A0 Yes, I think you&#= 39;re right that I was confusing current-buffer and selected-window.
I&= #39;m still a bit curious about the expected semantics of current-buffer, i= n particular which built-in commands should I expect to cause c-b to change= asynchronously, in case that's easy to explain.

Cheers,
-a


On Tue, Oct 4, 2016 at 8:45 AM Ami Fischman <ami@fischman.org> wrote:
=E2=80=98descr= ibe-key=E2=80=99 is based on =E2=80=98with-temp-buffer-window=E2=80=99 whic= h tries very
hard to restore the current buffer after doing its work.=C2=A0 So what you<= br class=3D"gmail_msg"> see here is not a stale value but one that has been correctly preserved.

I'm sorry but I don= 't understand your statement.=C2=A0 Should there not be an expectation = that (current-buffer)'s return value does not change between the second= and third call in my original snippet?
Put a= nother way, under what circumstances should one expect current-buffer's= return value to be stable in user-written elisp?
Put a third way, what about describe-keys documentation should lead an= elisp author to understand that current-buffer will not reflect its effect= until after a [run-at-time 0]?
(sorry for th= e barrage of questions; I feel there's a fundamental something I'm = missing in play here and trying to see if you know what it is :))

Please tell us what you want to accomplish.=C2= =A0 Then we might be able to
tell you how to do that.

My original goal was t= o resolve a bug in the interaction between two add-on libraries (see the li= nk in my original email).=C2=A0 That bug has been fixed by replacing the us= es of current-buffer with window-buffer so my original goal is now moot.=C2= =A0 Now my goal is to understand the intended semantics of interaction betw= een current-buffer and describe-key (and its impl).

Cheers,
=
-a
--001a1145f56a437844053e0c011e--