GNU bug report logs - #17361
Tramp does not save history across sessions.

Previous Next

To reply to this bug, email your comments to 17361 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Le Wang <l26wang <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 09:16:14 -0400

Tramp installs its own sentinel -- tramp-process-sentinel -- over
shell-mode's shell-write-history-on-exit.  What's the way to write to
history file when the process ends without using defadvice?

Could the default behave better?


-- 
Le

Message #8 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Le Wang <l26wang <at> gmail.com>
Cc: 17361 <at> debbugs.gnu.org
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 15:45:34 +0200

Le Wang <l26wang <at> gmail.com> writes:

> Tramp installs its own sentinel -- tramp-process-sentinel -- over
> shell-mode's shell-write-history-on-exit.  What's the way to write to
> history file when the process ends without using defadvice?
>
> Could the default behave better?

The problem seems to be more general. Emacs does not support to have
several process sentinels for a given process. If several sentinels are
declared for a process by ?`set-process-sentinel', they compete for
being attached to the process. And the last one wins.

So we need to support several sentinels per process. Maybe this exist
already, but I'm not aware of such a mechanism.

Stefan?

Best regards, Michael.

Message #11 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 11:09:34 -0400

> The problem seems to be more general. Emacs does not support to have
> several process sentinels for a given process. If several sentinels are
> declared for a process by ?`set-process-sentinel', they compete for
> being attached to the process. And the last one wins.

Not true any more: Emacs-24.4's `add-function' was invented in response
to this specific request (or maybe it was for set-process-filter, but
the point stands).


        Stefan

Message #14 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, l26wang <at> gmail.com
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 18:26:45 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Mon, 28 Apr 2014 15:45:34 +0200
> Cc: 17361 <at> debbugs.gnu.org
> 
> So we need to support several sentinels per process.

Or a protocol: if you install a sentinel, and another one already
exists, call it after yours.

Message #17 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 20:01:54 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> Not true any more: Emacs-24.4's `add-function' was invented in response
> to this specific request (or maybe it was for set-process-filter, but
> the point stands).

Ah, thanks. I wasn't aware of this use case. However, shouldn't this be
propagated further? The Elisp info pages do not mention this use case,
when speaking about `set-process-filter' or `set-process-sentinel'.

Anyway, I'll try to rewrite Tramp's process filters and sentinels next
days. As usual, the crucial point will be backward compatibility ...

>         Stefan

Best regards, Michael.

Message #20 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17361 <at> debbugs.gnu.org, l26wang <at> gmail.com
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 20:05:17 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> So we need to support several sentinels per process.
>
> Or a protocol: if you install a sentinel, and another one already
> exists, call it after yours.

Yes. But all of the sentinels (or filters) must play the same game
then. When Tramp's sentinel is the first one being activated, it
shouldn't be thrown away by a `set-process-sentinel' call from another
library. We don't know in advance, in which order sentinels are
installed for a given process.

Best regards, Michael.

Message #23 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, l26wang <at> gmail.com
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 21:15:36 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: l26wang <at> gmail.com,  17361 <at> debbugs.gnu.org
> Date: Mon, 28 Apr 2014 20:05:17 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> So we need to support several sentinels per process.
> >
> > Or a protocol: if you install a sentinel, and another one already
> > exists, call it after yours.
> 
> Yes. But all of the sentinels (or filters) must play the same game
> then.

Indeed, the protocol should be universally enforced.

Message #26 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17361 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>,
 l26wang <at> gmail.com
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 28 Apr 2014 16:20:08 -0400

>> > Or a protocol: if you install a sentinel, and another one already
>> > exists, call it after yours.
>> Yes. But all of the sentinels (or filters) must play the same game
>> then.
> Indeed, the protocol should be universally enforced.

AFAIK add-function does that.


        Stefan

Message #29 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 00:19:29 -0400

> Ah, thanks. I wasn't aware of this use case. However, shouldn't this be
> propagated further? The Elisp info pages do not mention this use case,
> when speaking about `set-process-filter' or `set-process-sentinel'.

I added some advertisement for add-function in those sections, thanks.


        Stefan

Message #32 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 09:32:19 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Ah, thanks. I wasn't aware of this use case. However, shouldn't this be
>> propagated further? The Elisp info pages do not mention this use case,
>> when speaking about `set-process-filter' or `set-process-sentinel'.
>
> I added some advertisement for add-function in those sections, thanks.

Reading your text, I wonder how one should implement this. Usually, one
doesn't know which other library intends to set a filter or a process.

In stock Emacs, there are 43 files with calls of `set-process-filter',
and 53 files with calls of `set-process-sentinel'. In the elpa branch,
there are 4/4 additional such files. All those places must be adapted,
checking whether there could be several filters or sentinels.

Wouldn't it be more consistent to modify `set-process-filter' and
´set-process-sentinel' to take care, when several filters or sentinels
are added to a given process? Both functions could be equipped with an
optional argument WHERE, which has the similar meaning as in
`add-function'. Maybe just :before, :after and :replace shall be
allowed, and one of them (:after?) could be the default.

>         Stefan

Best regards, Michael.

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daimrod <daimrod <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 16:39:11 +0900

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> Ah, thanks. I wasn't aware of this use case. However, shouldn't this be
>>> propagated further? The Elisp info pages do not mention this use case,
>>> when speaking about `set-process-filter' or `set-process-sentinel'.
>>
>> I added some advertisement for add-function in those sections, thanks.
>
> Reading your text, I wonder how one should implement this. Usually, one
> doesn't know which other library intends to set a filter or a process.

I was thinking about the same thing.

> In stock Emacs, there are 43 files with calls of `set-process-filter',
> and 53 files with calls of `set-process-sentinel'. In the elpa branch,
> there are 4/4 additional such files. All those places must be adapted,
> checking whether there could be several filters or sentinels.
>
> Wouldn't it be more consistent to modify `set-process-filter' and
> ´set-process-sentinel' to take care, when several filters or sentinels
> are added to a given process? Both functions could be equipped with an
> optional argument WHERE, which has the similar meaning as in
> `add-function'. Maybe just :before, :after and :replace shall be
> allowed, and one of them (:after?) could be the default.

What about having a default sentinel/filter for all process that does
nothing (just a placeholder)?

Then instead of using `set-process-filter' one could use
(add-function :whatever (process-filter process) ...)

-- 
Daimrod/Greg

Message #38 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daimrod <daimrod <at> gmail.com>
Cc: 17361 <at> debbugs.gnu.org
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 09:59:57 +0200

Daimrod <daimrod <at> gmail.com> writes:

>> Wouldn't it be more consistent to modify `set-process-filter' and
>> ´set-process-sentinel' to take care, when several filters or sentinels
>> are added to a given process? Both functions could be equipped with an
>> optional argument WHERE, which has the similar meaning as in
>> `add-function'. Maybe just :before, :after and :replace shall be
>> allowed, and one of them (:after?) could be the default.
>
> What about having a default sentinel/filter for all process that does
> nothing (just a placeholder)?

There are already `internal-default-process-filter' and
`internal-default-process-sentinel'. They must be replaced, of course,
when a new filter/sentinel is added.

> Then instead of using `set-process-filter' one could use
> (add-function :whatever (process-filter process) ...)

Nope. One would need to change all places those functions are called. I
believe it is simpler to modify `set-process-filter' and
`set-process-sentinel'.

Best regards, Michael.

Message #41 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Daimrod <daimrod <at> gmail.com>
To: 17361 <at> debbugs.gnu.org
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 17:34:41 +0900

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Daimrod <daimrod <at> gmail.com> writes:
>
>>> Wouldn't it be more consistent to modify `set-process-filter' and
>>> ´set-process-sentinel' to take care, when several filters or sentinels
>>> are added to a given process? Both functions could be equipped with an
>>> optional argument WHERE, which has the similar meaning as in
>>> `add-function'. Maybe just :before, :after and :replace shall be
>>> allowed, and one of them (:after?) could be the default.
>>
>> What about having a default sentinel/filter for all process that does
>> nothing (just a placeholder)?
>
> There are already `internal-default-process-filter' and
> `internal-default-process-sentinel'. They must be replaced, of course,
> when a new filter/sentinel is added.

Oh, I wasn't aware of those functions.

>> Then instead of using `set-process-filter' one could use
>> (add-function :whatever (process-filter process) ...)
>
> Nope. One would need to change all places those functions are called. I
> believe it is simpler to modify `set-process-filter' and
> `set-process-sentinel'.

I see. Thanks for the explanation.

-- 
Daimrod/Greg

Message #44 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Daimrod <daimrod <at> gmail.com>
Cc: 17361 <at> debbugs.gnu.org
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 09:38:30 -0400

> What about having a default sentinel/filter for all process that does
> nothing (just a placeholder)?

That is already the case since 24.4.

> Then instead of using `set-process-filter' one could use
> (add-function :whatever (process-filter process) ...)

That's the idea.


        Stefan

Message #47 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 09:42:33 -0400

> Reading your text, I wonder how one should implement this. Usually, one
> doesn't know which other library intends to set a filter or a process.

That's a good question.  So far it works well when you know enough of
the various places that want to set a filter, so you can make sure only
one of them uses set-process-filter (and does it before the others).


        Stefan

Message #50 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 15:52:12 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> So far it works well when you know enough of the various places that
> want to set a filter, so you can make sure only one of them uses
> set-process-filter (and does it before the others).

Maybe. But Tramp cannot know who is using it. It just offers (its own
implementation of) very primitive functions, that's it. And it cannot
know, whether the calling library is doing its settings before or after
Tramp's setup.

That's what this bug report is about.

>         Stefan

Best regards, Michael.

Message #53 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 10:30:22 -0400

>> So far it works well when you know enough of the various places that
>> want to set a filter, so you can make sure only one of them uses
>> set-process-filter (and does it before the others).
> Maybe. But Tramp cannot know who is using it. It just offers (its own
> implementation of) very primitive functions, that's it. And it cannot
> know, whether the calling library is doing its settings before or after
> Tramp's setup.
> That's what this bug report is about.

The fix is to make those other packages use add-function as well, then.


        Stefan

Message #56 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 16:42:56 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> Maybe. But Tramp cannot know who is using it. It just offers (its own
>> implementation of) very primitive functions, that's it. And it cannot
>> know, whether the calling library is doing its settings before or after
>> Tramp's setup.
>> That's what this bug report is about.
>
> The fix is to make those other packages use add-function as well, then.

And why not modify `set-process-sentinel'? This would be less changes in
the different packages.

>         Stefan

Best regards, Michael.

Message #59 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 11:33:51 -0400

> And why not modify `set-process-sentinel'? This would be less changes in
> the different packages.

No, same difference: the calls need to be changed anyway.


        Stefan

Message #62 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 20:09:21 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> And why not modify `set-process-sentinel'? This would be less changes in
>> the different packages.
>
> No, same difference: the calls need to be changed anyway.

Not, if we use a proper default for WHERE, the new optional arg of
`set-process-sentinel'.

>         Stefan

Best regards, Michael.

Message #65 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 15:40:08 -0400

>>> And why not modify `set-process-sentinel'? This would be less changes in
>>> the different packages.
>> No, same difference: the calls need to be changed anyway.
> Not, if we use a proper default for WHERE, the new optional arg of
> `set-process-sentinel'.

The only default that's backward compatible would be :override, which
basically defeats the purpose.


        Stefan

Message #68 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 23:24:46 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>>>> And why not modify `set-process-sentinel'? This would be less changes in
>>>> the different packages.
>>> No, same difference: the calls need to be changed anyway.
>> Not, if we use a proper default for WHERE, the new optional arg of
>> `set-process-sentinel'.
>
> The only default that's backward compatible would be :override, which
> basically defeats the purpose.

In practice, your proposal means to throw away `set-process-sentinel'
(and `set-process-filter'). Since the default functions are already
enabled, in most cases one shall use `add-function' instead. Which is
more complicate.

Do we want such a radical change? Your wording, you have applied in
processes.texi, sounds different.

(I don't oppose completely, I just want that we understand and agree
such a change.)

>         Stefan

Best regards, Michael.

Message #71 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Tue, 29 Apr 2014 18:08:21 -0400

>> The only default that's backward compatible would be :override, which
>> basically defeats the purpose.
> In practice, your proposal means to throw away `set-process-sentinel'
> (and `set-process-filter').

[ Of course, only on the surface, since these are the low-level accessors
  used by add-function.  ]

> Since the default functions are already enabled, in most cases one
> shall use `add-function' instead.

There is a real problem with the default filter/sentinel, indeed.
Basically, add-function is a mechanism that allows combining functions
onto a "single function spot", so it provides the tool we need.

But another problem remains: for historical reasons (and for
convenience), the default filters/sentinels don't "do nothing".  So in
many cases packages want to *replace* the default rather than extend it.
`set-process-filter' works well for those, until another package comes
along which needs to interact with it.  Saying "use add-function"
doesn't really solve this problem, because we'll just replace

  (set-process-filter PROC FUN)
with
  (add-function :override (process-filter PROC) FUN)

which, just like set-process-filter, will override not just the default
filter but other filters added via add-function as well.

I haven't thought about how to really solve this problem.  I'm open
to suggestions.

> (I don't oppose completely, I just want that we understand and agree
> such a change.)

I don't have a good answer yet, sorry.


        Stefan

Message #78 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 17361 <at> debbugs.gnu.org,  Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Thu, 29 May 2014 12:21:45 -0400

Sorry, I closed this bug by mistake.
Reopening.

Message #83 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Sun, 10 Oct 2021 16:01:47 -0700

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Le Wang <l26wang <at> gmail.com> writes:
>
>> Tramp installs its own sentinel -- tramp-process-sentinel -- over
>> shell-mode's shell-write-history-on-exit.  What's the way to write to
>> history file when the process ends without using defadvice?
>>
>> Could the default behave better?
>
> The problem seems to be more general. Emacs does not support to have
> several process sentinels for a given process. If several sentinels are
> declared for a process by ?`set-process-sentinel', they compete for
> being attached to the process. And the last one wins.
>
> So we need to support several sentinels per process. Maybe this exist
> already, but I'm not aware of such a mechanism.

(That was 7.5 years ago.)

What followed was a discussion about how Tramp should use 'add-function'
instead of 'set-process-sentinel', IIUC.  Is this still an issue, or has
the situation changed since?

Message #86 received at 17361 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 17361 <at> debbugs.gnu.org, Le Wang <l26wang <at> gmail.com>
Subject: Re: bug#17361: Tramp does not save history across sessions.
Date: Mon, 11 Oct 2021 17:41:15 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

Hi Stefan,

> (That was 7.5 years ago.)
>
> What followed was a discussion about how Tramp should use 'add-function'
> instead of 'set-process-sentinel', IIUC.  Is this still an issue, or has
> the situation changed since?

Tramp still uses set-process-sentinel. I will change it to use
add-function instead, and I will run my regression tests.

However, we still need to adapt the set-process-sentinel calls elsewhere
in the code base. And of course, this will have to go to master, which
means I have to cut a new Tramp branch.

And the same game for set-process-filter, right?

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.