all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nick Helm <nick@tenpoint.co.nz>
To: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: isolating history with buffer-local variables
Date: Fri, 15 May 2015 02:40:26 +0000	[thread overview]
Message-ID: <F9C8D19D-6816-4004-9A1B-FCFC8A85EA21@tenpoint.co.nz> (raw)
In-Reply-To: <jwvtwvgtbb4.fsf-monnier+gmane.emacs.help@gnu.org>


> On 14/05/2015, at 9:39 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Thanks.  I think this functionality is important and should largely be
> activated automatically when visiting encrypted files (not sure which
> other files/buffers would warrant such behavior).

I could add to auto-mode-alist to activate private-mode for .gpg files 
(for example), but I don't know if the file extension is a reliable 
enough way to identify an encrypted file. I'll have a look at epa-hook
instead. 

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).

> So I'm happy to see you work on this, and I encourage you try and make
> it work well, and contribute your code so we can include it directly
> in Emacs.

Gladly. I'll progress it as far as I can then ask for further critique
and suggestions.

>>   (if (symbol-value private-mode)
> 
> `private-mode' will normally have value either t or nil, and the
> symbol-value of nil is nil and the symbol-value of t is t, so the above
> is better written as "(if private-mode".
> 
>>      (setq private-variables '( ;; data to isolate
>>         minibuffer-history         ;; <-- not working
>>         command-history            ;; ok
>>         extended-command-history   ;; <-- not working
>>         string-rectangle-history   ;; <-- not working
>>         query-replace-history      ;; ok
>>         search-ring                ;; ok
>>         regexp-search-ring         ;; ok
>>         kill-ring                  ;; ok
>>         backup-inhibited           ;; ok
>>         auto-save-timeout))        ;; ok 
> 
> This should probably be moved out to a defvar.
> 
>>      (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.

>> All the local auto-save/backup vars, local ring vars, and local
>> query-replace-history and command-history vars work as intended. But
>> minibuffer-history, extended-command-history and
>> string-rectangle-history do not. The buffer-local vars for these are
>> made as expected, but they are ignored and histories continue to
>> accumulate in the global variables.
> 
> I think Pascal has the right explanation for that.

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).

>> Any idea why? Anyone have suggestions for a different approach or
>> a way around the problem?
> 
> You'll probably need to hack read-from-minibuffer (e.g. with an advice)
> so as to redirect the history variable to another variable, or to
> cleanup the variable after the fact.

Thanks, I'll give those a try.

> 
>        Stefan
> 
> 
> 




  reply	other threads:[~2015-05-15  2:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  2:10 isolating history with buffer-local variables Nick Helm
2015-05-13 21:39 ` Stefan Monnier
2015-05-15  2:40   ` Nick Helm [this message]
2015-05-15 23:32     ` Stefan Monnier
2015-05-20 15:52       ` Nick Helm
2015-05-20 21:26         ` Stefan Monnier
2015-05-25  0:39         ` Stefan Monnier
2015-05-25  2:06           ` Nick Helm
     [not found]           ` <mailman.3589.1432519466.904.help-gnu-emacs@gnu.org>
2015-05-25  2:12             ` Pascal J. Bourguignon
2015-05-25  3:14               ` Nick Helm
     [not found] <mailman.2920.1431489112.904.help-gnu-emacs@gnu.org>
2015-05-13  4:17 ` Pascal J. Bourguignon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F9C8D19D-6816-4004-9A1B-FCFC8A85EA21@tenpoint.co.nz \
    --to=nick@tenpoint.co.nz \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.