That's a good idea, do you have some references I could use? I can try to look for something myself, but currently my studies take up a lot of my time, which means I will update this as soon as I find the time and motivation.
Thanks for the issue. I've added a short explanations which should give some intuition what System F is and why it is useful, as well as a link to the wikipedia page and references to the undecidability (or not) of type inference. Let me know if I could add anything else!
Thanks for your thoughts. I've detailed the reason why I find it surprising (namely naïve implementations of dependent types have undeciable type-checking).
Thanks for the clarification. I've removed mentions to System F, as the other links are already provide sufficient reasons.
Thanks, I've updated the description to mention the undecidable problem, and not an implementation issue
This would make testing and running behind proxies easier.
Makes sense. I'm playing around with prefixing the account name for that problem - both solutions would be fine with me. (Maybe even have both - a short popup telling you "problem in account xyz" and a persistent tab notification until you switch to the account?)
It's an interesting question how this plays with the composition or the msgview widget, since they are their own widget but have an associated account - I'm not sure how to handle this right now but I will play around a bit more and report back on the feel.
I've modified my fork to have one statusline per account, and it works fine. There's still some debate left about the following: Should errors be pushed to the host tab also? I think they are important enough to the user to be visible even when focusing on a different account. Then we could
PushStatusthem to the host tab to make the user aware of them and use
SetErroron the account tab for a more permanent view.