> Instead of my usual choice maim(1) , I tried grim(1) , but unfortunately grim’s -T flag to select the window to capture is rather cumbersome to use (and captures in 1x scale).
>Does anyone have any suggestions for a good alternative?
I guess this is something people have to make? I wrote one 6 years ago in Golang and rewrote it in Rust last year. I have stopped using it, but I had them running for 6 years without issues.
I have been trying to find an equivalent for `tracing` first in Python and this week in TypeScript/JavaScript. At my work I created an internal post called "Better Python Logging? Tracing for Python?" that basically asks this question. OpenTelemetry was also what I looked at and since I have looked at other tooling.
It is hard to explain how convenient `tracing` is in Rust and why I sorely miss it elsewhere. The simple part of adding context to logs can be solved in a myriad of ways, yet all boil down to a similar "span-like" approach. I'm very interested in helping bring what `tracing` offers to other programming communities.
It very likely is worth having some people from the space involved, possibly from the tracing crate itself.
I wonder whether it's achievable to have a plugin system similar to how web extensions work where you could write a plugin and have it work across different editors. I see how getting people to move to this editor might depend on people moving over once a sufficient amount of their current editor's features are supported, some of which might be contributed by extensions.
Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.
Tangential to this I've wondered if it's possible or advisable to have a utility to port VS Code plugins to a plugin that's compatible with the JetBrains IDEs.
So an interface like LSP but for plugins… very interesting idea!
Text manipulation operations are fairly simple to define and can probably be abstracted away into some generic API. Then writing generic text manipulation plugins should be very doable.
The complexity comes with project management, multiple files, build actions, etc. But you could define language specific sub-interfaces and the plugins would implement them. So a C++ plugin would understand CMake files for example.
The complexity comes with interaction in general. Writing plugins on their own is simple. And defining a good API for most common use cases is also not hard today, as we have enough experience now. But the hard part will be defining an independent Interface which will work everywhere on a satisfying level.
I mean that's basically the biggest selling-point of plugin-systems today. Not that you can write your own functions to do something, but how well you can integrate it into the interface and deliver your own interface to enhance the app. And another part would be safe interaction with other plugins, and necessary package-managment.
There seems to be some trend, to outsource plugins into their separate processes, so you can write them in your preferred language. So APIs are already being established here and there. All we probably need is someone carving out a standard from them, with room for editor-specific enhancement, and then convince the projects to support this.
Maybe the neovim-people could get together with other projects, start some group, project, whatever to discuss this further? Of maybe something like this already exists?
Maybe we could invent a standard technology for defining interfaces between software pieces. We could call it Interface Definition Language (IDL for short). And then we could have something that brokers requests to those objects to facilitate intercommunication. We could call that an ORB! Finally a good idea!
I have an even simpler idea. We can have some kind of protocol header that specifies the size and shape of the structures and functions that can be called using a binary-level interface. Then we can just provide the implementation as machine code where the header maps each callable function to its respective code block. To "return" values, the callables can just push their results onto a "stack" at a known location and return control to the caller.
The bonus is this should be really fast and it doesn't even require any codec or message copying.
I have been thinking about something like this as well. My idea however was to integrate sway/i3 and your terminal of preference (kitty here) with your server over ssh or using eternal terminal. My idea was to simply open new terminal windows already attached to the session and remember their location. I haven't thought about it thoroughly, but this seems like a good alternative for the time being. Might give it a shot on Tuesday at work :)
I'm currently trying to get into game development and Rust so I'm trying out Amethyst: https://book.amethyst.rs/master/. I wanted to follow along with a roguelike game tutorial for Rust, but there was a problem. I would love to make some games that you can play co-op with some friends as I feel like there aren't enough games like it out there.
Nice! I just did a simple roguelike in Rust a few months ago. I somewhat regret not looking at what it would take to make is work with wasm from the beginning, though.
You might want to give wayshot a "shot"? https://github.com/waycrate/wayshot