bug#18550: eww-history-browse may end up calling eww-restore-history in an arbitrary buffer

[Ivan Shmakov <ivan@siamics.net>]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> I see no reason to abuse quit-window for what’s 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’s buffer; instead, it allows for the VC
	commands to be used in the associated buffers /as if/ they were
	invoked in the file’s own one.  As in: the user does C-x v = to
	see the diff; finds something of interest, and – whoa! – the 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’m 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, – it could be a variable
	(as I’ve suggested before), a text property, or some arcane
	location quit-window would use.  However, I’d like to note that
	I currently also use EWW to render previews of the buffer’s
	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 “source” buffer, thanks to this very
	“history” feature EWW provides.)

[1] http://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git;a=blob;f=mw-eww.el

	I presume that such an approach will hold for the other cases
	where a given buffer’s contents needs to be rendered with EWW,
	possibly after passing through a specific local (say,
	$ markdown) or remote software.  It’s 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.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A