From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ivan Shmakov Newsgroups: gmane.emacs.bugs Subject: bug#18550: eww-history-browse may end up calling eww-restore-history in an arbitrary buffer Date: Tue, 25 Nov 2014 15:40:06 +0000 Message-ID: <87a93fs2zt.fsf@violet.siamics.net> References: <87tx3wn2d0.fsf@violet.siamics.net> <87zjbn5sxj.fsf@violet.siamics.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1416930084 23704 80.91.229.3 (25 Nov 2014 15:41:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Nov 2014 15:41:24 +0000 (UTC) To: 18550@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 25 16:41:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1XtIEx-0005BB-2Z for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Nov 2014 16:41:19 +0100 Original-Received: from localhost ([::1]:58090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtIEw-0003Og-Ge for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Nov 2014 10:41:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtIEn-0003NT-QZ for bug-gnu-emacs@gnu.org; Tue, 25 Nov 2014 10:41:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtIEi-0005Am-Pq for bug-gnu-emacs@gnu.org; Tue, 25 Nov 2014 10:41:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtIEi-0005Aa-0L for bug-gnu-emacs@gnu.org; Tue, 25 Nov 2014 10:41:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XtIEh-0006ua-FF for bug-gnu-emacs@gnu.org; Tue, 25 Nov 2014 10:41:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ivan Shmakov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Nov 2014 15:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18550 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 18550-submit@debbugs.gnu.org id=B18550.141693004526534 (code B ref 18550); Tue, 25 Nov 2014 15:41:02 +0000 Original-Received: (at 18550) by debbugs.gnu.org; 25 Nov 2014 15:40:45 +0000 Original-Received: from localhost ([127.0.0.1]:45103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XtIEK-0006tm-Ri for submit@debbugs.gnu.org; Tue, 25 Nov 2014 10:40:44 -0500 Original-Received: from fely.am-1.org ([78.47.74.50]:42324) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XtIE7-0006tP-ST for 18550@debbugs.gnu.org; Tue, 25 Nov 2014 10:40:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=siamics.net; s=a2013295; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:Sender:References:Subject:To:From; bh=Uuq4ZwjrUYFD06vCMqA1JL3s9SXGnreAWDrlSchm+os=; b=ntVRzPnk2X3x9xpOp9HVJ/bFEySFagb4v6th9ogChetvYrPoSGdbIpLA4M/TWSN/va9KrrIUPku3OK7e0FKZ1Hh6f2tGtnM22RgbxUVZtYpCdBVDMRqRv77TrenLVx+RDBRr3Z6BzCBDbPFtI+VCKSrPPUJOt1hO6ElWtOhkxaA=; Original-Received: from [2a02:2560:6d4:26ca::1:1d] (helo=violet.siamics.net) by fely.am-1.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XtIDt-0004Ip-Vf for 18550@debbugs.gnu.org; Tue, 25 Nov 2014 15:40:14 +0000 Original-Received: from localhost ([::1] helo=violet.siamics.net) by violet.siamics.net with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XtIDm-0001hy-LP for 18550@debbugs.gnu.org; Tue, 25 Nov 2014 22:40:06 +0700 Mail-Followup-To: 18550@debbugs.gnu.org In-Reply-To: (Lars Magne Ingebrigtsen's message of "Wed, 19 Nov 2014 18:25:57 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:96550 Archived-At: >>>>> Lars Magne Ingebrigtsen writes: >>>>> Ivan Shmakov writes: >> I see no reason to abuse quit-window for what=E2=80=99s essentially >> switching to a buffer to edit one. That is: the eww-restore-history >> call right after quit-window edits the /current/ buffer. Thus, it >> indeed makes sense to explicitly use set-buffer before that. (Or to >> wrap the call in with-current-buffer, anyway.) >> Moreover, vc.el already uses a dedicated buffer-local variable for a >> similar purpose, and so does rcirc.el, and perhaps a few more modes >> out there. > I think you're arguing against yourself here. Not in the least. > If this is such a common thing to do, then something in this setup > should provide this functionality, so that all these modes don't have > to implement it again and again. The vc-parent-buffer variable is /not/ used just to get back to the controlled file=E2=80=99s buffer; instead, it allows for the VC commands to be used in the associated buffers /as if/ they were invoked in the file=E2=80=99s own one. As in: the user does C-x v =3D to see the diff; finds something of interest, and =E2=80=93 whoa! =E2=80=93 t= he VC log is only C-x v l away. In the case of eww-history-browse, (quit-window) is part of the user interface, and I=E2=80=99m perfectly fine with it. (Although I /do/ imagine a use case which would require eww-history-browse to leave the history window in place.) On the contrary, the requirement to be invoked in the right buffer is part of the eww-restore-history calling convention. Even though the users may have different opinions regarding which buffer or window (if any) to select upon finishing with the history, the necessity to call eww-restore-history from the right one remains entirely the same. There is indeed some freedom with respect to the location the EWW buffer proper gets referenced from, =E2=80=93 it could be a variable (as I=E2=80=99ve suggested before), a text property, or some arcane location quit-window would use. However, I=E2=80=99d like to note that I currently also use EWW to render previews of the buffer=E2=80=99s MediaWiki markup [1], and that already benefits from having the target EWW buffer linked via a buffer-local variable. (Contrary to, say, M-x mml-preview, it /is/ reasonable to direct the output into a single buffer for all the repeated uses of the command in the same =E2=80=9Csource=E2=80=9D buffer, thanks to this very =E2=80=9Chistory=E2=80=9D feature EWW provides.) [1] http://am-1.org/~ivan/archives/git/gitweb.cgi?p=3Dmw-el-2014.git;a=3Dbl= ob;f=3Dmw-eww.el I presume that such an approach will hold for the other cases where a given buffer=E2=80=99s contents needs to be rendered with EWW, possibly after passing through a specific local (say, $ markdown) or remote software. It=E2=80=99s even possible to provide an M-x eww-preview command of some kind for that very purpose. The command will either use the (live) buffer pointed to by this new buffer-local variable; or will search for one, or create one anew, possibly by running a user-specified function or hook. (The command would employ one another hook to perform the conversion of the source data into HTML.) --=20 FSF associate member #7257 http://boycottsystemd.org/ =E2=80=A6 3013 B6A0= 230E 334A