Threads for mgutz
-
I am happy using most of the default unix tools (
vi/vimare fine,grepis fine,awkis great, etc), but usingbash/zshreally hurts now that I’ve spent a few years withfish.findas well–fdis so much better.-
Yep, love
fd. Alsorg(ripgrep).I’ve been using one variety of BSD or Linux or another almost 30 years, and out of the batch of new trendy tools those are two that have really made a big difference to me.
-
Been using Linux for 23 years and there are a few programs that have changed the way I interact with a computer. Among those, you’ll find some old, usual suspects like Emacs, awk, and git, but in the past couple of years, fd and rg have changed some of my own habits. I went from a model where I tried to very precisely organize (usually, unsuccessfully) data to a model where I put everything in a big heap and search for what I need.
-
-
-
-
I use it as my shell. I don’t really use it for scripting, except for setting up aliases and the like. Syntax highlighting and the magical autocomplete are the things I really miss when I use a different shell.
-
-
-
I created an IDL with plain typescript interfaces. The tool parses Typescript AST, converts exported interfaces and meta to JSON. From there I use simple ES6 template literals to generate code.
I started creating my own DSL, but why not just use TypeScript. It’s simpler than gRPC or GraphSQL for generating code. I would never write OpenAPI (feels like J2EE for APIs).
Typescript has mostly everything you need:
export interface AddArg { a: number; b: number; // required is '?' c?: number; } export interface Math { // language specific instructions through tags /** @_go { ident: 'Add' } */ add(arg: AddArg): number }I create strongly typed TypeScript requests in Next.js frontend and Go backend code from the JSON IDL.
It’s not in a state where I want to share the repo yet. I’m iterating on how to process templates more intuitively, taking ideas from
hygen. -
-
Just watched the demo video and must say this looks pretty cool. Especially that you can write native components & then call/“invoke” from your JS code. Basically a kind of FFI, right? It says you can already do native dialogs, presumably through the same mechanism - I wonder whether that could extend out to eg Cocoa and/or Win via, I don’t know, QT or wx or something? That would be a real killer - desktop app with native logic layer, access to native GUI widgets, all scripted together with JS, bundled up into a small and decently-performing package that doesn’t eat up lots of resources. Unfortunately way above my native-GUI-experience/available time, but … a man can dream, can’t he?
-
Tauri has a similar architecture to Electron in this regard: both have a main process and a renderer. It just happens that with Electron, both are JS, and in case of Tauri, the main process is Rust. In both, the two processes can communicate via IPC. In both, you can make native calls to the OS (Electron can pop up native dialogs too, and the main process can use modules that have native, non-JS parts, etc).
A desktop app with a native backend is possible, both with Electron and Tauri. Access to native GUI widgets is also kind of possible, but in both cases, from the main process, not from the renderer. The renderer is pure JS in both, so you can’t (at least not easily, not without jumping through plenty of hoops) mix native widgets into a web view.
-
-
It is using IPC, not just by the sounds of it, but based on the code too.
Mind you, not having FFI in the WebView is generally a good thing. Electron defaulted to
nodeIntegration: truefor quite a while (and you can still set that option), which made node APIs available to the renderer process, and that becomes a security nightmare the moment your webview meets untrusted content.
-
-
-
I don’t think they’re focusing on integrating native widgets other than things like file open dialogs. It’s a web-based desktop app platform just like Electron except it uses the WebView library installed on your desktop and Rust. The JavaScript runtime has a fairly robust API to access the desktop, file system, etc. You rarely need to write functions in Rust.
-
Fair enough, & thanks for the info. I’m just wanting something different, I think, as part of the point of a native environment for me is to be able to access platform APIs but do the UI declaratively in a friendly/already-familiar cross-platform way. I’m probably not the target audience. It looks cool anyhow!
-
-
-
I use frp. Easy to setup.
-
M1 is definitely the best balanced laptop right now—price, battery life, excellent if not great performance. Just waiting for Macbook Air refresh with better screen to body ratio like the new Pros. I just hope prices stay resonable.
-
-
I end up choosing coding fonts based on the application and OS. For example, there are only a few nerd fonts that properly render tmux pane and nvim popup borders in Windows Terminal, namely sauce code pro and ubuntu. On Linux most nerd fonts just work. On Mac OS I have to choose a thinner font as the Mac renders fonts “thick” according to my eyes.
-
yaymukund
1 year ago
|
link
| on:
LunarVim: An opinionated, extensible, and fast IDE layer for Neovim
“My minimal config with a good amount less code than LunarVim loads 40ms slower. Time to switch.”
- @mvllow, Potential LunarVim user.
This made me wonder - does LunarVim perform any sort of optimizations on top of lazy-loading plugins?
-
What’s the trend with UI’s designed for touch? It would make sense if the OS was designed for iPad. How many use Gnome on a touch device? Adding more whitespace doesn’t simplify a UI.
-
I finally got annoyed enough with GNOME 42 to switch to Plasma 5. I’m totally into it. Between the global menu, redefinable shortcuts and flexible panels and widgets (and the fact it’s zippy and responsive), it’s everything I wanted GNOME to be. No looking back.
The web-like hamburger menu is one of the few features I like in Gnome. It’s cumbersome to move the mouse all the way to the top left of a wide screen monitor to access a fixed global menu. On a laptop, a global menu isn’t as annoying.