#228 improve review screen 16 days ago

Ticket created by ~balejk on ~rjarry/aerc

The review screen which is displayed after a message is composed contains a lot of empty space and in my opinion unnecessarily uses up space for displaying key bindings, which is something that is not present anywhere else in aerc plus it duplicates the functionality of :help keys.

This empty space plus the space created by the removal of the key hints could instead be used to actually present the message for a proper review in a similar manner that the :preview command invokable from the review screen does.

Where there are now key hints and the empty space of the usually short attachment list, there could instead be an open pager displaying the actual message in the same way that it would be after :preview is invoked. This would make it possible to immediately see the message in full as the recipient will see it (modulo their email client) without the ability to alter it by accident (such as pressing a wrong key in the editor and then saving without noticing). List of attachments would also look the same as for :preview and switching between them would be possible which would also allow for their inspection. In addition, this change would allow for a full inspection of all message headers. At the same time, all operations which are now valid for the compose::review screen would be valid here.

Effectively, this would remove the middle step of dropping to the review screen after editor is closed and invoking :preview (plus the steps of closing the preview and going back to the review screen to send the message).

Several points have been brought up in the discussion. This "improved" review screen should be clearly discernible from a received message viewer. The screen could perhaps include some header or the tab title could indicate that it is a composed message.

A way to simulate this behaviour has also been suggested: a hook could be added which would trigger when the editor exits. The user could use this hook to automatically invoke :preview. For this to fully encompass all of the above it would also have to be ensured that the :send command and others can be invoked on a :previewed message, which is currently not the case.

It has also been mentioned that the attachments list could be displayed while composing below the editor similarly as it is shown below the pager in message viewer. Message editing could then be fully performed from the compose::editor screen including attachments and in addition to the above described changes to the review screen, a configuration option could be added to have the message sent immediately upon successful editor exit (review = true|false).

The original discussion can be found here [1]. Note that the original formulation is rather confusing and does not describe exactly the same behaviour as is described here.

[1] https://lists.sr.ht/~rjarry/aerc-discuss/%3CCYM1H3H7U1OA.78VQA3CI0BQQ%40matfyz.cz%3E

#223 style is not correctly layered 20 days ago

Ticket created by ~balejk on ~rjarry/aerc

Having a custom styleset with


and setting

tab-title-account={{.Style .Account "bold"}}

in aerc.conf does not reverse colors for the text when the tab is deselected (it does reverse colors for the tab's padding (spaces around the text) though).

A current workaround for this problem is the following patch (courtesy of Robin):

diff --git a/lib/ui/context.go b/lib/ui/context.go
index 9ca7cc9d56c0..5ab326eddaf8 100644
--- a/lib/ui/context.go
+++ b/lib/ui/context.go
@@ -77,6 +77,7 @@ func (ctx *Context) Printf(x, y int, style tcell.Style,
        buf := parse.ParseANSI(str)
+       buf.ApplyAttrs(style)
        old_x := x

#222 inherit default styles for the [viewer] section too 20 days ago

Ticket created by ~balejk on ~rjarry/aerc

Recently, a change was introduced which allows a custom styleset to only contain deviations from the built-in defaults, leading for instance to an empty default styleset. This is however not the case for the [viewer] section containing colorize filter styles. It might be nice to have this inheritance apply there too.

#221 actions are performed with respect to the selected message rather than the open one 21 days ago

Comment by ~balejk on ~rjarry/aerc

It seems that the first problem (with :reply -c) also works cross-account: so the bold part of point 3. shouldn't be there.

#221 actions are performed with respect to the selected message rather than the open one 21 days ago

Ticket created by ~balejk on ~rjarry/aerc

At least two operations which one would expect to be performed with an open message are instead performed with the one focused in the message list.

#reply -c

  1. Open a message.
  2. Issue :reply -c on the open message.
  3. Switch back to the message list of the same account.
  4. Focus a different message.
  5. Return to the reply composer and abort.
  6. The newly focused message is re-opened instead of the one we were replying to.


  1. Open a message.
  2. Switch back to the message list of the same account.
  3. Focus a different message.
  4. Return to the open message tab.
  5. Issue :next-message or :prev-message.
  6. Next/previous message is opened with respect to the newly focused one instead of the open one.

#112 task view a month ago

Comment by ~balejk on ~rjarry/aerc

Thank you for the tips! In particular, the library does indeed seem to handle many of the presented ideas.

#112 task view a month ago

Comment by ~balejk on ~rjarry/aerc

Maybe there could even be some task hiearchy, such as if the workers run several subtasks at once, but it shouldn't get too complicated.

Also, I forgot to mention (although it's in the original post) that the tasks should also ideally be stoppable, although that would probably require some cooperation from the tasks as I don't think it's quite possible to just stop a goroutine. But that would not be a good idea anyway, usually some clean up would be necessary, so the tasks would probably have to listen on a channel for a signal to exit prematurely. As such, there would probably be just a few exit points where the task would check if abort was requested and it would probably not be possible to force the task to exit in an arbitrary moment.

#216 `reply -c` locks up on editor failure a month ago

Ticket created by ~balejk on ~rjarry/aerc

Executing :reply -c on an open message and making the editor fail (:cq with vim) re-opens the viewer tab and removes the editor, but leaves the compose tab open and focused and seemingly causes a lock up -- it is not possible to switch tabs or anything else and aerc has to be killed.

Re-opening works as expected when composition of the reply is just :aborted.

#112 task view a month ago

Comment by ~balejk on ~rjarry/aerc

Some further ideas:

I'm thinking that perhaps a new TaskManager could be introduced which would keep track of relevant background tasks. Instead of backgrounding tasks manually using go func(), one would instead call TaskManager.New(func, chan) which would run func in goroutine and use chan to receive status messages messages from it, which would then be accessible to the user in the task view. I imagine the latest message would be displayed at the given task in the task view plus it could be forwarded to the status line (app.PushStatus/Error) for some duration.

If the task failed the user could try to run it again through the task view and perhaps there could even be some more parameters (like a map mapping an action description (string) to the function which would be invoked -- this could be different for while the task is still runnning and while it has already exited) to TaskManager.New which would allow the user to take more actions on a task, both while it is in progress and when it fails.

I think this could make sense for many things in aerc, although of course not everything that gets background deserves to be called "a task" and get its own slot in the task view -- or does it? I can for example imagine that the actions of workers could be shown there, perhaps it could be made possible to pause polling an IMAP/JMAP server for new emails through it.

However, what originally gave me this idea was sending of messages: right now when I send a message, the "Sending" status is displayed, however one of my servers gives me a "logged out" error every 30 seconds which overwrites the status and if I look away, I cannot discern if it is still sending or not, until the "Message sent" status appears (one way would be to try to exit aerc). And if it does not appear, it is not clear whether the message is still pending or whether the status has already appeared and has been overwritten by the server error. Of course, it usually does not take too long before the sending failure is indicated by the composer being reopened and, conversely, the presence of the message in the sent folder can be taken as indication that sending was successful, but it is really not clear for bouncing (which is currently being implemented) for instance.

I imagine that in this case (sending), the task would be backgrounded and the user could see the task view to find out the status. The status messages which are now shown in the status bar would stay the same except they would be sent there by the TaskManager which would also display the latest message in the appropriate task slot in the task view. If there was an error, the auxilary actions permitted to the user here could be either to attempt to resend or to reopen the composer, which would no longer happen automatically. Or perhaps even copy the message to drafts. Similarly for bouncing: if it failed, the user would know even if he walked away from the computer for those 10 seconds when the relevant error was displayed, plus he could rerun the function with the same arguments to attempt again, instead of having to invoke :bounce again manually (although that would probably not be too much work as the precise command line would be saved in his command history).

So to sum up, I think the main advantages of this feature would be the ability to clearly discern which status message was produced by what task and to explicitly check the status of a task even after the usual duration for which the status message is shown in the status bar has elapsed. Plus it would give more options and a common interface for influencing things running in the background, both before and after they have finished (successfully or not).

The notion of TaskManager sounds like something that could already exist so it might be a good idea to check whether part of the implementation of this could be delegated to some library.

Also, the task view could store all the status messages produced by a task, just as they are now logged, so the user could view the whole progress with timestamps even. Also, not all messages would have to be forwarded to the status bar -- perhaps some integration with log could even be implemented as it seems there are some shared traits.

I don't know if people usually run aerc for longer periods of time, if so, it could be made possible to remove finished/failed task from the view (and thus the manager) manually or to limit their amount/age.

#210 flag gets added on keybind press a month ago

Comment by ~balejk on ~rjarry/aerc

eliminate line 290 and expect the user the explictely ask for in the keybinds if you want the completions menu to pop up automatically.

Without any deeper insight, this sounds very sensible to me.