From Damien Tardy-Panis to ~kennylevinsen/poweralertd-devel
--- contrib/systemd-user/poweralertd.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/systemd-user/poweralertd.service.in b/contrib/systemd-user/poweralertd.service.in index 475fa00..c0c6559 100644 --- a/contrib/systemd-user/poweralertd.service.in +++ b/contrib/systemd-user/poweralertd.service.in @@ -7,6 +7,7 @@ Requires=graphical-session.target [Service] Type=simple ExecStart=@bindir@/poweralertd Restart=on-failure [message trimmed]
From Damien Tardy-Panis to ~kennylevinsen/poweralertd-devel
Some devices don't have a proper separate upower type (for example headsets) and could be just defined as "battery". So it's impossible just with the ignore flag to ignore them while keeping monitoring power supply batteries. --- main.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 219c79d..a6c408d 100644 --- a/main.c +++ b/main.c @@ -144,7 +144,8 @@ static int send_warning_update(sd_bus *bus, struct upower_device *device) { static const char usage[] = "usage: %s [options]\n" [message trimmed]
From Damien Tardy-Panis to ~kennylevinsen/poweralertd-devel
--- main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/main.c b/main.c index 3dadda1..219c79d 100644 --- a/main.c +++ b/main.c @@ -237,6 +237,10 @@ next_device: for (int idx = 0; idx < state.removed_devices->length; idx++) { struct upower_device *device = state.removed_devices->items[idx]; if ((ignore_types_mask & (1 << device->type))) { continue; [message trimmed]
From Damien Tardy-Panis to ~tardypad/wee-most-discuss
Hi Per-Arne, > It seems like whenever (seemingly randomly) I try to close a DM buffer > in a buffer created by wee_most, weechat SIGSEGV. > I have describe the problem, and provided stacktrace and crash dump > file in https://github.com/weechat/scripts/issues/548 > Could you perhaps have a look at it? Thank for reaching out but unfortunately I'm not going to be able to help fix this issue. I was developing wee-most solely for my usage of Mattermost at my previous job. And my current company is using Slack instead, which means that, for now, I'm back to using wee-slack.
From Damien Tardy-Panis to ~tardypad/wee-most-discuss
> > last night, our Mattermost server was upgraded from 7.8.x to 8.1.4. > setting "Enable cross-origin requests from: *" works. I wonder what > wee_most.py does which causes CORS validation to fail. wee_most doesn't do any specific thing. I believe setting this configuration server side is actually needed for wee_most to work. Checking the changelog https://docs.mattermost.com/install/self-managed-changelog.html, I see the following text here and there. "For servers wanting to allow websockets to connect from origins other than the origin of the site URL, please set the ServiceSettings.AllowCorsFrom configuration setting."
From Damien Tardy-Panis to ~rjarry/aerc-discuss
Hi Tim, Thanks for replying. > When you say "open aerc", do you mean a currently running instance or > a whole new instance? I meant opening a whole new instance. > I don't use maildir but looking at the way the worker is set up, > it should be listing all folders and their unread counts at startup. Do you see > any errors in your logs that might be preventing this from happening? I've tested again with logging enabled but I don't see any error there.
From Damien Tardy-Panis to ~rjarry/aerc-discuss
Hi, I'm going to bump again this topic I didn't get any reply to, with hopefully a better explanation of what I see as an annoying limitation of the maildir support. My desired workflow is the following. Using a maildir account, I'm running independently of aerc some regular background syncs. Whenever my system detects a new mail from the latest sync, I want to open aerc and immediately have the new mails being displayed in the dirlist whatever the subfolder they are in. Right now, as I explained in my previous post, this isn't the case and I'm left wondering where are the new mails. I need to either go to every
From Damien Tardy-Panis to ~tardypad/wee-most-devel
> I had however patched wee_most.py to get rid of wee_most from the > channel/buffer name of every Mattermost buffer: > > wee_most.look.buffer_name_prefix: Prefix to use for all wee_most > buffer names [default: "wee_most."] > > and that makes the context binding more tricky. I guess that can be > solved by documenting the need for adding new key bindings if the > buffer_name_prefix is changed. I'll have to look at this more closely > before submitting the patch. This "wee_most" prefix to buffer names is something meant for the internal implementation, not something for the users to be aware of.
From Damien Tardy-Panis to ~tardypad/wee-most-discuss
> hi there! I'm a new user of Weechat, lured to change by the excellent > wee_most plugin :) Hi! Welcome to the power of WeeChat :) > I've sent patches for a few annoyances to the devel list Thanks a lot for your contributions. I've merged the first one and left a comment regarding the other ones. > but there is one left which I wonder if anyone has a solution for? > > after I switch to a channel, I get a read bar to indicate how far I've > read, "- - - - - - -" - but in a wee_most buffer the read bar is removed
From Damien Tardy-Panis to ~tardypad/wee-most-devel
> Without this, I had to use /debug tags to find the tag > `post_id_3y8x6qot7pn63qa4ku5p9bjj6w` and then manually > `/mattermost reply 3y8x6qot7pn63qa4ku5p9bjj6w` which was rather awkward > to say the least :) There are already some convenient helpers so that you don't have to type the post id manually. But I admit it's a bit hidden as I didn't find the time to document it more than "check running /key list cursor" You can go to the weechat cursor mode in the chat part, scroll to the line you want to reply to and then press "t" (for thread). This will directly fill your prompt with "/mattermost reply 3y8x6qot7pn63qa4ku5p9bjj6w " so that you just have to type the reply.