Corwin Brust <[email protected]> writes: > I inadvertently hit "Reply" instead of "Reply-All". My apologies > and for now top-posting.
No reason to despair, it happens to us all the time. I'll also change the ML from [email protected] to [email protected], where it belongs to. Full-quoting for the people of that ML. >> 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. That's not a problem. You will send this process call only if system-type is equal to 'windows-nt, and you will send this only once, keeping the result during the Emacs session. >> > 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. Yep. See above. >> 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. I've seen ercn in the packages list, but I don't know how much it is used. And there is also erc-nick-notify on MARMELADE, for which I haven't an opinion either. IIRC, there was a discussion some years ago to harmonize all of this, and to bring it into the GNU ELPA repository. I don't remember the result of this discussion. >> > 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? I will try to help you. However, you shall know that I don't run MS Windows myself, so I cannot tell too much about the details of your implementation. >> Also, is Eli the Emacs maintainer? I thought John Wiegly was package >> maintainer or more to do with Elpa somehow. Both John and Eli are the Emacs maintainers. >> 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. I'm contributing to Emacs 15+ years, but I could say the same :-) >> 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 my experience, D-Bus on MS Windows isn't used so much. You cannot expect it running for MS Windows users of Emacs in general. However, I would expect a general notification mechanism on MS Windows would be of use in Emacs. But Eli is definitely much better to say what's good on that platform. >> 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. If that will be widely supported on MS-Windows: yes. But still in this case, I believe that using a platform's native API, like the Windows Notification Center, might be better suited. (Saying this as the guy who wrote the D-Bus integration initially) >> 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. In general, I agree with you. But I still haven't seen much D-Bus support on MS Windows. Widespread. (To be honest, I don't see anything on MS Windows 'cos I don't use it. This is just what I understand from different mailing lists. I could be completely wrong.) >> 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. Yes. And again, if we could bring at least alert.el to GNU ELPA, this would also be a win. >> Regards warmly returned, Michael! Best regards, Michael.
