~balejk


#138 Highlight terminal tabs if the underlying process prints bell 20 days ago

Comment by ~balejk on ~rjarry/aerc

Maybe this could be done by adding TabTitleTerm setting which would make it possible to do something like

tab-title-term={{if .Bell}}{{.Style .Title "bold"}}{{else}}{{.Title}}{{end}}

where .Title would return what the tab displays now and .Bell would be a flag indicating whether the process has rung the bell and would get cleared upon the tab being focused?

As for what ~tkna asks: I believe you can already do this. Take a look at tab-title-account. For instance I have

[ui]
tab-title-account={{.Account}}{{if .Recent "INBOX"}} ({{.Recent "INBOX"}}){{end}}

in my aerc config. You can also make the title bold, but it's currently slightly broken, see #223. Also the Recent status may not clear for you as you would expect, see the first comment at #242.

#249 new message bell not working 23 days ago

Comment by ~balejk on ~rjarry/aerc

The fix for the Vaxis breakage is up :-)

It seems that what broke the message bell in the first place is 24eab0f5ef63 which was meant to make the mail-received hook fire even when the tab is not focused.

I have compiled the revision prior to this commit and there the bell works even if the tab hasn't been opened previously (since the start of aerc). Whereas, as previously noted, on current master I only get the mail-received hook after I focus the corresponding account tab (and for instance for o365 not even then). So in other words the aforementioned commit doesn't fix the issue it was meant to solve for me.

I haven't yet looked into how exactly that commit broke the bell but I wonder if instead of moving the bell into the triggerNewEmail callback we could move the mail-received hook into the triggerDirectoryChange callback (after it's fixed) as that seems to be executed not only when the tab is not currently focused (even for me :-) ), but also even if the tab hasn't been focused yet since the start of aerc, which is listed as one of the limitations of the fix commit. (And when I say move into the other callback, I mean rather try to understand how the two triggers differ and see if they could be made into one which would keep the benefits of both and none of the problems of either :-) )

#249 new message bell not working 26 days ago

Comment by ~balejk on ~rjarry/aerc

There is no patch, I am just guessing based on what I write above but haven't looked whether in fact and what has been dropped. I can look into it later but feel free to beat me to it :-)

#249 new message bell not working 26 days ago

Comment by ~balejk on ~rjarry/aerc

Thank you for looking into this!

Sorry for the confusion: it seems that you are right, aerc probably no longer satisfies the interface - I assume this is related to the Vaxis switchover then?

To be more precise: I tested this again with 0.17.0 and there I get the bell on startup and I see no beeper warnings in the log. New messages still don't beep though.

With latest master, I don't get the startup bell and I see several beeper warnings in the log -- I assume these are the startup ones.

And I have now verified that moving the beeping into the NewEmail trigger on top of 0.17.0 causes new messages to beep, but again only after the receiving account's tab is opened -- this is a general problem of the trigger it seems.

#249 new message bell not working 26 days ago

Ticket created by ~balejk on ~rjarry/aerc

The terminal bell isn't rung when my IMAP account receives a new message. Tested with as-of-now-latest master (7b4c8f67eb5f).

What seems a little strange to me is that the Beep() call is in the triggerDirectoryChange callback of MessageStore rather then triggerNewEmail. However moving it there only produces

aerc.go:153: should beep, but no beeper

warning in the log. This is as far as I can guess because the UI context of the trigger is not DrawableInteractiveBeeper.

It's been suggested that the issue could be caused by the IMAP server not supporting the \Recent flag, however this should not be the case as evidenced by the above warning and also by the fact that the mail-received hook, which I have been lead to believe uses this mechanism too, works for this account (albeit it is only fired once the tab of the receiving account is opened).

I have {{.Recent}} in the tab title and that changes correctly even before the tab is opened. But so it does for another IMAP account where the hook does not work at all and I have been told (on IRC) that this variable is in fact possibly not related to the \Recent flag.

Also, the bell is rung soon after aerc starts up when placed in the triggerDirectoryChange callback which I guess happens as all my mailboxes are being opened.

#242 Recent status cleared on aerc startup for IMAP 26 days ago

Comment by ~balejk on ~rjarry/aerc

Conversely, although it's probably not related directly, the status isn't cleared when the new messages are read (or marked as read) and one has to change folder (another folder of the same account, not just different account/tab) to clear it. ~inwit reports to be seeing the same thing for {{.Unread}} (if I understood and remember correctly) -- I only have the unread count displayed in the folder list (so the defaults), rather than the tab title, and there it changes immediately and correctly for me when I read or unread a message.

#15 support querying the embedded terminal colors a month ago

Ticket created by ~balejk on ~rockorager/vaxis

Currently, when neovim is run in the embedded terminal with the default colorscheme, it cannot detect the background color because Vaxis does not support the corresponding OSC sequences. This leads to neovim defaulting to dark and this has to be set manually if the background is in fact light.

This is relevant for instance for aerc, which itself has a light background compliant colorscheme, but the editor opened when composing a message cannot adapt automatically.

Incidentally, neovim's built-in terminal did not support this either until quite recently. Here is the relevant pull request adding the support.

#242 Recent status cleared on aerc startup for IMAP a month ago

Ticket created by ~balejk on ~rjarry/aerc

To reproduce:

  1. Exit aerc if running.
  2. Indicate the Recent message count in tab title, such as
tab-title-account={{.Account}}{{if .Recent}} ({{.Recent}}){{end}}
  1. Send yourself a message without opening the mailbox (via sendmail or similar) and give it enough time to arrive.
  2. Open aerc and watch the tab title. The correct Recent count appears there for a split second and then disappears as the mailbox loads.

#228 improve review screen 3 months 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 3 months ago

Ticket created by ~balejk on ~rjarry/aerc

Having a custom styleset with

[user]
bold.bold=true

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.ApplyStyle(style)
+       buf.ApplyAttrs(style)
 
        old_x := x