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:45:00 +0000 Message-ID: References: <57F3C212.3020401@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1145f56a2133fa053e0bf22f X-Trace: blaine.gmane.org 1475595993 11415 195.159.176.226 (4 Oct 2016 15:46:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2016 15:46:33 +0000 (UTC) To: martin rudalics , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 04 17:46:29 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 1brRup-00081H-VV for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 17:46:00 +0200 Original-Received: from localhost ([::1]:43801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brRuo-000569-GU for ged-emacs-devel@m.gmane.org; Tue, 04 Oct 2016 11:45:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brRu5-00054m-DO for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:45:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brRu4-00039D-C7 for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:45:13 -0400 Original-Received: from mail-io0-x229.google.com ([2607:f8b0:4001:c06::229]:35287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brRu4-000390-51 for emacs-devel@gnu.org; Tue, 04 Oct 2016 11:45:12 -0400 Original-Received: by mail-io0-x229.google.com with SMTP id i202so76524146ioi.2 for ; Tue, 04 Oct 2016 08:45:11 -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=s6rgJHkMiOJK8RPb7OLuaXAaTcUBl5QXfly6Rsk2VDU=; b=Wo2/Nx5I2zMLS/wg6JT/Fq5Nb29oCypToG3Tmm9fTalWKmulnAYwx8fqD1hlTwKUla ysVEimcXp95klmY2hT40M7leqr7/OaI+hhST1owoloPOUKG/hg5qjfErancf1a12Chd9 lREdIbUeGrxZa3oYNnIyYioBvyCkQELmNc6GENIV1BpKeAVos2pdZUknqEWq3JX0AUBY 5WR83FgU5s9xlnOuzj2qPRQB5R/fC4l3KLIpOCoY1UQ8OvvKUAcwkUtSl94f/vPYsBNI 0ZzdQjYxLJRH6xMHacAsqFLh+rM/bBdv3M6Q1v0v+9zjGn7yAyq/zgH6fLFxKQ88SY7Q s/SQ== 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=s6rgJHkMiOJK8RPb7OLuaXAaTcUBl5QXfly6Rsk2VDU=; b=brGg0gmZwJVN+zRigqIL1AKPLEZZWSo8fzjnBlZzXUzgxwRPl5E5v7St/y6q0XilXQ WLq2pteLgztKTs4uTdO4g2st1hp1qLw3kM/j7+KFBU5A/Fi9Pme8VNedrkKTnHRLVF0Y fu44hhKpB0RoeFHygmx6XNvKF+E3Vm4c2U1gXG+Uc/SphXBoIxJesGXJrsLH/YX5e3P+ sm70EPLombX3M3hQtyi+24io5YsCXeWcsw7qusSXZQcnxUIrG7Xi6aKsNyQ+GapCoubv omqcfDzlhq/DvXXBJ40XnW+xOZIfLtrQGwS2hBbZo3E0rKugdq2nJ303iK6yTSdoRv57 nuLw== X-Gm-Message-State: AA6/9RkpmPf0CC9z2sQYL9pAyTHE0ZQTMnZqfRx6lsNCVE3p3ey+iolXH5ae5oQmVxj9gCnNSIIpKpVpJ2/TXw== X-Received: by 10.107.156.137 with SMTP id f131mr4788384ioe.83.1475595911367; Tue, 04 Oct 2016 08:45:11 -0700 (PDT) In-Reply-To: <57F3C212.3020401@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c06::229 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:207980 Archived-At: --001a1145f56a2133fa053e0bf22f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > =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 effect 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 --001a1145f56a2133fa053e0bf22f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= =E2=80=98describe-key=E2=80=99 is based on =E2=80=98with-temp-buffer-window= =E2=80=99 which 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 d= on't understand your statement.=C2=A0 Should there not be an expectatio= n that (current-buffer)'s return value does not change between the seco= nd and third call in my original snippet?
Put another way, under = what circumstances should one expect current-buffer's return value to b= e stable in user-written elisp?
Put a third way, what about descr= ibe-keys documentation should lead an elisp author to understand that curre= nt-buffer will not reflect its effect until after a [run-at-time 0]?
<= div>(sorry for the barrage of questions; I feel there's a fundamental s= omething I'm missing in play here and trying to see if you know what it= is :))

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

My original goal w= as to resolve a bug in the interaction between two add-on libraries (see th= e link in my original email).=C2=A0 That bug has been fixed by replacing th= e uses 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 = between current-buffer and describe-key (and its impl).

Cheers,
-a
--001a1145f56a2133fa053e0bf22f--