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

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> The patch seems to assume that notifications-notify works
>>> everywhere. That's not the case, since it depends on D-Bus it runs only
>>> for GNU/Linux systems.
>>
>> Thank you for pointing this out.  I had wondered about it while
>> preparing the patch but could not find a description of what happens
>> when notifications are not supported, other than the usual
>> "notifications-notify returns an integer ID".
>>
>> Does notifications-notify return nil in this case?  If so, I would like
>> to document this.  If not, wouldn't this make sense?
>
> Likely yes. It uses with-demoted-errors, which should return nil
> indeed.

In that case I think the proposed patch already behaves as it should,
without changing existing behaviour.  See the last few lines of the
function gnus-notifications:

  (let* ((photo-file (gnus-notifications-get-photo-file address))
         (notification-id (gnus-notifications-notify
                           (or (car address-components) address)
                           (mail-fetch-field "Subject")
                           photo-file)))
    (when notification-id
      ;; Register that we did notify this message.
      (push article (cdr group-notifications))
      ;; Register the notification ID for later actions.
      (setf (alist-get notification-id
                       gnus-notifications-id-to-msg)
            (list group article)))
    ...)

gnus-notifications-notify just calls notifications-notify, and the
resulting ID is not assumed to be non-nil.  Is this acceptable?  Or did
you mean something else when you said the patch assumes too much about
notifications-notify?

Here's the patch again, with an updated docstring for
gnus-notifications-notify: