From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Fwd: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match Date: Tue, 03 Mar 2020 20:17:42 +0100 Message-ID: <87d09t8cyx.fsf@gmx.de> Reply-To: Corwin Brust , emacs-devel@gnu.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="110055"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 03 20:20:27 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 1j9D5f-000SXD-8S for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Mar 2020 20:20:27 +0100 Original-Received: from localhost ([::1]:52242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9D5e-0001pV-4F for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Mar 2020 14:20:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55962) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9D38-00011U-HR for emacs-devel@gnu.org; Tue, 03 Mar 2020 14:17:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9D35-0000vb-SL for emacs-devel@gnu.org; Tue, 03 Mar 2020 14:17:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:38651) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j9D34-0000ue-W5 for emacs-devel@gnu.org; Tue, 03 Mar 2020 14:17:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583263064; bh=Z6afcphvGJH0KYfFlDvE4wl0imiHLYJDS4RXDcK/SWk=; h=X-UI-Sender-Class:From:To:Subject:Reply-To:Date; b=lDHIo3r8AYxmc5PcGkuD/6R0w19EPTI5cAuiMO0N3YG8KU0Zr7XanmvCXabmk8OHc kla2UfgI6++U19ifwwb856xVlDScgrBmBTKVGiE/jxw3arnnQC2HLAeusZ1mOKtDri X15gN1biSy+KCms06MCtnq7EWUG2rgyKQ+fTzymA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from detlef.gmx.de ([79.140.112.241]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N4QsY-1jXqwj3JmI-011ROp for ; Tue, 03 Mar 2020 20:17:43 +0100 X-Provags-ID: V03:K1:3/Kwo7laM7aj6gdxpW3bXZud7zhP0bRT0K+3IXauS2mZSrXj6Fy NaRAN5RwBjQOruFAYWgfoeAwbNGQ6sbgi0617p5MosO666j+o9WDd6cu/p3Ux+qBxfv6+/q HcyUG0ITFhPTzCog6RiTrnxSvgM86xizyoKbrdqI5DCCz2eFh7Y82aekbCy/ZAP8cNpccbv fsupo4E5iQBMD0dZHeyDg== X-UI-Out-Filterresults: notjunk:1;V03:K0:lJN8MxDzQlM=:JGqDjGMty3GezAg7bWWEfb 1SceDj0pI0bAvV7gMTjHjAamH87Jh2bckpBTw/YHdXb9EEq0c38KglosxZka2wfWFcx3POA/4 hP7SY2m0gFbTmVslivY2LJTtSQv1rpTZw8n5g5nJCenYvZRm0HwQbOSEpPf547KLb/a6rEjL9 hSF8DXL3UTdNvm3ML1l7yb6GZ8L//pw3HldceAxi4IlrY43qwB+42kVHPNyIlPL6J1GuMtWNa AAr1s80ZIYFhkO37XiiymmWMRFQj/xREW2Xy62uSBX8iJMk1TSFVe5n46UGGOUMHu2hlEoyci tSf2PRSGrrBUGLZYvrpGR1GTPAF+Ea7FomN3qkdQ0dYewrYP6UEpHUlcBOv2wD8PDvuJphc41 MfEWab9VdnI+Sc6FFAIiuRJcX//uVXeKgXNJpvkHEpW6CGu9p5lXJK4ACoXkQHzRIpE9evXL1 xTCUNCtHo8bqwUuaG/z2A0vrl32Aliv3gXV6LafS+NkTBnLUUJMIg2Yjmqg8E1Cd/byc/Ezee Obx+wce8SnuDCf5uS/GlKhj1RTYyd6DxAtSHae/gsGPExK1R9PPJS+ppxdNtmpZQ6ufpEgTSv tSiiCvu+JKEF8NRnHaTbignv00QnbO+1C/2JfjBxO/oR6cB25zRvSH8zlLpsitorX6Y6QIlEN rgedm9mF191+zP68lGP7+i9q2cJZxERutNBeFF8vnEK1xopVjwlPZZoxz9dAAmxc61N+vv+Ge gPG5qXrrD4qbWml60CVV7i3ANcAwWYZpCny4e9QyyTCFhQEzFjkanqdZNYeg1294+h8fk13n X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 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:245197 Archived-At: --=-=-= Content-Type: text/plain Grrr. Now I have forgotten emacs-devel in the list of addressees. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: Michael Albinus To: Corwin Brust Cc: rms@gnu.org, gnu-emacs-sources@gnu.org Reply-To: Corwin Brust , emacs-devel@gnu.org Subject: Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match Date: Tue, 03 Mar 2020 20:06:45 +0100 MIME-Version: 1.0 Content-Type: text/plain 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. >> 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. >> > 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 >> > , >> > 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. --=-=-=--