From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match Date: Tue, 3 Mar 2020 15:52:48 -0600 Message-ID: References: <87d09t8cyx.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="105362"; mail-complaints-to="usenet@ciao.gmane.io" To: Corwin Brust , Emacs developers , mab@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 03 22:53:48 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j9FU4-000RIi-GI for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Mar 2020 22:53:48 +0100 Original-Received: from localhost ([::1]:54086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9FU3-0003mg-H6 for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Mar 2020 16:53:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41230) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9FTN-0003Gg-Td for emacs-devel@gnu.org; Tue, 03 Mar 2020 16:53:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9FTK-0006Bn-Eq for emacs-devel@gnu.org; Tue, 03 Mar 2020 16:53:05 -0500 Original-Received: from mail-ed1-f68.google.com ([209.85.208.68]:36481) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j9FTJ-00069r-Du; Tue, 03 Mar 2020 16:53:01 -0500 Original-Received: by mail-ed1-f68.google.com with SMTP id a13so6391757edh.3; Tue, 03 Mar 2020 13:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/b/e4uXUJnk6/JUaljH1hNcm6BViDlIdyyJlC7oPRP4=; b=LWURwmFBj0Wv4FtljpbIDhT1rR0n1LQ7hFC7o0MJAN7VWrFbWCl01FlWtup1yKr4Gg iGezrjm210OCRIZ1rPiRCC1MiJaeOqxqDCDDbhnf9gJuQnu1scr8OuUCg0XeZRq7wyXv bCm4mDSs5UGJWgBB6p+ZLQ8OlyWHVvPt5JTDS+puopzE2w4i0Enji0yjFd+000Drc2aR //sfuj3y14lC5PR8cRSPDTUKaypSwjTh2CqyCdhdGBW48uCu95dy/uN/RSmOIsnvmcs/ xLBbsZ3glQcr5HT++gP1OU7v5981eGVj73KISyukKaozRloTeAE625nMU3zcuOaLVxxG hvOQ== X-Gm-Message-State: ANhLgQ0r81YkTNs6FDRCY8ckMMnzsNmpmc5G60IlTB9E4EhwanOWPGr7 ym9UMCWJd/pgBwBzif7mUNBxZ2EQWRT9BYwje8I= X-Google-Smtp-Source: ADFU+vuUF0zXXajITk5DVhJsfJ/2EVD6SGkv0aApRJVBdkfpnnMPhGlP14aOzxnpuBmJghRItFb+2YsTeQCTPO8bTME= X-Received: by 2002:aa7:d305:: with SMTP id p5mr5999475edq.222.1583272379983; Tue, 03 Mar 2020 13:52:59 -0800 (PST) In-Reply-To: <87d09t8cyx.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.208.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245201 Archived-At: I'm sick in bed today and writing from my phone. What's your excuse? ;) I'm very pleased to meet you, Michael. Thanks for another thoughtful reply. [In fact, I came to the desk to spellcheck on the desktop so I'm officially out of bed. I guess I have to check work email now?] On Tue, Mar 3, 2020, 13:19 Michael Albinus wrote: > > Grrr. Now I have forgotten emacs-devel in the list of addressees. > > > > > ---------- Forwarded message ---------- > From: Michael Albinus > To: Corwin Brust > Cc: rms@gnu.org, gnu-emacs-sources@gnu.org > Bcc: > Date: Tue, 03 Mar 2020 20:06:45 +0100 > Subject: Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match > Corwin Brust 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 gnu-emacs-sources@gnu.org to emacs-devel@gnu.org, where it > belongs to. > > Full-quoting for the people of that ML. Thanks. Here I'll do my best to confine to a subject per message. First, or at any rate here, I'd like to keep ferreting out the ideal scope. Always assuming neither pick up the thread, so to speak, from this list. I'll copy in Eli directly in a bit to request papers and clarify my situation as regards, and I propose we can also copy John explicitly just prior to opening an issue to/PR for alert.el and given we don't talk ourselves out of that somehow. > >> On Tue, Mar 3, 2020 at 9:32 AM Michael Albinus 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. Can do. > >> > 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. Okay. I agree this may be pretty easy -always assuming the general approach is on the road to robust- to support windows notification center fairly implicitly for alert.el users. This assumes, as I currently have done in erc-burnt-toast.el, that windows users can -and have- successfully navigated installing the PowerShell dependency from which I took the name: Burnt-Toast by Joshua King (MIT) - https://github.com/Windos/BurntToast But let's come back to this point in the context the onus alternatives place upon the user vs and considering the potential complicity each may introduce to the Emacs universe. Note, however, I can't currently build on Windows and have been working at it a week or two I'm tending to assume complicating all that takes some work in justifying and that. My point here is that I'm not brushing off.. call it: "Option 1: offer patches for alert.el, and maybe erc-alert.el, and maybe merge them". And I assume we may end up with several answers worthy of some further testing/analysis. > >> 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. This too looks easy to patch for use burnt-toast if under native Windows, module present, etc. and so on. I can even maybe work on this first? I will email Andy and see of he would like to see agree an extra conditional in the else block that reuses his vars to make a PowerShell command when it would work. I can also too what he thinks should happen for windows users who don't have Burnt-Toast. > > 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. I feel that. I think this relates to my fixation with doing a DBUS stint - core feels like it is (becoming) fairly centralized on DBUS and I think our goal is bringing capability symmetry to Emacs for multi-platform and windows only users. Well, config symmetry would also be good. But... > > >> > There is also erc-alert.el at > >> > , > >> > 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. As you point out there is little likelihood we will implement enough of DBUS to create excitement among windows users inspire it's popularity for use outside Emacs. Moreover, I think neither of us is motivated to do anything like a proper DBUS implementation that lives outside Emacs. I wasn't really thinking about trying to do that, although it would be cool to help that effort along somehow. > > 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. But instead this, exactly. > > >> 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) Well. So, obviously, this does sway me, if I wasn't. Let's don't implement DBUS for windows. I hear it wouldn't be fun or well used. Would it make sense to create am elisp package that installs advice on the functions that (for most users) invoke DBUS? It seems like, especially, this could be the easiest way to get windows notification center support into core quickly. This, I suspect I wasn't explaining well, is what I was thinking of a a "stint" (Emacs Lisp-based) - something that advises dbus.el, allowing it to load but supporting only a very limited call set and, of course, invoking (directly or indirectly) Windows Community Frame/PowerShell instead of calling into busbind.c. Or maybe... but nevermind that for now. For ERC users this could make existing tooling (al la erc-desktop-notifications.el) work changed, leaving aside installation of the module etc. to a little further down-message. I'm not sure how important that is vs adding support. I suspect a patch to erc-desktop-notifications.el that helps Windows users would be welcome. ++bandali [who just confirmed openness to this on IRC but stays tagged anyway ;] Let's call this "Option 2. Advise dbus.el" > > >> 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. So this is where we are, I think. Two clear options (which aren't really exclusive), some potential for radically different approaches (like targeting compiling Emacs with support for the Windows Community Toolkit, when available), and a couple of interwoven dirwctional points to consider: 1. Should we try to create some tooling to help install Burnt-Toast and instruct configuring it and Microsoft People and Task Bar? This is a bit of a pain. I predict issues/frustration e.g. due to not getting a GUID assigned to Burnt-Toast, permissions, and other things I currently take no care to detect. 2. And apropos, this solution isn't very robust yet, I think. I'd be grateful for pointers expressing that more specifically and perhaps suggesting some directions to poke in. Capturing command failure and sharing the message would be a favorite, I'm sure. Most appropriate way of doing this, however, is cloudy. Just `message' and forget? Is is there a good recipe for balance between sloc and error trapping (or test, ahem *blush*) code? 3. Finally, and still pretty interrelated, I think: how do we make and evaluate our case for a change in core? To open up the Windows Notification Center for alerts overall, firstly, but then also to understand what level of utility should drive, e.g. looking into compiling against the Windows Community Toolkit and (let's say) advising dbus.el where needed? My thinking is that by driving the feature back to core (with minimal impact thereto) we serve the most people, and probably the most quickly. If that both a correct assessment and feasible to devise, that's the solution I guess we should work *mostly* on. There could be advantages for users in looking all the way down the rabbit hole to a custom integration between Emacs and Windows for supporting Notification Center. This would look rather like the DBUS wrapper in C for GNU/Linus, Mac, and Cygwin but wrapping (probably) the Windows Community Toolkit. This would definitely allow us to properly associate Emacs as the originating process and probably opens the door to let users create/manage GUIDs on the fly, which can to differentiate toasts as from different logical processes within Emacs and/or different users of Emacs. As background here, Burnt-Toast creates a GUID universal for "toasts" it creates. This GUID is a requirement for the underlying Windows Community Framework methods and, IIUC, overall Windows facilities exposed for Notification Center (and Microsoft People?) interaction. In fact, those toast really belong to Emacs and it might make sense to look into Emacs' own procedures for having a GUID and thus into the Emacs GUID instead of our own. I suspect a custom native wrapper is the only route to seeing "Emacs" instead of e.g., the attached image in the Notification Center preferences panel. I would like to see Emacs in this panel. I would not like to cause Emacs to require a working C# compiler (if it doesn't already, and I think maybe it doesn't) to create a Windows native build. Perhaps a glue-lib could be maintained outside of core and an optional dependency added thereto? Emacs can quite likely get a binary this way, and would have sources for the win32 source depts tarball, but would GNU maintainers end up needing to compile themselves vs using a provided binary version? Is/would that be a problem? I'm pretty sure we should still build up patches starting with alert.el and erc-nick-notify (which I found on EmacsWiki) and erc-desktop-notifications.el is the right next move, while we discuss. It's useful to start refactoring erc-burnt-toast into tidbits for inclusion and understanding how different variables and helpers are between packages. I will plan to track stuff that somewhat closely. > > >> Regards warmly returned, Michael! > > Best regards, Michael.