On Thu Sep 15, 2022 at 14:00 CET, Robin Jarry wrote:
> Bence Ferdinandy, Sep 15, 2022 at 13:38:
> > Hi,
> >
> > so I started to write a list of things I was missing from aerc. The way things
> > got on the list wasn't after careful thinking, just as they came up during
> > usage, so they're of varying quality and importance, but since many of them
> > found their way onto the mailing list as well I thought I'd share (as you can
> > see I also use this list to track the relevant discussion for myself):
> >
> > https://github.com/ferdinandyb/dotfiles/blob/master/.config/aerc/aerc_wishlist.md
>
> Hey Bence,
>

On Thu Aug 18, 2022 at 17:42 CET, Ben Cohen wrote:
> This patch reuses the next-message-on-delete configuration flag to
> mirror the behavior when archiving.
>
> Signed-off-by: Ben Cohen <ben@bencohen.net>
> ---
> v1->v2:
>
> * Fixed commit and patch format
>
> commands/msg/archive.go | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/commands/msg/archive.go b/commands/msg/archive.go

hi there,

in other email readers applications, it's possible to have conversations
being displayed in threads (we now have that feature in aerc), but also
as (re)grouped "flat" entries.
ie: instead of using vertical estate for all the threading (as is now
the case in aerc), you just have 1 entry (ie: 1 row) for the whole stack
of email conversations, with some hint that it's a group of emails
beneath (ie: usually with a (counter) being displayed somewhere).

would that be something worth considering implementing ?

cheers,
-s

"This is not the Gio you are looking for".

(This is a mailing list dedicated to a Go-based graphical UI toolkit)

Cheers,
-s

Jul 18, 2022 23:07:31 John Klug <John.Klug@multitech.com>:

> I called:
>   g_dbus_connection_call_sync()
> 
> Doing a BlueZ connect.
> 

Robin,

On Thu Jul 14, 2022 at 23:25 CET, Robin Jarry wrote:
> Sebastien Binet, Jul 13, 2022 at 09:42:
> > is this behaviour the expected one?
> > I'd venture a "better" one (at least the one I was used to), would be to
> > point at the "new" "last" message, according to my sort criterion.
>
> Hi,
>
> I don't believe this is intended. I have noticed a few "message
> selection after delete" weirdness lately. It may be due to one of my
> recent patches[1].
>

hi there,

I am using 12dec19 (ie: v0.11.0) but the behaviour I'll describe
shortly appeared a couple of days before.

I am using:

```
[ui]
sort="date"
next-message-on-delete=true
```

when I delete the last message, be it from the main window or when

On Fri Jul 8, 2022 at 13:25 CET, Egon Elbre wrote:
> One way to add predictive loading to that async loader example is to
> use `List.Position.First` and `List.Position.First + .Count` then
> trigger loading to items that are beyond those.
>
> > throttling the actual loading of the resource (and only load resources that are "about to be in the viewport")
>
> I'm not quite sure, whether I understand you correctly, but currently
> the async loading is only triggered for things that are rendered.
>
> However, you trigger loading, either through `widget.List` or by other
> means, you could hit a scenario where you initially use a zero size
> widget, which would mean all items are visible... which would trigger
> loading all the items.

On Wed Jul 6, 2022 at 10:29 CET, Egon Elbre wrote:
> For async loading take a look at
> https://github.com/egonelbre/expgio/tree/master/async-loading

thanks Egon.

I tried a bit gioverse/chat/list.Manager but it doesn't compose well
with FlowWrap (wrapping it with a "fake" 1-item material.List doesn't
trigger the "update" event of the list.Manager, and it's left capped at
the list.Manager maxSize).

I also tried async-loading.
it composes well with FlowWrap. but for my use case, I'll need to add:
- throttling the actual loading of the resource (and only load resources

Tim,

On Thu Jul 7, 2022 at 16:52 CET, Tim Culverhouse wrote:
> On Thu Jul 7, 2022 at 9:26 AM CDT, Sebastien Binet wrote:
> > I tried a couple of times with a couple of email addresses I had
> > control of: the same misbehaviour showed up.
> >
>
> Hi Sebastien -
>
> I can replicate this. Can you submit a bug report?
> https://todo.sr.ht/~rjarry/aerc

done:

hi there,

I am using aerc@4240f1f.

I don't know since when this is the case, but:
- I received an email with a bunch of CCed addresses
- I replied-all (':reply -aq') and removed all the CCed addresses
  from the ad hoc fields with my $EDITOR (nvim)
- I hit "send".

I have a rule to also send a Bcc to myself.
and when I received it, I noticed that aerc kept *the whole set of
originally CCed addresses.*
(eventhough they didn't show up in the "send this email" dialog.