Re: erc-burnt-toast - Provide Windows Notification Center to erc with burnt-toast and erc-match

[Corwin Brust]

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 <address@hidden> wrote:
>
> Greetings Michael.  I really appreciate your response!
>
> On Tue, Mar 3, 2020 at 9:32 AM Michael Albinus <address@hidden> 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
> > > address@hidden
> >
> > Best regards, Michael.
>
> Regards warmly returned, Michael!
>
> --
> Corwin
> address@hidden



-- 
Corwin
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
corwin.brust (skype)
address@hidden