From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: isolating history with buffer-local variables Date: Fri, 15 May 2015 19:32:43 -0400 Message-ID: References: <54AE8A33-FB8D-4F63-8BC1-F84DB290EF05@tenpoint.co.nz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431732805 6134 80.91.229.3 (15 May 2015 23:33:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 23:33:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 16 01:33:13 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtP6O-00052H-Oj for geh-help-gnu-emacs@m.gmane.org; Sat, 16 May 2015 01:33:12 +0200 Original-Received: from localhost ([::1]:33218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtP6O-00078Z-3N for geh-help-gnu-emacs@m.gmane.org; Fri, 15 May 2015 19:33:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtP69-00078U-W8 for help-gnu-emacs@gnu.org; Fri, 15 May 2015 19:32:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtP65-0005k1-K7 for help-gnu-emacs@gnu.org; Fri, 15 May 2015 19:32:57 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:41874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtP65-0005jZ-E1 for help-gnu-emacs@gnu.org; Fri, 15 May 2015 19:32:53 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YtP63-0004rW-Em for help-gnu-emacs@gnu.org; Sat, 16 May 2015 01:32:51 +0200 Original-Received: from 69-165-139-108.dsl.teksavvy.com ([69.165.139.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2015 01:32:51 +0200 Original-Received: from monnier by 69-165-139-108.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2015 01:32:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-165-139-108.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:yyZuQRPOun6CeC+ktz+jzxPZK5I= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:104460 Archived-At: > 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