artemave's comments

I came here through @Hn251 on Twitter

I use tmux to organize terminal windows in a project. One of those windows is running vim, where the coding happens. A big chunk of my time is spent writing, running and fixing tests. And so I keep switching back and forth between vim and shell windows. It goes like this: I choose a single test or a test file in vim and it's then sent to another tmux window to run. When the test fails, I want to jump back to vim, with some file from the stacktrace opened. This should sound familiar to the IDE users: that's what you get when you click on an individual line in a stacktrace in vscode/intellij/etc shell. It's a pretty basic feature. It's also an important one as it removes frictions from the flow.

I haven't been able to find this for the vim + tmux combo[*]. And so I had to do it myself[**]. It's a tmux plugin. It's not vim specific and it can open more than just file links. However, as the end result is more generic, it's worth stressing that the main itch to scratch was to support the above workflow.

[*]: I've since learned about vim-test[1] with quickfix strategy which sort of fits the bill

[**]: For posterity: this wasn't the first attempt. Prior to that I was using a kitty's terminal[2] hints plugin with a bit of python code on top[3], but it really falls short for multi pane windows

[1]: https://github.com/vim-test/vim-test

[2]: https://sw.kovidgoyal.net/kitty/

[3]: https://featurist.co.uk/blog/file-links-in-terminal/

A Tmux plugin to open file links in vim, urls in the browser.

Transover is a good tool for surgical translation:

- https://addons.mozilla.org/en-US/firefox/addon/transover-ff/

- https://chrome.google.com/webstore/detail/transover/aggiicla...

Oh man, I'm two bots down: https://twitter.com/Hn251 and https://twitter.com/Hn150

Clickable link from the submission https://github.com/artemave/node-test-runners-benchmark

> Doesn't it feel inappropriate to express gratitude as an "issue"?

Indeed! It must equally feel inappropriate to close a gratitude issue.

How to make code reviewee fall in love with you:

1. Make a list of your points

2. Throw away half of them

3. Publish the rest

Came here to defend my plastic Lenovo. Two years and counting, looks and feels like new. The keyboard still makes me want to just keep typing.

I stash mine here https://twitter.com/hackercomments?s=21

> People rarely criticize Apple for the products themselves

Apple prrrrrrrrrrrrrrrrrducts smetimes prrrrrevent them frrrrrrrrrm ding s

> Understanding hooks did take effort. Only after I read Dan Abramov's article a few times was I able to write hooks w/ deterministic results.

A tool for building web pages that requires that level of effort to learn it is not a good tool.

If you haven't already, you might want to check out coc.nvim https://github.com/neoclide/coc.nvim

codedokode's concerns are spot on. You, on the other hand, do sound like Prigozhin's troll.

I guess it depends.

Compared to React, Hyperdom:

- does not require any state management beyond regular javascript

- is fast

- has a built-in router

- has input bindings

- has a small, concise API

is 9k gzipped

As for Mithril, there is a great write up that goes into a detailed comparison on their website - https://mithril.js.org/framework-comparison.html#react. One thing stood out for me personally - and it's true for both frameworks - it's pragmatic. There is just not much to it. There is just not much to building SPAs as React might make you think.

On the other hand, React has a massive community and a whole lot of complimentary projects that solve all sorts of problems - I am thinking of styled components for instance - and so perhaps, from that point of view, React is rather pragmatic.

> Components might need to be released “together”, but if they are worked on by different teams, it means they’ll have a different release process, as in different timeline, different priorities.

released "together" == part of the same feature. Timelines, release process and team priorities are all there to help to deliver features. If they stand in the way, they need to be adjusted. Not the other way around.

Multi repos encourage silos. Silos encourage focusing on the goals of the silo and discourage poking around the bigger picture. Couple that with scrum, that conveniently substitute real progress metrics with meaningless points, and soon enough you end up with an IT department, full on with processes but light on delivering value.

> Having different teams working on different components in different repos will lead to an interesting effect ... nobody wants to own more than they have to

... and so nobody really understands how all of the components tie together and as a result it takes weeks of manual testing to release.

Yes, I am mac user. Should have made mentioned it in the post.

I downloaded your video, but it is just black screen all the way through.

Nice!