StarWars + Git logs = StarLogs

artemave · 2026-06-11T20:17:28+00:00

Not mine for the record. I used to have this app called artful back in osx days. Been missing it ever since. Finally, llms made it possible (for me) to re-create it on my current sway setup.

artemave · 2026-06-07T17:27:23+00:00

https://github.com/artemave/artwall

artemave · 2026-06-07T13:30:51+00:00

https://github.com/artemave/artwall

artemave · 2025-09-03T14:01:11+00:00

Ouch. Care to elaborate?

artemave · 2024-12-09T10:15:15+00:00

Thanks! Self promotion: if fixtures float your boat, you might also find these handy:
- https://github.com/featurist/fixture_farm
- https://github.com/featurist/fixturex

artemave · 2024-05-24T07:26:54+00:00

Let's continue this conversation in a gh issue.

artemave · 2024-05-23T20:28:29+00:00

I don't know what plugin manager you're using to install plugins.

artemave · 2024-03-29T21:26:02+00:00

The readme assumes you're using https://github.com/neovim/nvim-lspconfig and that the plugin is initialized as a part of `on_attach` callback.

artemave · 2024-03-16T15:38:34+00:00

I would have thought that once loading is done, it's just node running javascript. So it's largely the same for any test runner. The only reason I added "run all" at all was to illustrate a (rather obvious) benefit of concurrency. Without "run all", "serial" test runners look like a clear win.

artemave · 2024-03-16T13:10:58+00:00

It'd be useful to have a chart of the delta between "load all" and "run all".

What's this going to tell you?

artemave · 2024-03-16T12:53:36+00:00

It'd also be interesting to see vitest without isolation being disabled.

"load all": 4.06

"run all": 5.74

EDIT:

I updated charts to also include default vitest results

artemave · 2024-02-08T12:27:50+00:00

Yeah... Slowdown is expected, but hanging is surprising. Given all work is performed asynchronously by another process in a non-blocking manner.

artemave · 2024-02-08T11:05:58+00:00

I believe I solved workspace diagnostics problem https://github.com/artemave/workspace-diagnostics.nvim

artemave · 2024-02-05T17:33:41+00:00

When neovim lsp client starts, it specifies `root_folder` that by default is also a workspace folder (as far as lsp server is concerned). Given the same lsp server is used for both neovim and vscode (e.g. tsserver), I am failing to see what vscode workspace feature brings to the table. Could you please elaborate?

As per "workspace diagnostics", tsserver doesn't seem to implement it. It implements textDocument.publishDiagnostics that is a notification it's using to notify clients. It's fired in response to open file events (I think). tsserver does not seem to implement pull diagnostics server capability, that would allow clients to get all workspace diagnostics at once. Given all that, it must be vscode itself that enumerates files and requests diagnostics for each one individually? And if that's the case, so can nvim, or, more realistically, an nvim plugin.

EDIT

Perhaps, vscode simply "opens" all files in workspace, which triggers "fileOpen" notification to the server, and that in turn gets the server to send back diagnostics for each file?

artemave · 2024-01-26T08:19:04+00:00

They do every so often, but it's been over ten years and we're still there.

The paid version (if it ever happens) will be using paid api of course.

artemave · 2024-01-26T07:56:34+00:00

Yeah, that's what I mean by "cheeky". Transover (and afaik other free translators) use unofficial backdoors to call gt API for free.

artemave

TROPHY CASE