131–140 of 223 posts
Looks cool! Hope Rust gets some libraries like this, i'd love to make use of this functionality!
Really nice design. I like CLI and TUI, they can be both practical and aesthetically pleasing, in my opinion the "beauty" of tools is something that can improve the quality of life for the end-user. But I have a few negative remarks. - The glow.exe app on Windows is 19M, the launch is fast and I love that it is self contained and portable, but I think that even a pretty markdown viewer could be compiled to a much sma…
I've not dug into it but syntax highlighting for code fences probably is costing some space for the syntax definitions.
I wonder if the vt-100 terminal emulator will be used to surf the next "web"... Instead of web sites, the nerds will run their own ssh servers, then you can run programs and read files on their "web site" (ssh shell). This has many advantages over the current web, for example built in user management - you can allow anyone access by their public ssh key. Now you say what about graphics ? Text only might be a break fr…
That used to be a common practice before the advent of the web. There are still plenty of them around, including a few games.
> Now you say what about graphics ? Text only might be a break from the ad ridden web today, but you could also ssh -X to run GUI apps.
There are some extensions outside of the VT100 protocol that allows things like graphics. Emacs buffers are capable of much more. They could achieve graphics right in the terminal. Ultimately, they are all variations of the same idea that HTML and CSS are based on.
Earlier quoted context omitted.
What I don't understand is with the recent adaptation of GPU-accelerated terminals, why not create something that actually renders Markdown like you'd expect in the browser, but in the terminal? It would have to be significantly faster than the bloat of a typical browser, but just with limited features... like no JS engine.
What about 'glow' and 'glamour' components of the charm project? What is their difference from what you propose? Aside: I use glow to display help for special keybindings mode on sway.
This looks cool! But: These mostly aren't command line applications, they're mostly terminal applications. They're no more "command-line" than running "firefox" from your shell is "command-line". There's a big difference... a terminal application takes over your terminal and doesn't have all the usual advantages of command-line applications used from the shell, like history and easy scripting.
What do you mean "takes over"? You can always open another tab inside your terminal. You can use tmux to open multiple panes inside the same tab.
> and doesn't have all the usual advantages of command-line applications used from the shell, like history and easy scripting.
That may be true but at least TUI apps can be truly platform and DE independent, unlike GUI apps coming out from GTK4 where every non-trivial GTK4 app in existence is a libadwaita app. Qt apps are buggy on Wayland right now. In such a scenario, anything that runs on a terminal is a welcome addition for me. I'm done with GUI apps, except my web browser.
I have one major problem with a lot of the recent TUI stuff that’s been happening: it almost always assumes dark terminal, and uses techniques that work poorly or terribly on light terminals. For example: bat’s default colour scheme uses white text for the contents of files except where syntax highlighting changes it. Not the default colour, but white . This makes it completely unusable for me without --theme=ansi (w…
lipgloss, the ANSI color library from Charm, has support for specifying different colors for light and dark terminals. https://github.com/charmbracelet/lipgloss#adaptive-colors
Actually, on reflection I’m inclined to reckon lipgloss.AdaptiveColor an actively harmful API design direction, because it makes doing the right thing harder (scattered, inconsistent definitions) and encourages doing the wrong thing.
A vastly more robust approach is to shape your app around themes/palettes, and then allow the terminal’s colours to influence the default palette. Much like the traditional HTML/CSS approach: don’t use style="color:red;font-weight:bold", but rather class="error" and load in a stylesheet that says .error{color:red;font-weight:bold}.
Such an approach is also, incidentally, more flexible and user-pleasing because it necessarily allows more than two themes, allowing users to choose their own palette if they’re not happy with your default—though how that’s exposed is a distinct matter, especially as to whether ad-hoc themes can be created.
lipgloss looks to support some useful fundamentals for such a theme-based approach (styles, even with inheritance), but not to have built a palette abstraction on it, or adaptive palette selection, which is what you really need.
I love the general renaissance of terminal UI tools we are seeing in the last few years. I can't quite put my finger on what I like about it so much. Something to do with the simplicity and directness of these UIs, guaranteed optimised for efficient keyboard nav, widespread adoption of vim-like navigation keys, and the fact that they link directly with my terminal shell so I can stay entirely in a stream of thought w…
My first exposure to anything that could be related to professional day-to-day work was when my dad taught toddler-me how to use DOS in Windows 3.1 Unfortunately for me, I didn't do anything else remotely related to programming until my 20s. But I think this early exposure to a command line made it much easier to go through tutorials, since everything that I used to learn early on involved a unix terminal. Anyways, c…
I love the general renaissance of terminal UI tools we are seeing in the last few years. I can't quite put my finger on what I like about it so much. Something to do with the simplicity and directness of these UIs, guaranteed optimised for efficient keyboard nav, widespread adoption of vim-like navigation keys, and the fact that they link directly with my terminal shell so I can stay entirely in a stream of thought w…
You can configure kitty to open the entire scrollback buffer in an editor or a pager(less/nvim etc). https://github.com/kovidgoyal/kitty/issues/719