Timeline for How to stop a process gracefully before killing its buffer?
Current License: CC BY-SA 4.0
17 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Apr 1, 2023 at 21:24 | vote | accept | Arch Stanton | ||
Apr 1, 2023 at 9:28 | history | edited | Arch Stanton | CC BY-SA 4.0 |
edited body
|
Apr 1, 2023 at 9:21 | history | edited | Arch Stanton | CC BY-SA 4.0 |
deleted 53 characters in body
|
Apr 1, 2023 at 9:08 | history | edited | Arch Stanton | CC BY-SA 4.0 |
deleted 398 characters in body
|
Apr 1, 2023 at 8:44 | history | edited | Arch Stanton | CC BY-SA 4.0 |
added 1799 characters in body
|
Mar 31, 2023 at 22:10 | comment | added | phils |
Case-by-case -- it 100% depends on what the original sentinel does. In that example I see there's another buffer (:accum_buffer ?) which the default sentinel kills at the beginning, so maybe you do want that to run first, to ensure it cleans up after itself? You can call ess-process-sentinel in your function as an alternative to advice, which is quite likely to be equivalent in practice (i.e. so long as nothing else is messing with the sentinel for this).
|
|
Mar 31, 2023 at 20:47 | history | edited | Arch Stanton | CC BY-SA 4.0 |
edited body
|
Mar 31, 2023 at 20:08 | history | edited | Arch Stanton | CC BY-SA 4.0 |
deleted 7 characters in body
|
Mar 31, 2023 at 14:02 | comment | added | Arch Stanton | @phils ESS does set its own sentinel for its processes, but if I advise it I guess it'll kill the process' buffer and window every time I exit one, which is not what I want. Is there something wrong with replacing a sentinel like my function does? | |
Mar 31, 2023 at 11:51 | comment | added | phils |
My other tip about sentinels is to remember that a process has only one of them -- if you set a sentinel, you're replacing any pre-existing sentinel. As such, it can be a good idea to figure out if it's just using internal-default-process-sentinel (the default), or if there's something else already configured. If necessary you could call he original function explicitly in your sentinel, or else use something along the lines of (add-function :after (process-sentinel proc) #'my-sentinel) (which I haven't tested, but (elisp)Advising Functions provides a similar example for filters).
|
|
Mar 31, 2023 at 11:36 | comment | added | phils |
That's fair enough -- your process-live-p approach was probably fine. I'd be inclined to use explicit status tests as a general rule in sentinels, though -- sentinels can be called for a number of reasons, so I think it makes the purpose clearer. Regarding the and form, that's just personal preference -- (and x y z) is simpler than (when (and x y) z) . The byte compiler will optimise the latter to the former, though, so it makes no real difference.
|
|
Mar 31, 2023 at 9:25 | history | edited | Arch Stanton | CC BY-SA 4.0 |
Update according to comments
|
Mar 31, 2023 at 9:14 | comment | added | Arch Stanton |
Also, is there a particular reason why you call kill-buffer within the and form?
|
|
Mar 31, 2023 at 9:08 | comment | added | Arch Stanton |
@phils Thanks for the tips :-) Why not use process-live-p ? The manual says A process is considered alive if its status is run , open , listen , connect or stop . So I thought I was checking the signal.
|
|
Mar 31, 2023 at 8:59 | comment | added | phils |
n.b. I would usually be dealing with (process-buffer process) within a sentinel function, so I've shown that, but I don't know what (ess-get-process-buffer) actually does.
|
|
Mar 31, 2023 at 8:57 | comment | added | phils |
Nice one. A couple of things... 1. You should set the sentinel before calling ess-quit -- it may well never make a difference in practice, but in principle if the process died instantly your sentinel might never have a chance to run if you don't try to set it until after you've asked it to exit. And 2, always check the signal in a sentinel: (lambda (process signal) (and (memq (process-status process) '(exit signal)) (buffer-live-p (process-buffer process)) (kill-buffer (process-buffer process))))
|
|
Mar 31, 2023 at 8:40 | history | answered | Arch Stanton | CC BY-SA 4.0 |