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

[Michael Albinus]

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.

>> 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.

>> > 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.