Re: Calling internal-default-process-sentinel from another sentinel?

["Štěpán Němec" <stepnem@gmail.com>]

On Wed, 18 Nov 2020 09:44:18 -0500
Stefan Monnier wrote:

>>> `add-function` is your friend.
>>>
>>>     (add-function :around (process-sentinel proc)
>>>                   (lambda (orig-fun proc state)
>>>                     (if (one particular case)
>>>                         (do the thing)
>>>                       (funcall orig-fun proc state))))
>>
>> Thanks, I've seen similar examples in the code base, but always advising
>> an Elisp sentinel, not 'internal-default-process-sentinel', which is a C
>> function, and IIUC also would/might be called from C (e.g. from
>> status_notify ?). Or is the actual default sentinel some kind of a
>> wrapper?
>
> This is not advising 'internal-default-process-sentinel'.  It just
> replaces the sentinel by a new function which often delegates to the
> previous function, whichever that previous function was and without
> affecting that previous function's definition.
>
>> And even for Elisp sentinels, I figured I'd rather avoid advice, as even
>> when using a self-removing piece of advice, it still applies to all
>> (even unrelated) calls of the same sentinel function occurring until the
>> removal. Or am I missing something?
>
> You're confused: this is not an "advice".

Indeed, I hadn't realized that, even though "(process-sentinel proc)"
above would (before the add-function modification) evaluate to
'internal-default-process-sentinel', using `add-function' on that form
really works through `set-process-sentinel' (via a gv place reference)
and is thus different from advising 'internal-default-process-sentinel'
directly.

Thank you!

-- 
Štěpán