From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: help-gnu-emacs@gnu.org
Subject: RE: Multiple M-x shells sharing input ring
Date: Thu, 4 Sep 2014 13:58:56 -0700 (PDT) [thread overview]
Message-ID: <6938458c-7116-458a-9e10-8397dfa5b25a@default> (raw)
In-Reply-To: <87bnqvktkf.fsf@web.de>
> > Too bad that `comint-input-ring' is "permanent local".
> > Should it be, or is that a bug?
>
> 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?
next prev parent reply other threads:[~2014-09-04 20:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 8:54 Multiple M-x shells sharing input ring Joseph Xu
2014-09-04 14:58 ` Subhan Michael Tindall
2014-09-04 15:55 ` Joseph Xu
2014-09-04 19:46 ` Michael Heerdegen
2014-09-04 20:09 ` Drew Adams
2014-09-04 20:40 ` Michael Heerdegen
2014-09-04 20:58 ` Drew Adams [this message]
2014-09-04 21:21 ` Michael Heerdegen
2014-09-04 21:33 ` Drew Adams
2014-09-05 7:33 ` Joseph Xu
[not found] ` <mailman.8284.1409864361.1147.help-gnu-emacs@gnu.org>
2014-09-04 21:09 ` Stefan Monnier
2014-09-04 21:20 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6938458c-7116-458a-9e10-8397dfa5b25a@default \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=michael_heerdegen@web.de \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).