Re: isolating history with buffer-local variables

[Stefan Monnier]

> I think there are other use-cases though. For instance, I use Emacs to
> edit confidential files that I don't want leaking into incremental
> backups or off-site syncing of ~/.emacs.d/ (all the usual financial,
> medical, legal stuff).

Could you give details of those use-cases, to see how much of it is very
specific to your particular setup, and how much of it could apply to
a wider audience?

I'm specifically wondering why copying "foo" to "foo~" or to "#foo#"
would be a problem (assuming "foo" itself is modified) w.r.t
incremental backups or off-site syncing.  Or are your worries more
specifically about leaking data from those files via history variables
saved in ~/.emacs.d ?
[ Another way to attack this problem is to try and avoid
  syncing/backing-up the saved-history data in ~/.emacs.d.
  Maybe this history data should never be saved to ~/.emacs.d but to
  another place instead?  ]

>>> (setq backup-inhibited t) ;; locally disable backups
>>> (setq auto-save-timeout 0)) ;; locally idle auto-saves
>> For encrypted files (accessed via EPA), the above should be correctly
>> handled already (either by preventing autosave/backups or by keeping
>> those files encrypted just like the main file).  If you find they're
>> not, please file it as a bug.
> Yes, that's what I see here too.

In which other situations did you find such settings to be needed?

> I thought that was probably the case, but I couldn't pin down why some
> minibuffer input was prepended to the local variable
> (e.g. command-history) while other input was not
> (e.g. extended-command-history).

`command-history' is a variable managed by the read-eval command loop,
whereas `extended-command-history' is a normal minibuffer history
variable (i.e. managed by read-from-minibuffer).

Minibuffer history variable are apparently set while we're in the
minibuffer.  Maybe we should change this so that minibuffer history
variables get set in the buffer from which read-from-minibuffer is
called instead of in the minibuffer.  It would probably be very useful
in your case, and seems like a good idea in general.
I suggest you file a bug report about that.


        Stefan