[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: STOP this patch for now.

From: Christian Hopps
Subject: Re: STOP this patch for now.
Date: Thu, 08 Jul 2021 08:02:19 -0400
User-agent: mu4e 1.5.13; emacs 27.2

stardiviner <numbchild@gmail.com> writes:

    On Jul 8, 2021, at 4:59 PM, Christian Hopps <chopps@chopps.org>

    It may eventually be incorporated into the very popular emacs-mac
    port (railwaycat tap in homebrew); however, it will probably not
    be incorporated into the nextstep/emacs main code. I started
    looking at doing a version for the mainline code, but it’s hard
    to get motivated b/c using that version of emacs on OS X is a
    pretty sub-par experience.

Thanks for your work on this support. I found upstream is less
active. Don’t know when will be merged.

    I only commented on this b/c I think you might are disabling
    notifications-notify which work great with my code changes, and
    using something else if you see Darwin OS, and that will break my
    native “Just Works” support for notifications, which again may
    end up on many peoples machines. I would ask that the patch be
    modified in a way that didn’t break native support if present
    before it was accepted.

    Also as you can see by the multiple patches you’ve submitted
    there’s really no good answer for an external notifier, so
    whatever you pick is probably going to be wrong for someone I

Yes, this troubled my too. Currently no good solution. I will stop
this patch for now. Wait for upstream emacs-mac port support. Hope it
will be arrived in at leas half of year.

You could add a comment to the pull-request in support of merging. :)


FWIW, if you are currently using the railwaycat tap in homebrew you can just 
switch to my tap and you'll get the support right now. It should be just as 
easy to install.


    If this patch is going to be accepted I would ask that it

    1) be conditional (disable-able with a variable)
    2) do the check for the custom installed external notifier and if
    not present then fallback to using the emacs supplied
    3) not restrict notifications-notify to gnu/linux only.

    That way people that have already developed solutions for this
    won’t have them broken.


        On Jul 7, 2021, at 8:00 PM, stardiviner <numbchild@gmail.com>

        Hi Chris, thanks for your work. I have a question, will your
        patch of notification code be merged to upstream?
        If yes, I think my patch will be not necessary. If no, then I
        think add a my workaround for macOS is considerable.

            On Jul 7, 2021, at 2:23 AM, Christian Hopps <
            chopps@chopps.org> wrote:

            It supports imagemagick (specify —with-imagemagick), and
            it includes svg by default, I simply forked the
            railwaycat version and added the native notification


                On Jul 6, 2021, at 11:30 AM, stardiviner <
                numbchild@gmail.com> wrote:

                Thanks for your suggestion. Does your Emacs build
                supports imagemagick image view and svg feature
                support? Because company-mode now have built-in icons
                support. This is the reason that I switch from https:
                //emacsformacosx.com/ to Homebrew cask Emacs version.

                    On Jul 6, 2021, at 12:21 PM, Christian Hopps <
                    chopps@chopps.org> wrote:


                    Please consider: I added full native notification
                    support to the popular OS X Emacs build available
                    in homebrew. This supports rewrites
                    notifications-notify defun to use the native code
                    rather than dbus, and so everything "Just Works".

                    Info can be found here:



                    stardiviner <numbchild@gmail.com> writes:

                        Here is the new patch which invokes
                        notifications though Emacs built-in API

                        [2. text/x-patch;

                            On Jul 6, 2021, at 8:06 AM, Tim Cross <
                            theophilusx@gmail.com> wrote:

                            stardiviner <numbchild@gmail.com> writes:

                                    On Jul 5, 2021, at 7:55 PM, Maxim
                                    Nikulin <manikulin@gmail.com>

                                    On 05/07/2021 10:50, stardiviner

                                        I updated the patch, I found
                                        the package `osx-lib`
                                        contains solution.
                                        So I removed the directly
                                        osascript process invocation.

                                    I have no objections any more. On
                                    the other hand I have no access
                                    to macOS, so
                                    I have not tested this patch.
                                    Feel free to ignore comments from
                                    this message,
                                    they are mostly matter of taste.

                                    I expect that a simple script
                                    "notify-send" may allow to avoid
                                    modification of
                                    code. Something like (untested,
                                    unsure concerning "quoted form of

                                    #!/usr/bin/env osascript
                                    display notification (item 1 of

                                    However if osx-lib in is
                                    installed automatically, it may
                                    be more convenient.
                                    Unsure if some of currently
                                    supported linux distributions
                                    have notify-send
                                    that can not handle title as the
                                    first argument.

                                        - ((fboundp
                                        + ((and (eq system-type 'gnu/
                                        linux) (fboundp

                                    Does it mean that
                                    `notifications-notify' is bound
                                    but it does not work on
                                    macOS? If so, maybe it is better
                                    to put new clause for 'darwin
                                    above and to
                                    drop 'gnu/linux here. From my
                                    point of view, it is preferable
                                    to avoid
                                    additional requirement for
                                    `notifications-notify'. If
                                    someone will create a
                                    feature request for
                                    `notifications-notify' for macOS,
                                    it will just work
                                    without installing of additional
                                    packages as soon as such feature

                                I indeed tried `notifications-notify
                                `. And it does not work, reports
                                error that
                                it needs dbus. PS. I used the
                                Homebrew formulae version Emacs.
                                I considered the order of conditions.
                                Because notifications and notify-send
                                requires dbus. So I guess only Linux
                                supports that. So add system-type
                                will be better. WDYT?

                            I think you can add dbus support to macOS
                            using homebrew and that might
                            resolve the issue. At the very least,
                            this will need to be investigated
                            because otherwise, adding this patch may
                            break configurations for users
                            who have added dbus support via homebrew
                            and have notifications working,
                            but have not installed the osx-lib

                            My only small concern with your proposed
                            changes is that it will add a
                            dependency on a new package osx-lib,
                            which I think is only available in
                            melpa. At the very least, this will need
                            to be documented somewhere.
                            However, I'm not sure what the situation
                            is wrt adding code which
                            depends on an external package which is
                            not available in either elpa or
                            nongnuELPA? As org mode is a part of GNU
                            Emacs, I suspect that any code
                            which 'encourages' the use of melpa
                            packages will not be acceptable.

                            Tim Cross

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]