From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: Multiple M-x shells sharing input ring Date: Thu, 04 Sep 2014 23:21:07 +0200 Message-ID: <87ha0njd4s.fsf@web.de> References: <87ppfbkw31.fsf@web.de> <7fba0cb5-c7a9-40ef-9de4-3191a6c52f3a@default> <87bnqvktkf.fsf@web.de> <6938458c-7116-458a-9e10-8397dfa5b25a@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1409865730 7128 80.91.229.3 (4 Sep 2014 21:22:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 21:22:10 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 04 23:22:03 2014 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 1XPeTh-00014d-QL for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 23:22:01 +0200 Original-Received: from localhost ([::1]:54229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeTh-00056b-Av for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 17:22:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeTN-00050V-If for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPeTA-000789-Fd for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:41 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:51580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeTA-000779-A0 for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:28 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XPeT8-0000dC-AT for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 23:21:26 +0200 Original-Received: from ip-90-186-74-63.web.vodafone.de ([90.186.74.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Sep 2014 23:21:26 +0200 Original-Received: from michael_heerdegen by ip-90-186-74-63.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Sep 2014 23:21:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 62 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-186-74-63.web.vodafone.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:HvmDd6aS6irwaj/9yJV7yusZj6w= 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:99656 Archived-At: Drew Adams writes: > There are not only two alternatives: permanent-local and global. > The normal way to handle what you describe is to make the variable > local in each buffer where it should be local. It can even be made > automatically local everywhere (`make-variable-buffer-local'). > > And any mode derived from comint mode that happens to want a separate > history can easily obtain that, even if the variable is not declared > automatically local. Nothing prevents scheme mode or whatever from > doing `make-buffer-local' in its buffers. That's the usual way these > things are done. Yes, but if you want to have a shared input history for all shell buffers, and another shared history for all interactive scheme buffers, using a global var is not good enough either. > AFAICT, `permanent-local' is for a different purpose. At least its > doc claims that. It speaks specifically of "the file". Again: > > Permanent locals are appropriate for data pertaining to where the > file came from or how to save it, rather than with how to edit the > contents. > > I don't see how anything in that description applies here. It doesn't say that it's inappropriate for all other cases ;-) > > It's not that easy, since `comint-mode' does a lot of explicit > > `make-local-variable' calls including for `comint-input-ring'. > > Why would it do that, if the variable is already permanent-local? > Doesn't permanent-local imply buffer-local? I think no: (put 'foo 'permanent-local t) (setq foo 1) (local-variable-p 'foo) ==> nil (make-local-variable 'foo) (setq foo 2) (local-variable-p 'foo) ==> t (kill-all-local-variables) (local-variable-p 'foo) ==> t > And even if it does that, that just makes the variable buffer-local. > What prevents one from then killing that local variable and using > the global one instead? Nothing, but I just think a per-mode input history could be more useful. Michael.