bug#19865: tar-untar-buffer: should honor default-directory

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Tue, 17 Feb 2015 05:25:47 +0000

[…]

 > Emacs maintenance shouldn't pay a price for marginal use cases for
 > which simple workarounds (like "M-x cd BACK") are available.

        It is not a workaround for the problem in question.

[…]

 >> We’re using with-current-buffer there for the sole reason that
 >> write-region operates strictly on the current buffer.  It is so
 >> without this change, and it remains so with it; the change maintains
 >> this status quo just perfectly.  And as long as such use /is/
 >> acceptable in the current code, I fail to see why it wouldn’t be in
 >> the replacement being discussed.

 > I already explained that, more than once:

        And I’ve already provided an example where default-directory is
        changed by Emacs behind the back of the user.

 > the change is obscure,

        Yet it makes the code /less/ obscure that it currently is.

 > and is made for the sake of a marginal use case,

        It is made for the sake of consistency with the rest of the
        tar-mode.el code.  And sure: it fixes that marginal use case at
        the same time, too.

 > where the user should have returned to the original directory from
 > which she cd'ed, to avoid the problem.

        The use of M-x cd on a buffer does not influence the behavior of
        tar-untar-buffer for that same buffer in any way.  When it
        thinks – for whatever reason – that it should use
        /that/directory as its target, – it’s stuck that way, and no
        sensible user action is going to change its twisted mind.
        (Incidentally, this is the very description of this bug.)

        There’s simply /no/ problem which the user could solve by
        changing the value of default-directory – whether back, forth,
        or sideways.

 >> What /is/ changed is that with-current-buffer will now go
 >> immediately before write-region:

 >> (with-current-buffer data-buffer (write-region …))

 >> Cf. the former:

 >> (with-current-buffer data-buffer … lots of code to make sure the
 >> reader’s lost… (write-region …))

[…]

 > Now put yourself in the shoes of someone who needs to review this
 > change many moons from now, and try to imagine how "easy" it will be
 > for them to understand what the heck was that all about.

        Whose shoes do you think I was in while I’ve investigated this
        issue?  My first thought: why on Earth does with-current-buffer
        wraps some 18 LoC while it’s needed for exactly a single one?

        As for the “many moons” part, I think I’d request a re-review
        after a few.  Hopefully someone’d provide some more convincing
        arguments by then, since I’m pretty much out of ink right now.

        (And TIA to that party, sure.)

[…]

-- 
FSF associate member #7257  tar-mode.el does nasty things 3013 B6A0 230E 334A