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

[Ivan Shmakov <ivan@siamics.net>]

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