The main complaint was having to dig through terminal tabs to find your vim and not being able to Alt+Tab to it. Surely just detaching that single tab would work just fine? Their solution seems to add a lot of complexity for not much benefit...
This is more about “Cmd+Tab” on app-oriented desktops like macOS or gnome. In these environments, cmd+tab will switch applications, not just windows, and this person wants neovim to be there alongside whatever other apps they run (eg safari, Finder).
There’s a similar problem where some people don’t like to search for email or chat tabs, so they install a “native” (electron) app like teams or slack so that it acts like more than just another browser tab.
I've said it before and I will say it every chance I get: TUIs are poorly disguised GUIs, and the whole premise of TFA seems to be here to support this notion.
If you want to integrate your TUI program more tightly with the terminal emulator it's running in, how about you rip out those half a dozen layers of abstraction and indirection and compatibility with half-a-century-old hardware that nobody produces anymore, that sit in between your program's display logic and the actual pixels on the screen? You can keep the grid-of-characters display style, but e.g.:
- implement text selection that works in sub-frames
- give your program an icon
- support key combos like Ctrl+Shift+F
- display an inline picture
...all while removing hundreds, probably thousands of lines of code.
TUIs have conventions that grant them high usability and accessibility.
GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.
That said, yes, without a doubt you can make a GUI that is as usable as a random TUI. You can even make it work well over ssh. And even get shorter code after it's done. You will just have a hard time communicating you did that to people.
> GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.
Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are:
- It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator)
- The API is simple and stupid (paint a character here)
- There's only this many things you can do, so you don't over-engineer your UI
- Accessibility. Screen readers are guaranteed to work (but lack a11y context)
I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.
> I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage.
The baggage may be unnecessary, but I think the key to the success of TUIs is that the terminal’s interaction mechanism is restrictive. To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. You might end up with something better, but I think it will be very reminiscent of current terminal emulators.
> To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of.
I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator.
Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc).
I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.
I think my ideal terminal emulator would be HTML based. Programs would output HTML, with some special extra tags. If you want a UI, serve a web interface on a random port and embed it in an iframe.
You could make app launchers with links that run other apps, and even non terminal people would want to use it.
> Accessibility. Screen readers are guaranteed to work
I wonder how useful screen readers are in curses-style applications (I don't have any experience with screen readers)? Sure, it can probably read it, but applications like this is essentially just a screenful soup of character blocks. It sounds like it'd make for a very tedious screen reading experience.
Correct. There's no additional context for the reader. There's blind people who are pretty good at Nethack. Once you're stuck with a character soup you might as well fully embrace it.
How would you make the GUI work well over SSH, unless you mean having the GUI installed on the client device and only connecting to the host over SSH?
A huge part of why I keep my workflow 100% terminal / TUI is because I know I can use anything with a solid shell (even my iPad or my phone) and instantly have my full workflow exactly where I left off with every single program looking and working exactly the same in exactly the same state.
If I was only running neovim, this wouldn't make much sense. However, I can use this method for any command line application. Since it's essentially just re-using my existing terminal, I can also re-use as much of my terminal emulator configuration as I'd like. I can also rely on the known performance characteristics of my terminal emulator. In particular, a number of the Neovim GUIs are energy hogs (either due to some unoptimized thing that uses a lot of CPU or the specific method that is used for rendering on the GPU).
The other nice thing is that when I want to run Neovim, I start an app called Neovim. Not FNvim or Neovide or glrnvim or any of those other things. Neovim. It's a closer match to my intent and I don't have to try to remember some weird app name when I just want to edit code.
> I can use this method for any command line application
Which apps do you use actually it for?
> when I want to run Neovim, I start an app called Neovim
That's what aliases are for (or you could rename the binary?)! Or you could just bind it to shortcut+E for Edit and forget the name of the editor as you'd never type it
The last trick could also solve the Cmd+Tab issue as you could set it up to open the in-terminal-editor, and it'll always be faster vs tabbing
> That's what aliases are for (or you could rename the binary?)!
Unfortunately, it's not that simple on macOS for app bundles. The human readable name of the app bundle really doesn't matter that much to the operating system -- it's the contents of Info.plist that matter. In order to have a separate app that can be Cmd+Tab'd to, you have to have a separate app bundle, separate app bundle identifier, etc. There's really not a way around it on macOS that I've seen.
(And to be clear, aliases do work on the command line. I'm talking specifically about GUI apps - which is my primary method of separating my different activities. Terminal emulator tabs are not good enough.)
This also doesn't solve the performance problems with any of the various GUI applications, nor does it solve my problem for other applications that I want to run.
I do! I tried this route first, but it falls apart when you start a GUI application from the script that you supply to platypus. If your script is e.g. `wezterm start`, it'll just start up another instance of a wezterm-branded GUI app in addition to the wrapper app that Platypus spits out.
> In order to have a separate app that can be Cmd+Tab'd to, you have to have a separate app bundle, separate app bundle identifier, etc.
I meant you could edit the existing bundle for, e.g., FNvim, and change it's bundle id/name/icon to whatever you want instead of having to re-create a bundle for a weztermed neovim
(aliases would only work for the launching part)
I also like the fact that it's hard to build a terminal application that needs a mouse. I don't want to touch a mouse if I can avoid it, so I run them. A personal computer is too powerful to operate with a single finger.
There's the low resource aspect too. Sure, you can build a TUI that hogs resources, but there's a culture of not doing it, and it's harder to do it even if you try. Contrast that to modern GUI software where it's like the developers look at the minimum requirements as a speed limit, that is, the bare minimum you have to use.
>A personal computer is too powerful to operate with a single finger.
You might've forgotten due to no use, but mice don't use only 1 finger, and they don't prevent keyboard use either.
The comparison to some general GUI state also doesn't make sense - that class of software is miles ahead of the TUI in terms of functionality, so you'd need to limit the comparison to apps that are functionally similar
I've found that with keyboard oriented interfaces the TUIs are as or more functional than GUI apps.
And sure, having a mouse doesn't preclude you from using a keyboard, but GUI applications are so mouse focused it's impossible to use most of them without a mouse. The 1 finger comment was hyperbole, but it's close enough to true.
I use various buttons and wheels and gestures and click sequences (LR switch tab left, RL switch tab right) and buttons-as-modifiers on a mouse, so not even remotely close
The other point is repeating the same generalization mistake, "most of them" don't even exist in a TUI form, and the level of keyboard customization for keyboard focused interface is often pretty lackluster in a TUI (terminal text editors famous for their customization can't differentiate between left and right modifiers and it's harder to fix that with an external utility because, guess what, it's not a separate app, so usual app detection fails!)
> Kitty also had a command line flag to allow setting the window class
That's quite fortunate/fortuiutous and makes for a nifty shortcut that works so well. Is this common for all terminals, eg does gnome-terminal have a --class that would let it slot in to this .desktop setup?
Tbh the Mac version looks a bit too involved and hinges on or works around specific behaviors, I'm not sure I'd want to go that far as it then ventures into the territory of 'maintenance'.
I use X window classes to differentiate between all of my Firefox instances. No idea if Wayland even supports the idea of window classes (so that I can raise the instance I need with a single hotkey), but if not that’s yet another blocker for me.
No I mean, opening a terminal window with a program running in it. Pipe the command to the terminal when you run the terminal. I do this for TUI apps on my Sway desktop, just put some bash scripts with a single line in them, they're my shortcuts so I can run them from my menu.
I've done this for a few years as well. I use a terminal+tmux for most work including quickly editing files here and there but for some reason when I get to "proper" focus-mode programming my brain just wants a separate "application" to look at. And usually the terminal is on my secondary monitor while the "editor" terminal is full-screen on the main monitor.
I used to gvim but realized that I was getting almost no benefit (and occasionally the differences between gvim and my terminal caused minor annoyances).
Two things I do that help in this regard:
I use a tweaked config for the "editor" instance of the terminal that has a slightly different background color from my main terminal. This keeps them separate in my mind.
I use dedicated shortcuts for focusing each application I use (browser, terminal, slack, etc) and the "editor" terminal has its own shortcut. (The --class flag that the post mentions kitty has would be pretty helpful in this regard. My terminal doesn't have that so my shortcuts are based on title, which works well enough most of the time.)
I went through a phase like this a long time ago. Mobile kills the entire idea. Sure, you can get Termux or an ssh client going but then what? It's not like Mutt has a hidden touch friendly interface implemented through vt100 codes.
The modern 2023 guide would be discussing how to spawn PWA/webapp windows and integrate them like Android and ChromeOS.
I'm not sure why mobile kills this idea or why it even matters. I'm not going to be running neovim or mutt on my mobile device because I don't often use a mobile device to write a substantial amount of code or do anything beyond surface-level email triage.
The next version of Safari has the idea of installable web apps on macOS. Chrome has had that functionality available for years. There are also a number of third party apps for macOS that handle creating app bundles that essentially just run web views (e.g. Fluid, Bulldock Browser, etc).
My terminal emulator has tabs and splits and saved sessions already. That doesn’t really solve the problem though. I want something that I can cmd+tab to and not dig through a pile of tabs.
I auto rename the tab to the program that is running currently. So visually scan the window list for vim, then hit the prefix followed by the number of the window.
But if you really need alt-tab, I can see why this won't work (unless you manage to integrate tmux windows into your window manager).
The main complaint was having to dig through terminal tabs to find your vim and not being able to Alt+Tab to it. Surely just detaching that single tab would work just fine? Their solution seems to add a lot of complexity for not much benefit...