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

[Corwin Brust]

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 <address@hidden> wrote:
>
> Grrr. Now I have forgotten emacs-devel in the list of addressees.
>
>
>
>
> ---------- Forwarded message ----------
> From: Michael Albinus <address@hidden>
> To: Corwin Brust <address@hidden>
> Cc: address@hidden, address@hidden
> 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 <address@hidden> 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 address@hidden to address@hidden, 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 <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.
>
> 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
> >> > <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.

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.