* bug#17361: Tramp does not save history across sessions. @ 2014-04-28 13:16 Le Wang 2014-04-28 13:45 ` Michael Albinus 0 siblings, 1 reply; 26+ messages in thread From: Le Wang @ 2014-04-28 13:16 UTC (permalink / raw) To: 17361 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 13:16 bug#17361: Tramp does not save history across sessions Le Wang @ 2014-04-28 13:45 ` Michael Albinus 2014-04-28 15:09 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Michael Albinus @ 2014-04-28 13:45 UTC (permalink / raw) To: Le Wang; +Cc: 17361 Le Wang <l26wang@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 13:45 ` Michael Albinus @ 2014-04-28 15:09 ` Stefan Monnier 2014-04-28 18:01 ` Michael Albinus 2014-04-28 15:26 ` Eli Zaretskii 2021-10-10 23:01 ` Stefan Kangas 2 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-28 15:09 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 15:09 ` Stefan Monnier @ 2014-04-28 18:01 ` Michael Albinus 2014-04-29 4:19 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-28 18:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 18:01 ` Michael Albinus @ 2014-04-29 4:19 ` Stefan Monnier 2014-04-29 7:32 ` Michael Albinus 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 4:19 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 4:19 ` Stefan Monnier @ 2014-04-29 7:32 ` Michael Albinus 2014-04-29 7:39 ` Daimrod 2014-04-29 13:42 ` Stefan Monnier 0 siblings, 2 replies; 26+ messages in thread From: Michael Albinus @ 2014-04-29 7:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 7:32 ` Michael Albinus @ 2014-04-29 7:39 ` Daimrod 2014-04-29 7:59 ` Michael Albinus 2014-04-29 13:38 ` Stefan Monnier 2014-04-29 13:42 ` Stefan Monnier 1 sibling, 2 replies; 26+ messages in thread From: Daimrod @ 2014-04-29 7:39 UTC (permalink / raw) To: 17361 Michael Albinus <michael.albinus@gmx.de> writes: > Stefan Monnier <monnier@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 7:39 ` Daimrod @ 2014-04-29 7:59 ` Michael Albinus 2014-04-29 8:34 ` Daimrod 2014-04-29 13:38 ` Stefan Monnier 1 sibling, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-29 7:59 UTC (permalink / raw) To: Daimrod; +Cc: 17361 Daimrod <daimrod@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 7:59 ` Michael Albinus @ 2014-04-29 8:34 ` Daimrod 0 siblings, 0 replies; 26+ messages in thread From: Daimrod @ 2014-04-29 8:34 UTC (permalink / raw) To: 17361 Michael Albinus <michael.albinus@gmx.de> writes: > Daimrod <daimrod@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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 7:39 ` Daimrod 2014-04-29 7:59 ` Michael Albinus @ 2014-04-29 13:38 ` Stefan Monnier 1 sibling, 0 replies; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 13:38 UTC (permalink / raw) To: Daimrod; +Cc: 17361 > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 7:32 ` Michael Albinus 2014-04-29 7:39 ` Daimrod @ 2014-04-29 13:42 ` Stefan Monnier 2014-04-29 13:52 ` Michael Albinus 1 sibling, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 13:42 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 13:42 ` Stefan Monnier @ 2014-04-29 13:52 ` Michael Albinus 2014-04-29 14:30 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-29 13:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 13:52 ` Michael Albinus @ 2014-04-29 14:30 ` Stefan Monnier 2014-04-29 14:42 ` Michael Albinus 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 14:30 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 14:30 ` Stefan Monnier @ 2014-04-29 14:42 ` Michael Albinus 2014-04-29 15:33 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-29 14:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 14:42 ` Michael Albinus @ 2014-04-29 15:33 ` Stefan Monnier 2014-04-29 18:09 ` Michael Albinus 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 15:33 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 15:33 ` Stefan Monnier @ 2014-04-29 18:09 ` Michael Albinus 2014-04-29 19:40 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-29 18:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 18:09 ` Michael Albinus @ 2014-04-29 19:40 ` Stefan Monnier 2014-04-29 21:24 ` Michael Albinus 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 19:40 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 >>> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 19:40 ` Stefan Monnier @ 2014-04-29 21:24 ` Michael Albinus 2014-04-29 22:08 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-29 21:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: Le Wang, 17361 Stefan Monnier <monnier@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 21:24 ` Michael Albinus @ 2014-04-29 22:08 ` Stefan Monnier 2014-05-29 16:21 ` Glenn Morris 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2014-04-29 22:08 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-29 22:08 ` Stefan Monnier @ 2014-05-29 16:21 ` Glenn Morris 0 siblings, 0 replies; 26+ messages in thread From: Glenn Morris @ 2014-05-29 16:21 UTC (permalink / raw) To: 17361, Le Wang Sorry, I closed this bug by mistake. Reopening. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 13:45 ` Michael Albinus 2014-04-28 15:09 ` Stefan Monnier @ 2014-04-28 15:26 ` Eli Zaretskii 2014-04-28 18:05 ` Michael Albinus 2021-10-10 23:01 ` Stefan Kangas 2 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2014-04-28 15:26 UTC (permalink / raw) To: Michael Albinus; +Cc: l26wang, 17361 > From: Michael Albinus <michael.albinus@gmx.de> > Date: Mon, 28 Apr 2014 15:45:34 +0200 > Cc: 17361@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 15:26 ` Eli Zaretskii @ 2014-04-28 18:05 ` Michael Albinus 2014-04-28 18:15 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Michael Albinus @ 2014-04-28 18:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: l26wang, 17361 Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 18:05 ` Michael Albinus @ 2014-04-28 18:15 ` Eli Zaretskii 2014-04-28 20:20 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2014-04-28 18:15 UTC (permalink / raw) To: Michael Albinus; +Cc: l26wang, 17361 > From: Michael Albinus <michael.albinus@gmx.de> > Cc: l26wang@gmail.com, 17361@debbugs.gnu.org > Date: Mon, 28 Apr 2014 20:05:17 +0200 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 18:15 ` Eli Zaretskii @ 2014-04-28 20:20 ` Stefan Monnier 0 siblings, 0 replies; 26+ messages in thread From: Stefan Monnier @ 2014-04-28 20:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: l26wang, Michael Albinus, 17361 >> > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2014-04-28 13:45 ` Michael Albinus 2014-04-28 15:09 ` Stefan Monnier 2014-04-28 15:26 ` Eli Zaretskii @ 2021-10-10 23:01 ` Stefan Kangas 2021-10-11 15:41 ` Michael Albinus 2 siblings, 1 reply; 26+ messages in thread From: Stefan Kangas @ 2021-10-10 23:01 UTC (permalink / raw) To: Michael Albinus; +Cc: Le Wang, 17361 Michael Albinus <michael.albinus@gmx.de> writes: > Le Wang <l26wang@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? ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#17361: Tramp does not save history across sessions. 2021-10-10 23:01 ` Stefan Kangas @ 2021-10-11 15:41 ` Michael Albinus 0 siblings, 0 replies; 26+ messages in thread From: Michael Albinus @ 2021-10-11 15:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: Le Wang, 17361 Stefan Kangas <stefan@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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2021-10-11 15:41 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-28 13:16 bug#17361: Tramp does not save history across sessions Le Wang 2014-04-28 13:45 ` Michael Albinus 2014-04-28 15:09 ` Stefan Monnier 2014-04-28 18:01 ` Michael Albinus 2014-04-29 4:19 ` Stefan Monnier 2014-04-29 7:32 ` Michael Albinus 2014-04-29 7:39 ` Daimrod 2014-04-29 7:59 ` Michael Albinus 2014-04-29 8:34 ` Daimrod 2014-04-29 13:38 ` Stefan Monnier 2014-04-29 13:42 ` Stefan Monnier 2014-04-29 13:52 ` Michael Albinus 2014-04-29 14:30 ` Stefan Monnier 2014-04-29 14:42 ` Michael Albinus 2014-04-29 15:33 ` Stefan Monnier 2014-04-29 18:09 ` Michael Albinus 2014-04-29 19:40 ` Stefan Monnier 2014-04-29 21:24 ` Michael Albinus 2014-04-29 22:08 ` Stefan Monnier 2014-05-29 16:21 ` Glenn Morris 2014-04-28 15:26 ` Eli Zaretskii 2014-04-28 18:05 ` Michael Albinus 2014-04-28 18:15 ` Eli Zaretskii 2014-04-28 20:20 ` Stefan Monnier 2021-10-10 23:01 ` Stefan Kangas 2021-10-11 15:41 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git 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).