I inadvertently hit "Reply" instead of "Reply-All". My apologies and for now top-posting.
On Tue, Mar 3, 2020 at 11:57 AM Corwin Brust <[email protected]> wrote: > > Greetings Michael. I really appreciate your response! > > On Tue, Mar 3, 2020 at 9:32 AM Michael Albinus <[email protected]> wrote: > > > I would love to see core Emacs (and/or a popular notifications > > > modules) support notifications for all platforms natively. To that > > > end, I'm absolutely fine with folding the 15-30 or so important sloc > > > from this solution into an existing package, or more than one of them > > > if that makes sense. That said, I'm leery of offering up brand-new > > > feature, lightly tested by the author, to a stable package a > > > potentially much larger portion of the user base depends on. > > > Especially in as much as it would bring along a system dependency in > > > the form of the Burnt-Toast PowerShell module. Maybe there's a way > > > to use the advice system to install globally but only affect Windows > > > users and implicitly take settings meant for DBUS setup? > > > > erc-desktop-notifications.el, part of the ERC subsystem, supports > > GNU/Linux notifications only if I'm not misguided. > > That's what I see from the 27.0.50 GNU binary dist. I didn't poke > around in master but that's what I expect to see there too. > > I dropped a quick note on IRC where I've chatted some with the ERC > maintainer "bandali" to feel him (and other users) out for an appetite > for putting win32 special case logic into this one. At a minimum, I > suspect we need at least one additional shell process/call for all > users of Windows native (not cyg) binaries, to automatically detect > the presence of the BurntToast PowerShell module, which my efforts so > far rely on. In theory, this could be changed to depend directly on > the Windows Community Toolkit project, but more on this presently. > > > There is alert.el on MELPA, which supports different platforms > > (including GNU/Linux via D-Bus). I believe, MS Windows/Powershell is not > > supported yet (but I'm not sure). Maybe your Powershell related code > > could be plugged in. > > This looks like the best bet. I will work on this, starting with > asking if adding special casing for Windows users is of interest and > whether this solution seems robust enough. I really don't see a way > out of opening/using a shell process to query PowerShell for > availability either of Burnt-Toast or of the UNC framework on which > /it/ depends, so I'll likely mention that potential downside. > > I'm using ercn which hasn't been updated for several years. I've no > trouble switching to setup to use alert.el; I'll do that presently. > Incidentally, and IIUC adding support for burnt-toast to ercn just > looks like publishing a new package that depends on ercn and defines > the setup more or less as I've shown in the readme for the subject > program, notwithstanding it expects the minor mode thus generated to > be called erc-notifications-mode vs erc-burnt-toast-mode as I > currently have done. > > >> There is also erc-alert.el at > > <https://github.com/jwiegley/dot-emacs/blob/master/lisp/erc-alert.el>, > > which uses alert.el for ERC notifications. Since this package is not > > available on GNU ELPA or MELPA, I don't know its status. > > > > Maybe one could try to merge all of them together, somehow. alert.el and > > erc-alert.el are written by John Wiegley, the Emacs maintainer. He will > > know much better the status and future plans. > > Since I'll be reaching out to John (probably via feature request to > the alert.el project?) I'll have a chance to ask. > > To the extend John would appreciate the support, I can also offer to > help with maintenance, especially of things I would have to take a > chance at breaking to smoothly integrate support for Windows users. > Any chance you'd want to be a phone-a-friend if John does ask for > support maintaining alert.el &ct in considering taking this feature > in/on? > > Also, is Eli the Emacs maintainer? I thought John Wiegly was package > maintainer or more to do with Elpa somehow. I'm kinda... "new" if > that isn't showing yet. I used Emacs seriously also a couple of > decades back but have only started trying to make elisp work for me > these past several months. I subscribed to several mailing lists but > I won't pretend to understand all that much of what I'm reading. > > Coming back to Windows support relying on Burnt-Toast vs building > something to use the Windows Community Toolkit (for PowerShell) > directly vs writing a custom C# assembly or otherwise messing with the > Emacs build, vs etc., and I find that this needs more thought. > > I've no trouble sharing my Burnt-Toast based solution with any package > maintainer who feels it may add value. Without question, I can > implement more of WIndows Notification Center either as exposed by > Burnt-Toast or with some custom PowerShell or C#. And, if we're > talking about C# then we can also think about bypassing the toolkit's > API and working directly with Windows. I think I can see where it > /might/ make sense to more fully implement the API from the Windows > Community Toolkit to/for Emacs, but.. maybe as a DBUS stint? > > In looking at erc-desktop-notifications.el I bumped into the core DBUS > functionality that Emacs ships with. This, it seems, is too hairy for > me. Worse, the DBUS project page claims "a port is in progress" says > little else to wit since 2018. Considering that Emacs relies already > on C code for optionally compiled in DBUS support it seems obvious > that what's /really/ wanted here is a drop in DBUS implementation > targeting native win32. > > What are your thoughts on focusing on a DBUS stint that is maybe > native windows code and has the goal of making as much existing Emacs > config as possible Just Work(sm) under Windows? Frankly, bringing > Windows to DBUSfeels better from the "Free Software" standpoint than > bringing Emacs to Windows, in that it tends to standardize Emacs as a > platform rather than potentially cave to vendor-specific features that > could create an appetite for Emacs under non-free software. (Screw > that.) I'd be open to contribute in this area too/instead if my > limited and rusty C (and C#) skills or novice Emacs Lisp knowledge or > access to proprietary personal and (maybe) enterprise operating > environments could be useful but, again and still, I'd be relying on > the community to help me find my way. > > I can reach out to John in any case since insight into plans for > alert.el (and erc-alert.el) are potentially useful in all sorts of > cases. > > > > > > Corwin > > > [email protected] > > > > Best regards, Michael. > > Regards warmly returned, Michael! > > -- > Corwin > [email protected] -- Corwin 612-217-1742 612-298-0615 (fax) 612-695-4276 (mobile) corwin.brust (skype) [email protected]
