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 14:20:56 -0700 (PDT) Message-ID: 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 1409865699 6213 80.91.229.3 (4 Sep 2014 21:21:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 21:21:39 +0000 (UTC) To: Stefan Monnier , 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:21: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 1XPeTC-0000gZ-BS for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 23:21:30 +0200 Original-Received: from localhost ([::1]:54226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeTB-0004aK-SG for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 17:21:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeSr-0004Vw-R7 for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPeSj-00073T-4o for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:09 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:30612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPeSi-00073I-Ul for help-gnu-emacs@gnu.org; Thu, 04 Sep 2014 17:21:01 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s84LKxVO009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2014 21:21:00 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s84LKw7A000897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2014 21:20:59 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s84LKvRZ029433; Thu, 4 Sep 2014 21:20:57 GMT In-Reply-To: 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: 141.146.126.69 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:99655 Archived-At: > > 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. >=20 > permanent-local is used to mark variables as pertaining to the > content of a buffer rather than to its mode. So presumably that doc should be changed to speak of "the buffer" instead of "the file". The sentence you just wrote is clearer than what is in the doc, IMO. > The effect it has is that the variable won't be reset if you > change major mode (i.e. it's not "killed" by kill-local-variables). >=20 > It's reasonably common in comint buffer to reset the major mode > (typically, you kill the process and re-run it which sets up the > comint mode again) and you generally want to preserve the > input-history, hence the `permanent-local' property. I see. Yes, I guess that makes sense. It is a use case that is perhaps worth pointing out in the doc. > Note also that the `permanent-local' property does not make a > variable buffer-local. It just makes it stay local longer, in > case it was made local. I see. I thought it also made the variable buffer-local.