Skip to main content
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