~poldi1405

Germany

https://moritz.sh

~poldi1405/comments

Last active a month ago

~poldi1405/yeet-announce

Last active 2 months ago

~poldi1405/updates

Last active 2 months ago

~poldi1405/test

Last active 3 months ago

~poldi1405/yeet-contact

Last active 3 months ago

~poldi1405/discussion

Last active 5 months ago

~poldi1405/patches

Last active 6 months ago

~poldi1405/ideas

Last active 8 months ago
View more

Recent activity

Re: [PATCH aerc 2/2] config: add bindings to trash messages a month ago

From Moritz Poldrack to ~sircmpwn/aerc

> -d = :prompt 'Really delete this message?' 'delete-message'<Enter>
I don't think changing the default behaviour of `d` would be a good
idea. To be fair I have a hard time thinking of a more intuitive
binding. Maybe add the trash-behaviour as a comment.
> +d = :trash<Enter>

Re: [PATCH aerc 1/2] commands/msg: add trash command a month ago

From Moritz Poldrack to ~sircmpwn/aerc

> + case *types.Done:
> +     aerc.PushStatus("Messages deleted.", 10*time.Second)
To me this sounds misleading. After all the whole point is not deleting
the message (right away)
> + case *types.Error:

Re: introduce the "trash" command a month ago

From Moritz Poldrack to ~sircmpwn/aerc

Right now - at least to me - it sounds like changing the default
behaviour of :move inside the message view would be the easiest
solution, but I'd prefer to see the patch first.

> You can configure :archive to stick things in the [Trash] folder, using
> `archive` in accounts.conf. It might make sense to be able to configure
> multiple archive directories, but I don't think we need a separate
> command for this.
I agree that a new command might not be needed, the functionality itself
is useful though, and one should not have to "repurpose" :archive (what
if they actually want to archive mails? :D). Supporting multiple
archives might be a larger change.

Re: introduce the "trash" command a month ago

From Moritz Poldrack to ~sircmpwn/aerc

> in my aerc tree, I have introduced a new command: :trash.
> it's somewhat similar to the :delete one, except it moves the (list of)
> email(s) under the [Trash] folder.
sooo... something like :move Trash ?

> I initially wrote a binding to do this but I didn't find a way to make
> it behave the same than the :delete command (where it moves to the next
> message afterwards).
:move Trash selects the next message afterwards

> would there be interest in providing it to aerc proper?
If it's behaviour is different from :move Trash, this might be a good
idea. But it is hard to tell without knowing the exact behaviour of your
:trash command.

Re: [PATCH] Don't propagate negative offsets when drawing a month ago

From Moritz Poldrack to ~sircmpwn/aerc

On Thu Sep 2, 2021 at 1:22 PM CEST, Daniel Patterson wrote:
> Perhaps we shouldn't be panicking here at all? If we returned an error
> here and forced the caller to handle that 
The best way to handle errors, is to handle them gracefully IMO. Since
the size is outside of the scope of aerc, so aerc should do the next
reasonable thing: nothing.

We could try to show an error, but what would this mean to the user? (If
they can at all read it) Close to nothing, if the user doesn't ignore
the error outright.

> then we could probably avoid a lot of these hard to reproduce panics.
Panics are there for a reason, so getting rid of panic doesn't really
help here if we don't adress the underlying reason.

Re: [PATCH] Don't propagate negative offsets when drawing a month ago

From Moritz Poldrack to ~sircmpwn/aerc

> I'll also note that this doesn't appear to happen in GNOME terminal,
> though I don't know if that information is terribly interesting here or
> not.

Then that might be a reason for me not being able to reproduce it. I am
using KiTTY and neither opening tabs, nor splitting the window caused a
panic for me. Regarding whether this is the best way, I would actually
say it is the best fix we currently have. I am still going through the
codebase, and understanding the inner workings.

I think having an unresponsive grid while some invalid values are given
is preferable over a panic.

One Proposed change would be to add this check with the similar guard in

Re: [PATCH] lib/ui/textinput: Optimize ensureScroll a month ago

From Moritz Poldrack to ~sircmpwn/aerc

You are correct, it was.

Re: [PATCH 2/2] detect loopback by ip address not by string representation of server name a month ago

From Moritz Poldrack to ~sircmpwn/aerc

> i hope to learn fast how to contribute here. thanks for your time.

No worries and thanks for the contribution. The extra DNS Lookup did not
lead to a noticeable overhead and the benefit for the users that
actually have this issue exists. I think it should be merged as it does
not impact "normal" use of aerc and provides a solution to this problem.

Re: [PATCH 2/2] detect loopback by ip address not by string representation of server name a month ago

From Moritz Poldrack to ~sircmpwn/aerc

I'd recommend the following approach:

- do a `git rebase -i` and squash the commits
- submit a v2 by using `git send-email --annotate -v2 HEAD^`

I am sorry if this seems excessive, but it would be best if we do not
include temporary work in the history and just combine the correction
with the original – imperfect – solution.

Re: [PATCH] do not check for STARTTLS support for localhost a month ago

From Moritz Poldrack to ~sircmpwn/aerc

Please refer to this tutorial on how to properly submit patches:
https://git-send-email.io/#step-4