From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Multiple M-x shells sharing input ring Date: Thu, 4 Sep 2014 13:58:56 -0700 (PDT) Message-ID: <6938458c-7116-458a-9e10-8397dfa5b25a@default> References: <87ppfbkw31.fsf@web.de> <7fba0cb5-c7a9-40ef-9de4-3191a6c52f3a@default> <87bnqvktkf.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409864382 22981 80.91.229.3 (4 Sep 2014 20:59:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 20:59:42 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 04 22:59:32 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 1XPe7v-0002ci-EK for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 22:59:31 +0200 Original-Received: from localhost ([::1]:54141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPe7v-0005uQ-58 for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 16:59:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPe7b-0005pE-AA for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 16:59:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPe7S-0005U8-Jz for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 16:59:11 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:18629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPe7S-0005U1-Dw for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 16:59:02 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s84Kwwn8023777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2014 20:59:00 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s84Kwv2k024513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2014 20:58:57 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s84Kwv9k024506; Thu, 4 Sep 2014 20:58:57 GMT In-Reply-To: <87bnqvktkf.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:99652 Archived-At: > > Too bad that `comint-input-ring' is "permanent local". > > Should it be, or is that a bug? >=20 > The variable is made local in the comint code with > `make-local-variable'. Yes. > Since very different modes are based on comint, making such vars > permanently local seems ok in this case. You probably don't want to > share an input history between a shell and a scheme buffer. Using a > global variable is not a good idea here. 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. 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. Maybe the description is faulty. Or maybe this variable should not be permanent-local. But so far, the description does not seem (to me) to fit the `comint-input-history' case. > > Anyway, presumably you could remove its permanent-local status, > > by removing property `permanent-local' from symbol `comint-input- > > ring'. > > > > Then you should be able to use `kill-local-variable', to have all > > comint buffers share the same variable (value). > > 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? 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?