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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> I can only re-iterate what I already said: we shouldn't cater to
> marginal use cases like that with code that is "tricky" (a.k.a.
> "maintenance headache").  People who change directories of their
> buffers should (and do) know what they are doing.  If doing that
> causes them annoyances, they will know better next time.

Hmm... so you're considering `M-x cd' as harmful?
I'm surprised, it looks like a perfectly normal command to me.
If we don't want normal users to use, we should at least
`disable-command' and/or rename it to something more verbose and
less attractive.

>> the command is executed by the user in one buffer, and it just so
>> happens that its implementation switches to some internal auxiliary
>> buffer.  The value of `default-directory' that should be used is the
>> one that the user knows about, not the one kept by the hidden buffer,
>> over which the user has no control.
> Are we still talking about the situation where a user did "M-x cd"?

Actually, no, I'm talking about how the code *should* behave from a simple
semantic correctness point of view.
This then appears in cases such as `M-x cd' indeed, but it might appear
in other cases I haven't thought about.

> If the former, then is there still a problem if the user refrains from
> "M-x cd"?

Until we decide to deprecate `M-x cd' I think this question is not
really relevant.

> Understood, but unintended results do not necessarily need fixes, just
> because they are unintended.  The important question is: what, if any,
> real problems are caused as unintended results?  We are discussing
> those problems, so the fact that they are unintended results doesn't
> seem important to me.

The patch he provides fixes the immediate problem, which in my book is
a plain bug (maybe for a "corner case", but still a plain bug), but in
terms of "disagrees with the docstring" and "disagrees with my mental
model of what is right".
Also the fix doesn't make the code more obscure or more complex.

Hence I still fail to see why you're opposing it.

I agree that having to be careful in which buffer we are when we read
a given variable because it might be buffer-local is a source of
maintenance headaches, but we have that all over the place in Elisp,
and we don't really have any "better solution".


        Stefan