[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isolating history with buffer-local variables
From: |
Stefan Monnier |
Subject: |
Re: isolating history with buffer-local variables |
Date: |
Fri, 15 May 2015 19:32:43 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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
- isolating history with buffer-local variables, Nick Helm, 2015/05/12
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/13
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/14
- Re: isolating history with buffer-local variables,
Stefan Monnier <=
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/20
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/20
- Re: isolating history with buffer-local variables, Stefan Monnier, 2015/05/24
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/24
- Message not available
- Re: isolating history with buffer-local variables, Pascal J. Bourguignon, 2015/05/24
- Re: isolating history with buffer-local variables, Nick Helm, 2015/05/24