Multiple M-x shells sharing input ring

Multiple M-x shells sharing input ring

[Joseph Xu]

Hello,

Is there a way to have multiple M-x shell buffers share an input ring? For
example, if I have two shells running, A and B, and I enter a command into
A, I would like to be able to find it immediately in the input history of B
using M-p and M-r.

Thanks for your help,
Joseph

RE: Multiple M-x shells sharing input ring

[Subhan Michael Tindall]

Read up on 'history' in your shell documentation.
Different shells handle it differently, and it can be configured in some.


> -----Original Message-----
> From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org
> [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On
> Behalf Of Joseph Xu
> Sent: Thursday, September 04, 2014 1:54 AM
> To: help-gnu-emacs@gnu.org
> Subject: Multiple M-x shells sharing input ring
> 
> Hello,
> 
> Is there a way to have multiple M-x shell buffers share an input ring? For
> example, if I have two shells running, A and B, and I enter a command into A,
> I would like to be able to find it immediately in the input history of B using M-
> p and M-r.
> 
> Thanks for your help,
> Joseph

This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message.  Thank you.

Re: Multiple M-x shells sharing input ring

[Joseph Xu]

I'm using zsh and it is already configured to share history. However, I
thought the input ring and zsh's own history mechanism are two different
things. Am I wrong?

I noticed that each command I execute in an M-x shell is immediately
written to ~/.history. I assume the only problem is that emacs is only
repopulating the input ring from that file when the M-x shell starts, not
after each command. I wonder if it is possible (and not too slow) to
register a hook to make emacs reload from that file after each command.


On Thu, Sep 4, 2014 at 7:58 AM, Subhan Michael Tindall <
SubhanT@familycareinc.org> wrote:

> Read up on 'history' in your shell documentation.
> Different shells handle it differently, and it can be configured in some.
>
>
> > -----Original Message-----
> > From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org
> > [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On
> > Behalf Of Joseph Xu
> > Sent: Thursday, September 04, 2014 1:54 AM
> > To: help-gnu-emacs@gnu.org
> > Subject: Multiple M-x shells sharing input ring
> >
> > Hello,
> >
> > Is there a way to have multiple M-x shell buffers share an input ring?
> For
> > example, if I have two shells running, A and B, and I enter a command
> into A,
> > I would like to be able to find it immediately in the input history of B
> using M-
> > p and M-r.
> >
> > Thanks for your help,
> > Joseph
>
> This message is intended for the sole use of the individual and entity to
> which it is addressed and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If you are
> not the intended addressee, nor authorized to receive for the intended
> addressee, you are hereby notified that you may not use, copy, disclose or
> distribute to anyone the message or any information contained in the
> message. If you have received this message in error, please immediately
> advise the sender by reply email and delete the message.  Thank you.
>

Re: Multiple M-x shells sharing input ring

[Michael Heerdegen]

Joseph Xu <josephzxu@gmail.com> writes:

> Is there a way to have multiple M-x shell buffers share an input ring? For
> example, if I have two shells running, A and B, and I enter a command into
> A, I would like to be able to find it immediately in the input history of B
> using M-p and M-r.

Not without some dirty hack.

`shell' is based on comint.el that uses a buffer local history variable
(`comint-input-ring') for every buffer.

However, you can try to copy the history from one buffer to the other:

(defun my-use-comint-input-ring-from-buffer (buffer)
  (interactive "b")
  (setq comint-input-ring
        (with-current-buffer buffer comint-input-ring)))

If you do that from shell2 to use the history from shell1, they share
the same structure as history.  That works because the history is
realized as a list, and what you copy is internally a reference to that
same object.

Dunno whether doing that can cause any problems, but it seems to work
here as you want.

Michael.

RE: Multiple M-x shells sharing input ring

[Drew Adams]

> > Is there a way to have multiple M-x shell buffers share an input
> > ring?
> 
> Not without some dirty hack.
> 
> `shell' is based on comint.el that uses a buffer local history
> variable (`comint-input-ring') for every buffer.  However, you can
> try to copy the history from one buffer to the other:...

Too bad that `comint-input-ring' is "permanent local".
Should it be, or is that a bug?

(elisp) `' says that a permanent-local variable is one that is

  "appropriate for data pertaining to where the file came
   from or how to save it, rather than with how to edit the contents."

It does not sound to me like `comint-input-ring' fits that description
at all.

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).  (Dunno whether that
is what is what Joseph wants.)

From (emacs) `Locals':

  `M-x kill-local-variable' makes a specified variable cease to be
  local to the current buffer.  The global value of the variable
  henceforth is in effect in this buffer.  Setting the major mode
  kills all the local variables of the buffer except for a few
  variables specially marked as "permanent locals".

Presumably, any buffer where you do that would then use the
global value of `comint-input-ring'.  (And of course that would 
then be the ring that gets updated from any such buffer.)

I haven't tried any of this, but you might want to give it a try:

(put 'comint-input-ring 'permanent-local nil) ; Do once
(kill-local-variable 'comint-input-ring) ; Do in each shell buffer

Re: Multiple M-x shells sharing input ring

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

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

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.

> It does not sound to me like `comint-input-ring' fits that description
> at all.
>
> 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).  (Dunno whether that
> is what is what Joseph wants.)

It's not that easy, since `comint-mode' does a lot of explicit
`make-local-variable' calls including for `comint-input-ring'.

Michael.

RE: Multiple M-x shells sharing input ring

[Drew Adams]

> > 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?

Re: Multiple M-x shells sharing input ring

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> 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.

RE: Multiple M-x shells sharing input ring

[Drew Adams]

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

True.  But nothing says that scheme mode cannot use a different
global variable.  Just because it is derived from comint mode does
not mean that it needs to stay in lockstep with other comint-mode
(or derived-p) buffers.

> >  Permanent locals are appropriate for...
>
> It doesn't say that it's inappropriate for all other cases ;-)

Oh, come on.

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

OK.  But see above.  I don't disagree with the per-mode part.

But starting with per-comint-mode is not a bad start.  Any mode
derived from comint-mode could then, if it needed, use its own
separate variable - for all of its buffers (shared).  Or it
could use a separate history for each of its buffers, as is the
case now.  (Or for some but not others.)

Anyway, I think we've probably beat this request to death. ;-)
It should be clear now that Joseph can get any combination of
behaviors he wants, and there are different ways to do that.

Re: Multiple M-x shells sharing input ring

[Joseph Xu]

Thanks for all the feedback. Unfortunately I'm not very familiar with
elisp, and most of the discussion went over my head.

In the end I was able to get the behavior I wanted by just adding a hook to
comint-input-filter-functions that executes comint-read-input-ring, which
reloads the history ring from file after every command. This only works
because I use zsh and have SHARED_HISTORY on, so every executed command is
immediately written to ~/.history. Not very elegant, but I don't have to
hack elisp, and has the extra benefit of being able to share history with
other terminals.

Regards,
Joseph

Re: Multiple M-x shells sharing input ring

[Stefan Monnier]

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

permanent-local is used to mark variables as pertaining to the content
of a buffer rather than to its mode.  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).

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.

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.


        Stefan

RE: Multiple M-x shells sharing input ring

[Drew Adams]

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