[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18141: 24.4.50; saving .gz file breaks file coding

From: Stefan Monnier
Subject: bug#18141: 24.4.50; saving .gz file breaks file coding
Date: Thu, 07 Aug 2014 15:08:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> Again, that's how write-region always worked.  And with magic file
> names, this is actually the right approach: Emacs has no idea how to
> set up the encoding for such files, so it must delegate that
> responsibility to the handler.  choose-write-coding-system works only
> for local (a.k.a. "non-magic") files, it cannot possibly DTRT for
> files that have handlers.

I'm beginning to understand, so yes I guess the unintended consequences
of the patch should be rather limited.

> Why not move the call to backup-buffer (and surrounding code that
> deals with backup complications) from basic-save-buffer-2 to a
> separate function, and then call that function directly from
> write-region, right before it is about to write the new contents?

That's the hook I suggested.
It's indeed a valid approach.  But it suffers from two problems:
- currently write-region doesn't itself perform backups, so if we make
  it do them always, it's an incompatible change.
- if write-region sometimes performs backups, it'd probably be
  controlled by some dynamic-scoped var (e.g. a hook), in which case
  we could get "spurious" backups if write-region gets called during the
  execution of write-region.

> While at that, we should IMO make the backup-then-write sequence a
> transaction, by using the suitable unwind-protect functions, and
> perhaps also make sure that unwind-protect function runs if Emacs is
> killed half-way through the sequence, to keep the transaction promise.

I'm not terribly worried about this "time window" especially since
I think it's pretty clear that we can't completely eliminate it anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]