TUIs
github.com
github.com
Don't get me wrong, JetBrains has some cool stuff. It's nice to see they're working on a lighter-weight text editor to add some competition to the newbie-friendly text editor market. And JetBrains Mono is a phenomenal monospace font.
IntelliJ is open source/FOSS/FLOSS/Free Software, etc, here is the code[0], license is Apache 2.0.
As an editor, I really hate it coming from vim. Even with vim mode, it sits in the uncanny valley for me. It's pretty close to vim, I'd say 95% of the stuff works as I'd expect, but the last 5% is jarring. My biggest annoyances are:
* The undo behavior is insane, I'm constantly double-tapping u, because undo brings your cursor back to your last edit, but doesn't undo it. Unless your cursor is already where it should be, then it will undo. So it's uu then ctrl+r (sometimes).
* They don't have vim tabs (I don't think any modern IDE does). I'm constantly closing and reopening splits, it drives me crazy.
* There's no toggle fold, gotta explicitly unfold/fold. That muscle memory is stuck with me now, even in vim which makes me sad.
* Moving between the different panels is not the same as moving between different splits. You need to memorize the hotkey for each panel and then the hotkey to get back to the code, it feels extremely unnatural. The vim hotkeys are hit or miss in the different panels as well.
Despite all that, I still used it when I was working on a Kotlin codebase. I wish it was possible to extract their language processing stack and use it in vim to have the best of both worlds.
This is a much better way than stock vim. In vim, if I scroll elsewhere and undo, it jumps back to the last edit and already undone the edit and sometimes I'm not sure what got changed but in IntelliJ it jumps back first, so I can see what will change before it gets undone and also I can just use 'u' whenever I want to go back to the last edit's position.
> also I can just use 'u' whenever I want to go back to the last edit's position.
I use ctrl+o for this.
My dev workflow consists of 4-6 screen sessions with 3-5 terms each. Each one represents one "task" (usually a branch), and I use git worktrees to keep separate copies of the repo that are linked at the git object level. An IDE that insists on being a GUI makes me feel like I'm using a toy OS like Windows.
As a bonus, this is a remote-native setup, which made covid trivial to adapt to. I'm exactly as productive in the office as I am at home or on planes or in Ubers or at wine bars on sunny afternoons (modulo extra screen real estate).
gnuplot> set term dumb
Terminal type is now 'dumb'
Options are 'feed size 79, 24 aspect 2, 1 mono'
gnuplot> plot sin(x)
1 +--------------------------------------------------------------------+
| * * + * ** + * * |
0.8 |-+ * * * * sin(x* *******-|
| * * * * * * |
0.6 |-+ * * * * * * +-|
| * * * * * * |
0.4 |*+ * * * * * *+-|
|* * * * * * * |
0.2 |*+ * * * * * *+-|
| * * * * * * * |
0 |-* * * * * * *-|
| * * * * * * *|
-0.2 |-+* * * * * * +*|
| * * * * * * *|
-0.4 |-+* * * * * * +*|
| * * * * * * |
-0.6 |-+ * * * * * * +-|
| * * * * * * |
-0.8 |-+ * * * * * * +-|
| * * + ** * + * * |
-1 +--------------------------------------------------------------------+
-10 -5 0 5 10I've even written my own simple barplot program in awk for generating quick-and-dirty comparisons in shell scripts.
Minitab!
Makes me wonder, though, is there enough space in unicode to just encode every possibly 16x16 bitmap? 256 bits?
Space is not an issue here. You can do with very few characters, just make them combine with each other, like ˩˥ is encoded as ˩+˥, flags are encoded as combinations of two letters, etc.
So, you can just have 256 characters for each bitmap dot and make them combine with each other. Or have 16 characters and make them combine (maybe using zero-width joiner).
I think the biggest problem is actually getting this thing into Unicode. Emoji got codified because some Japanese phone encodings included them. But it would be harder to justify arbitrary bitmaps.
Up to four (or more?) in some cases. Example: The flag of Scotland, that's a four-character combo IIRC.
Not 100% sure I understand your requirement, but does `column` fit the bill?
$ echo -e "foo,bar,quux\n1,2,3" | column -t -s,
foo bar quux
1 2 3 $ echo -e 'foo,bar,quux\n1,,3' | column -t -s,
foo bar quux
1 3
> Version 2.23 changed the -s option to be non-greedy
Elsewhere on an ancient Ubuntu I have lying around, `-n` did the same:
-n By default, the column command will merge multiple adjacent delimiters into a single delimiter when using the -t option; this option disables that behavior. This option is a Debian GNU/Linux extension. $ cat iris.csv | ph columns setosa versicolor | ph head 15 | ph tail 5 | ph show
setosa versicolor
-- -------- ------------
0 1.5 0.2
1 1.6 0.2
2 1.4 0.1
3 1.1 0.1
4 1.2 0.2Is there such a thing as a TUI launcher out there? Something that allows fuzzy search of program names, tags and a short description (using something akin to .desktop files for the application metadata). Then, when I suddenly need a program for a certain task, I don't have to hope I memorized the correct command. I just open my TUI launcher, type something related to my task and get a list of some TUIs that could help.
Also I use dmenu and a script for using aliases in dmenu, and I create aliases for popping them out in new terminals. Really fast workflow.
If you're using a lot of tui stuff changing workflow from double click to launch really makes the whole experience smoother, much smoother than GUI stuff.
If you don't want a package cluttering up your system, but also don't want to forget about its existence you can just comment it out.
A usual line for an install is the package name, the package type (flatpak, appimage, tarball, AUR, deb, etc) and a description of what the package is. Not much longer than the command I typed in to install.
I also keep notes on changes to the system, services created, paths changed, firewall rules, detailed notes on big things and stuff like that. Any time I run into something weird I reference it and make sure it's not something I did before I go hunting for a solution.
[0] https://github.com/lpsantil/slmenu
1. You're limited to binaries and executable scripts in your $PATH
2. Many commands do not have bash-completion support.
vi mode for bash, bash-completion are both innovations trying to tackle this optimization of workflow. I see tools like dmenu and slmenu as better ways to give richer UI and create/reuse workflows. GP's request for `allows fuzzy search of program names, tags and a short description` is highly doable in dmenu/slmenu if not already done [0]. Not so much with bash, vi mode for bash, bash-completion.
May also use i3-dmenu with fzf:
urxvt -title "fzf-menu" -e bash -c 'i3-dmenu-desktop --dmenu=fzf'Coincidental - I just reinstalled my machine and this is the first site I came to. I keep all the applications I installed in a 'packages.new' file, and do
apt-get install -y `cat packages.new`
Hey, I didn't claim it was exhaustively complete :-)
I have not used any appimages or flatpaks much. If I am using a program and it is not available on my new install, I'll remember to install it when I look for it.
For source compilation, it's frequently for a once-off use (maybe the repo software is too old, so I compile the latest). Mostly, when I move to a new version I don't need to recompile from source.
Properly taken notes are much more than a memory aide.
> I'm in the habit of keeping a text file with all software I've installed and updating it immediately.
What’s the problem with writing a .desktop file for a TUI app? Make the exec line open a terminal and run the app in it. If you want to open the app in place you could probably have the exec line determine the focused terminal and send a command to it to have it run the app.
A launcher could also be a "standard" middle layer that defines common key bindings for tasks that people prefer different TUI applications for (e.g. "m" --> mail - whether it's "mutt" or "mail" or "sup-mail" or "pine" behind it).
I don't use one at present, but took the short cut to define 1-letter shell aliases for some of the more common ones:
e: _e_dit <file> (Sublime)
n: _n_ote taking (own system)
m: new e-_m_ail (sup-mail)
p: show processes (htop)
I've been looking for GUI launcher/software-catalog solution for Windows with those characteristics.
Still haven't found any.
$ apropos -a data term
fidentify (8) - Determine file type using PhotoRec database
Pod::Text::Termcap (3perl) - Convert POD data to ASCII text with format escapes
sql (1) - execute a command on a database determined by a dburl
termcap (5) - terminal capability database
terminfo (5) - terminal capability data base
tput (1) - initialize a terminal or query terminfo database
vd (1) - a terminal utility for exploring and arranging tabular data
visidata (1) - a terminal utility for exploring and arranging tabular dataSometimes it's useful to have a subset, which is what a menu does.
In practice, I find that there are a handful of various "swiss army knives" I return to again and again. Some of the new tools are indeed impressive, but an be implemented or offer features available in other utilities.
For myself, "apropos foo", "apt search foo", and the DDG bang "!dpkg foo" are almost always excellent starting points. Debian packages somewhere north of 70,000 individual software packages these days, and will almost always have a tool to do a specific job if not the tool you're looking for.
And yeah, the kids these days are using flatpacks and pip and nodejs and rpm (not to be confused with RPM), etc., though back in the day we had CPAN to deal with. (It still exists, of course, it's just less significant.)
Check out notcurses-demo and see what you can pull off in a terminal. My only gripe is that tmux degrades significantly. Regardless, dankamongmen is an awesome dude bringing back the demoscene vibes.
Edit: Looks like I should clarify – I'm not saying that people should stop creating TUIs right now: in the current landscape, TUIs do have advantages like being usable over ssh, text selection, a simpler programming model in most languages... but I'm arguing that these advantages aren't inherent to TUIs. We should aim to improve GUIs, not stuck in a interface from the 70s. Unfortunately I've seen too many people (including a big chunk of HN) that argue that TUIs are just inherently superior.
I mostly agree. I use Midnight Commander a lot but I'd prefer a basically identical GUI version with the same keys. None of the Linux GUI orthodox file managers I looked at were comparable, though I didn't do a comprehensive search. (Edit: There are tons of GUI orthodox file managers for Linux. I was wrong.)
The main advantage of a TUI to me is that it is available over SSH more easily. X forwarding exists but I never recall it being particularly responsive.
As another commenter says, TUIs also have advantages in terms of coding.
To make a GUI I have to pull in megabytes of libraries, learn their API, then update them every time they release a new version that will likely have breaking changes. They'll also have questionable bindings outside of one or two "first-class" languages, so reading docs and investigating why something isn't working is harder.
I'll stick with TUIs, thanks.
I have to `pkill -9` firefox once every few days because of bugs; a few months ago it used to break the clipboard until it was restarted, these days it freezes when dragging tabs around in the tab bar, tomorrow I'm sure it'll be some new bug... I'm glad I don't lose my editor / IDE / chat clients / monitoring dashboards when this happens.
(Not to mention that some X11 software doesn't seem to work across the network these days, which causes me no end of frustration since RDP is usually fantastic. Not to mention the bandwidth requirements of graphical sessions, which is a concern over mobile networks.)
VNC would be a more reasonable answer but that is a pain to set up server-side on Linux and isn't very good. Really NX4 is the answer but it costs an absolute fortune.
The only big issues I have with them are security (most don't restrict connections to the same user and I wouldn't be surprised if a lot of them listen on 0.0.0.0) and launching them. There isn't a good cross-platform way to launch a browser.
No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.
You also make your software unusable for people who use assistive software. TUIs are not accessible by default, GUIs can be with only a tiny bit of effort.
TUIs are perfectly fine for internal tooling, but any piece of software intended for general distribution should ship with a proper GUI. Even a basic Electron UI beats TUI in terms of accessibility and internationalization support.
However, neither of the emulators can render the typed text correctly. I tried typing "नमस्ते" into both just now, and they both broke in different ways.
Here's iTerm failing to render a half स: https://imgur.com/a/vg1i4aB
Here's Terminal.app messing up how the quotation mark gets rendered: https://imgur.com/a/B5zd85V
Can foot handle this case? What about GNOME Terminal, Konsole, and Windows Terminal? If I can't reliably read Hindi text on the commonly used terminal emulators on all three major operating systems, then from my perspective a TUI app is worse in every way compared to a native GUI app or even an Electron app.
It's not wrong. Note that it's not a single vertical line, but a line with a smaller line below it (a halant). This has the same meaning as not having that line entirely, namely that the letter is a "half-sound" s rather than a "full-sound" sa. It's just that nobody would write it this way as part of the word namaste; it's only used when talking about the sound standalone or when the half-sound is at the end of a word. (The latter is rare in Hindi, because Hindi is less precise about denoting half-sounds at the ends of words, compared to something like Sanskrit.)
However the halant does seem to be cut too short, perhaps because it's exceeding the terminal's line height. The terminal may need to be configured to use a smaller font size for the Devnagari font. The halant renders fine in foot without having to tweak the size, but of course it depends on what font is getting used in my case vs yours.
Another problem in that picture is that the horizontal line between the n and m has a tiny break, which it shouldn't.
If you have other issues that you would like me to check, just reply back here. Thank you.
Many times you don't have graphical access to the machine. As an example, `htop` is very useful when I don't have access to `gnome-system-monitor`.
TUI's and GUI's can both be used in the middle of a pipe when things require some manual fiddling, Git commit would be an example of this, opening vim to edit the commit message. Here's an example (https://stackoverflow.com/questions/8371877/ncurses-and-linu...) of how you could create an ncurses TUI but still output to stdout.
Dmenu (https://tools.suckless.org/dmenu/) is a good example of a gui program that fits comfortably in a pipeline.
I also recall an article a while back about Emacs and screen readers. Since everything has to be representable as text, rather than accessibility being an afterthought, it was usable with screen readers. I imagine something similar can be said for those who need better contrast or large text, since terminal colour schemes can be defined by the user and software has to handle variable terminal sizes.
In practice, for use cases where you're spelunking through different directories and running different commands: you're going to have an easier time either staying in a terminal (where opening a GUI to perform a task is awkward), or an easier time sticking with a GUI (where opening a terminal to run a command is awkward).
Currently, TUI provides many of the benefits of a GUI, without having to leave the terminal.
For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.
I do think GUIs can learn a few tricks from TUIs. TUIs are often more responsive and usually provide better keyboard driven workflows.
Ultimately my preference for GUIs probably reflects what I'm used to. To paraphrase Jef Raskin, there are no intuitive UIs, only familiar ones.
cfdisk, cgdisk.
Maybe you are afraid of parted/fdisk. Then you are right.
But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode.
You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.
They are a reflection of a time when I would like to have more and it was out of reach.
We used them because it was everything we had access to, that is all.
Growing up with TUIs, I was quite surprised how often people refuse to use a program because it doesn't conform to the "native" look and feel. I've found plenty of people who'll happily use htop in the terminal, but then complain when a GUI app doesn't respect some tiny aspect of look and feel. Even things like the placement of "Options" or "Preferences" in the "wrong" menu causes them ire.
For whatever reason, people just seem to expect different things from GUIs.
- The required libraries you need to install for them. A docker image with TUI tools can be light, with GUIs it will be heavy.
- Usability over SSH is definitely a TUI inherent advantage. X forwarding is an absolute mess, and even if someone tried to improve it probably would still be a mess. Executing code in a remote machine and sending the graphics to another system (possibly with different graphical interface or even operating system) is never going to be as responsive or integrated.
How do you use a GUI app inline inside a screen session? And I mean _use_ it inside, not launch a floating GUI window that's disconnected from your entire workflow.
There are advantages to remaining inside the terminal, for those who are comfortable with the terminal.
I wish conio.h would have been something under Unix, free from the VT100 cruft. ncurses is lacking and awkward to use.
Apparently conio.h was ported to Linux (https://github.com/nowres/conio-for-linux) but I don't think it ever was a popular option.
Though it is a bit weird in that it uses the TP5.5-style objects which aren't as powerful as the Delphi-style objects (very roughly think class in C++ vs class in Java).
The (sadly only German) tutorial linked by the wiki has a bunch of screenshots in a terminal.
[0] https://wiki.lazarus.freepascal.org/Free_Vision#Unicode_vers...
A repo containing README.md is a primitive wiki page. And with GitHub you can contribute (pull requests) or discuss meta (issues).
But a page on Wikipedia or something like it be better. But, it's harder to create such a wiki then a GitHub repo (which most devs are already familiar with). And it might not show up as high on SEO. So GitHub repo it is.
Not having that is kinda the whole value proposition of Big Data.
Github gives you free bandwidth and disk space. In return they get to "grep like a boss" running complex queries with no fuzziness; you don't.
Similar story with search engines and their crawler output. And Amazon's product catalog.
None of these let you turn off the fuzziness and run large/frequent/complex queries, even if you're willing to pay for it. Amazon's "good" product search API is ratelimited by how many convertible leads you send them.
I dunno, it's kinda lame, but I guess that's how things work.
There are other options if you don't like alot. See:
I do this because this way I can have all my chat apps in one app and also all the chart histories together in one database.
But scli is pretty nice too yeah.
I'll start with https://github.com/rivo/tview/ and https://github.com/gdamore/tcell
Been dying to find the time to build something just for fun.
While these are experience values and not strict rules: Astonishingly older users are performing better with TUIs than GUIs, and the worst are usually websites and web-applications. By "better" I mean fast in usage and less prone to mistakes.
The only stuff which is worse than websites are probably voice-assistants, people just avoid them. And voice assistants could be better with local evaluation and open speech database, especially for persons with limited eye-sight.
The #1 thing that messes my (elderly) parents up, using a UI, is inconsistency. In modern software, this comes in two main forms: frequent updates that modify the UI, and screen-takeover notices (often about updates that have modified the UI, or to beg the user to perform an update that will modify the UI).
These are much rarer in TUIs.
Vim, for example, excels at quick nimble edits for someone who darts around the filesystem in their terminal. Even if you have to pop back into your shell for a command or two while editing, you have the option of C-z and `fg`.
The same thing applies to many TUI tools as well. Many of them deliver things you could get with more primitive tools, as well (say `btop` and `htop` vs `ps`), but have a nicer feedback loop while still allowing for pop-in-and-pop-out interactions. GUI alternatives would have you pushing the mouse around a lot without much benefit.
That, and they work well through SSH, without the hassle of setting up X11 forwarding. For other TUI tools that are typically used in longer sessions (e.g. `gdb`), that is also a huge benefit. Most likely you won't even realize how huge until you have tried to set up a non-TUI alternative for the same scenario (the remote debugging service for Visual Studio is a nightmare to set up, for example).
And since there are obvious limitations, developers must focus on core functionality rather than getting paddings and margins right and be more creative in the process.
TUIs are typically very responsive- you issue a command, and there's no wait. Feedback is nearly instantaneous. There are GUI apps that share this characteristic, if their authors put latency concerns as one of their primary goals, but the majority do not. Even fractions of seconds are noticeable, and make a significant impact on the usability of an application.
TUIs are keyboard driven, so I don't have to reach for a mouse for most operations, which slows down most operations, and can promote RSIs. GUIs do often have keyboard shortcuts, but they still suffer from higher latency, and generally aren't a high priority concern for the UI author, so the shortcuts tend to be inconsistent, and not usually customizable, and users typically cannot create their own.
I can get a TUI up and running on a remote server trivially, and at rather low performance costs. Doing the same for a GUI is a much worse experience. And when it does succeed the GUI is detached from the general interface through which I am managing that remote services (a shell session running over SSH).
Honestly I wonder if there is a way to speed it up. Like a new terminal mode which lets you write or color a particular row/column directly, or utilizes the GPU to render to each pixel, or really anything better than literally printing text with fancy spacing, escapes, etc. on each refresh.
Until then, anything which is render-intensive you're much better using a GUI, even if it's just a shell script which opens a window while it's running.
And if you are sending video or animated graphics, then perhaps a special video-orented protocol is a much better choice. Like that browsh project - I am fairly sure the performance would be much better with special protocol.
But to your question, yes there are 'text' console bitmap graphics protocols. Check out sixel for one example: https://saitoha.github.io/libsixel/ Some terminal emulators support other bitmap graphics too.
That is not accurate, and your example is absurd abomination of the text-based concept (but is nevertheless a fun demonstration of capabilities).
I run TUIs that push hundreds (sometimes thousands) of changes per second to a 80x48 canvas. There is zero lag induced by the front end.
You can easily write a TUI that only updates the View (at a particular location and color) when the View Model changes.
Run `arch` in a terminal. Does it return `arm64`?
Interestingly, I just opened Alacritty on my M1, and it's showing `arm64` now. I know it didn't before. The app has been upgraded because macOS's security tools blocked it when I tried to open it and I had to explicitly allow it.
Maybe it was an issue that they've fixed since I last looked?
- Argument parser - https://github.com/tyrrrz/CliFx
- TUI builder: https://spectreconsole.net/ and https://github.com/spectreconsole/spectre.console
https://news.ycombinator.com/item?id=30732274#30732565
> I was looking for a C# version [of Turbo Vision]
mentioned: https://github.com/elw00d/consoleframework + https://github.com/jinek/Consolonia
This feels like such a dangerous new cargo cult to me: ooh terminal good, hackers are here! Let's build applications for this! Ok, so... you may be in the console. But unless your program can be easily controlled & ran by other command line processes, unless it has machine-readable output, imo, you've simply imported the bad/ill/damaged/corrupt into a world that historically was usually much better.
Building little isolated insular worlds is what apps do. On the terminal, I expect systems to compose & interoperate well. I have yet to see a TUI toolkit/library that demonstrates any form of commitment to first-principles of the shell world. That was my comment 26 days ago, seeing Bubbletea[1], a leading Go based library. This all feels so icky, so wronghearted to me. It could be done responsibly- yes- but it's not. This feels so wildly to be missing the point of the terminal, the shell: to be a complex, interwoven system, where anything- not just some basic pre-determined rote functionality- is possible.
It's never quite been as easy/convenient as it should be, but services which offer a non-console but other machine-to-machine interface could suffice. Which if any of these listed examples offer HTTP or DBus interfaces for control? (Not a lot, alas, but perhaps some?) If you do want to build an application, these are good ways to make it externally controllable. I'm not aware of any dbus nor http tooling that makes interfacing with these protocols super slick & easy & friendly from the command line, but there's at least ways to do both, and we probably ought refine our script-foo in both realms.
Another thought is that the libraries/frameworks could help a lot. Ultimately frameworks like Bubbletea are ways to display stuff & script actions. Why don't we make those actions first class citizens and have the library natively expose actions in a command line format? I dont a lot of console apps do this, but a pattern I love is being able to feed a command sequence into a console program. This example is terrible, I need to think of something more purposeful, but for imagineering sake, perhaps:
my-tui-music-player --enqueue album:40-oz-to-freedom --enqueue album:steal-your-face --randomize --play 10 --wait 20s --volume 0.8 --clear-playlist --enqueue never-gonna-give-you-up --play --wait 20s --pause
Both have their place. Often you'll see TUI apps being built on top of their cli counterparts, in other cases both interfaces are built on top of a common library.
What you describe in your music player example is a cli interface and imho shouldn't be in the TUI binary.
I'm not sure why you need HTTP or dbus for control. Just use stdin and stdout. For example:
cat << EOF | my-cli-music-player
enqueue album:40-oz-to-freedom
enqueue album:steal-your-face
randomize
play 10
wait 20s
...
EOF
cat << EOF | dc | espeak
100 k 22 7 / p
EOFTools like espeak and dc that you cite fall into the conventional cli-tools camp. By compare mamy of the TUI tools we see here have their own autocomplete systems embedded in the program, multiple screens, full terminal layouts, multiple on-screen focus-able areas.
Or is this expectation more for TUIs?
I was young & barely knew it, but KDE's DCOP seemed like a very adequate way to script & control any app- that was awesome. Today on FreeDesktop, some apps do a good job of exposing themselves via DBus; music/media players in particular have very widespread support for the mpris interface, for example, but all sorts of apps expose control this way. The programming language Vala[1] in Gnome world has excellent DBus integration built in, so one can take some of their application models & expose them to the world, very much easing making m2m interfaces.
[1] https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_T...
more HN clients:
https://github.com/ggerganov/hnterm
https://github.com/wtheisen/TerminusBrowser (also supports 4chan, reddit and others)
RSS reader: https://github.com/qw3rtty/neix
window manager for the console: https://gitlab.com/AutumnMeowMeow/xtermwm
lots of other top replacements out there as well: bpytop, vtop, gtop, bottom, zenith, tiptop, nmon etc.
and even more resources for this kind of stuff: https://old.reddit.com/r/commandline/
Of course I could use a simple GUI text widget with fixed size font, but I doubt it'd be fast...
Maybe notcurses ?
Unfortunately there's nothing like that on the list. Any recommendations, HN folks?
Nowadays still available (in spirit) in Free Pascal and a C++ port.
Of course you can make a bunch of text files but Easy categorisation, browsing, auto saving and even something as simple as window-size based word wrapping is difficult with most editors. Of course they're not really made for it.
But I've never come across something like this.
org-mode is bundled with emacs, but org-roam [1] you gotta install yourself.
Although org has a huge ecosystem (org-roam is quite good), you don't need to go beyond plain org-mode if all you want is the features and general working model of OneNote. It's basically all there, batteries included.
Well, there's a lot of games inside emacs
> Well, there's a lot of games inside emacs
One disclaimer though: I'm using version 0.14. Starting with 0.17 or so the UI got a bit too noisy (loads of colors), but most importantly the tool got extremely slow. Like the startup time jumped from not noticeable at all to several seconds, which is absolutely unusable for what I need the tool for. Since it was a real pain to downgrade I haven't tried newer versions since. Maybe it's fixed, I don't know and I have no desire to find out.
Regarding the colours, I personally like them, but the configuration [0] options look fairly thorough so perhaps its worth checking those out?
[0]: https://github.com/jesseduffield/lazygit/blob/master/docs/Co...
His other project, lazy docker, is also handy for dealing with collections of docker services.
- Turn on "lynx like navigation" in "Panel options". Allows you to move around real quick when you're traversing a bunch of directories. - SFTP/FTP mode, where you can mount a remote FS like it was local (in case you need to selectively copy files).