Various add-ons, including Conversations, add columns to the message list. Therefore, I think there should be an API for it.

I've started drafting one as an experiment, but I think that it would be better to be developed as a patch within Thunderbird because of the amount of integration it needs.

I've attached a possible schema for this. The basic idea is that you create a column with:

browser.messageList.addCustomColumn("my name", "my sort tooltip");

As we can't pass functions through the API, we'd need an event handler to fill in the column details:

browser.messageList.onGetColumnDetails.addListener((columnName, message) => {
  if (columnName != "my name") {
    return undefined; 
  }
  return {
    text: message.author,
    sortString: message.author,
    // Potentially other properties for display...
});

A couple of notes:

• Ideally we'd have a way to add the listener just for the column name, so we weren't notifying every extension listener for every added column. Not sure if that's possible, I haven't looked into the capabilities of the API definitions enough.
• The extension API is async, but the tree view is sync. We'll need some way of formulating the tree, and getting details from the extensions but caching them. Once we have responses, we can invalidate the tree and have it load the responses.
• Extensions should be encouraged to keep the amount of processing small so that responsiveness is fast.

I've just realised this API exists: browser.menus.create(createProperties, [callback]), so we should be able to do something like that here:

browser.messageList.addCustomColumn("my name", "my sort tooltip", (message) => {
  return {
    text: message.author,
    sortString: message.author,
    // Potentially other properties for display...
});

I very much support this. I also have various applications to add extra columns.
Like displaying whether a messages has notes attached (xnote++ does that), showing glodaid and glodadirty (glodaquilla - which is more for developers) , showing whether messages are awaiting a reply, or a follow up at a certain date.

The addon should be able to display the column without user interaction in certain contexts, but the usershould be able to deselct the column with the column selector. Like: I want to see glodaid but not glodadirty.

It would be undesirable if the end user has to explicitly enable every single column that is displayed. If he doesn't want any of them, he should deinstall - he is not obliged to keep the addon. But if it is basic functionality, the addon should be able to just display the column.

I have something that I'd call a PoC for this that roughly works. I'll try and tidy it up a bit and post it soon.

The patch I've just attached for this is a very rough, but working(ish) PoC. You can have an add-on create a column and add string values to it.

It is hidden by default at the moment - that probably needs some poking to see where values are being stored and where we can see if the add-on is being uninstalled/disabled etc.

There's a little bit of delay in adding values, but we can't do much about that - essentially we're using asynchronous functions for filling what's been designed as a synchronous object.

Also need to think about the option for the extension to trigger update of a row/column/everything, e.g. if a value has now changed.

Example of its use from the WebExtension side: https://github.com/Standard8/thunderbird-conversations/blob/95cace58e1623e8aa89c817d5d8166dae2dc7ad9/addon/uiHandler.js#L19-L43

Just to note that yesterday I updated the patch and example. There's now a topicbox thread with a proposal document for this API:

https://thunderbird.topicbox.com/groups/addons/Tf7f2d663f8314b02/proposal-custom-column-api-for-message-list

Although I'd love to get this done, realistically I'm probably not going to have the time to invest over the next few months. Part of the issue I hit which would take longer than I'd like was sorting out the caching of data so that we're not constantly hitting the WebExtension with requests for updates.

I'm quite happy for someone else to take this up if they have time, and to provide occasionally advice/help.

Checking in. Any movement on this?

fyi. We're having a discussion on this topic here:
https://github.com/lkosson/full-address-column/issues/11#issuecomment-1024954835

@Mark_Banner - I completely understand and respect your thoughtfully prioritizing your time and efforts.