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

[Ivan Shmakov]

>>>>> 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