On Mon Jan 6, 2025 at 3:21 PM CST, Silvan Jegen wrote:
> Thanks for your input! I am learning a lot about the JMAP protocol,
> which was one of my motivations to look at the code :)

I went ahead and applied this patch as is. I think the larger picture about the
API usage is still a question, but that isn't a reason to hold up this one :)

Thanks!

-- 
Tim

> Silvan Jegen <s.jegen@gmail.com> wrote:
> AFAICT the locking dance we have to do in the client is only necessary
> because we allow Authenticate to be called in so many places.
>
> I wonder if it wouldn't be better to just introduce a `NewClient()
> (*Client, error)` function that returns an authenticated client with a
> valid session (or an error).

In JMAP, each request returns the state string of the session object. I've found
it to be pretty good practice to check that on every request against the session
object you have, and if it's different, request a new session object. In this
case, that would be to call Authenticate.

If we remove that method, the only means is to then create a *new* client. This

> If we don't do this, there might be concurrent access if multiple "Do()"s
> are executed at the same time without having called "Authenticate()"
> before.
> ---

Thanks for the patches! I've applied both.

-- 
Tim Culverhouse

> Is it possible to add inline images instead of attaching them when composing a new mail ?

Not currently. To do inline images, you need to attach an image with a
disposition of "inline" and a Content-ID header. It also can *not* have a
filename. This is currently not possible in aerc.

From there, you'd have to create a text/html part which references the attached
image by it's Content-ID value (<img src="cid:<value>">). This level of HTML
email crafting is seems too far outside the scope of aerc.

-- 
Tim

> tbh, probably calling :open on the file and actually watching in mpv makes more sense here.

I agree. Thinh and I chatted on discord earlier and couldn't quite get this to
work...It "worked" in a plain vaxis terminal but not within aerc, I'm not sure
why.

Either way, the performance is going to be pretty abysmal with all the layers
going on here. I doubt you'd be able to maintain even 30fps.

-- 
Tim

Update vaxis to latest tagged release. Includes a few fixes related to
OSC 11 requests and responses that will help aerc work with the chawan
terminal web browser, as well as integrate with $EDITORs better.

Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
---
 go.mod | 2 +-
 go.sum | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/go.mod b/go.mod
index 9f82c8e37381..67891d338620 100644
--- a/go.mod
+++ b/go.mod
[message trimmed]

Hugo Osvaldo Barrera <hugo@whynothugo.nl> wrote:
> It's a basic internally-scrollable list.
> ---
> v2: suggestions from v1

Applied, thanks.

To 
   e2b805b0e8d4..5faebf643093  main -> main

On Wed Dec 18, 2024 at 12:21 PM CST, Hugo Osvaldo Barrera wrote:
> It's a basic internally-scrollable list.
> ---

Thanks for the patch! Just a couple of comments below.

> diff --git a/widgets/list/list.go b/widgets/list/list.go
> new file mode 100644
> index 0000000..95be93e
> --- /dev/null
> +++ b/widgets/list/list.go
> @@ -0,0 +1,92 @@
> +package list
> +

On Mon Dec 16, 2024 at 9:08 AM CST, Robin Jarry wrote:
> Depending on the backend which is sending the email, the Bcc headers
> will or will not be stripped implicitly. Make sure to remove them before
> writing the message.
>
> Fixes: https://todo.sr.ht/~rjarry/aerc/283
> Changelog-fixed: Some SMTP servers do not strip `Bcc` headers. They
>  are now stripped by aerc from the outgoing messages to ensure they
>  are not leaked to all recipients.
> Signed-off-by: Robin Jarry <robin@jarry.cc>
> ---

Reviewed-by: Tim Culverhouse <tim@timculverhouse.com>

On Mon Nov 25, 2024 at 5:47 PM CST, Kristófer R wrote:
> Follow-up to my previous patch; this fixes an issue where the mouse_leave
> event was never sent because maybe_last_handler was only set when there
> was already a maybe_last_handler widget set.
>
> The change here makes it so that every time an event is consumed libvaxis
> keeps track of which widget did that through the maybe_last_handler
> variable.
>
> In other words: we update maybe_last_handler every time an event is
> explcitly consumed.
> ---

Applied on main, thanks!