> and in recent weeks it has started to dominate the Twitter discourse.

As a general rule, I don't waste my time with the advice of people who still think Twitter is a source of wisdom.

This is not consistent with current Fair Use application. The TL;DR is that the use must be for a new expression that is protected by either the 1st amendment or copyright itself. I don't know of a single case where it has applied to mere distribution. I would be astounded if there is such a case because that isn't within the expressed purpose of the doctrine.

This seems akin to complaining that the CPU core has only one instruction pointer. There is nothing preventing a struct implementing `Error` from aggregating other errors (such as validation results) and still exposing them via the `Error` trait. The fact of the matter is that the call stack is linear, so the interior node in the tree the author wants still needs to provide the aggregate error reporting that reflects the call stack that was lost with the various returns. Nothing about that error type implementing `Error` prevents it from also implementing another error reporting trait that reflects the aggregate errors in all of the underlying richness with which they were collected.

https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...

He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:

https://news.ycombinator.com/item?id=7279358

In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.

    $ du -s -h .vim
    22M .vim

Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).

My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).

    Vim9 script and legacy Vim script can be mixed.  There is no requirement to
    rewrite old scripts, they keep working as before.  You may want to use a few
    :def functions for code that needs to be fast.

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*

    Bram,
    I happy to see there is still some hope for this patch getting merged.

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.