5 ms·

The obsession is because it is still the best. For all its faults, I'm still terminally terminal. The beauty of it is in the utility and how it becomes so natur

The obsession is because it is still the best. For all its faults, I'm still terminally terminal. The beauty of it is in the utility and how it becomes so natural. It's a language you learn that gives you so much freedom you cannot find anywhere else. I've tried many IDEs but I'll always come back to vim. It might have taken time to learn but this is true for anything else. I didn't learn a tool, I learned a language. I didn't learn to run, I learned how to move my legs. With that I could teach myself, I can walk, I can run, I can jump, I can dance, I can be anything I want to be. In VSCode I can walk, hell I might even be able to run, but there is no dance, there is no "me". That's the beauty of the terminal. It's not a one size tool for all. There is no product that can be made for everyone. Instead it's an environment for you to craft and live in. Everyone's dotfiles are as unique as they themselves are. That's the point. Because when you can't build something for everybody you give them the means to craft their own worlds. The computer didn't become so great because the chips, it was the ability to write software and build the things you need. The smartphone didn't take off because it had a big screen, it did because the app. Because you could create. Because your phone is yours and no other phone is like it. But I haven't found a browser that lets me be me. That let's me dance around the web and jump and be free. And I fear we lost sight of this thing as it became so natural, that the phone and computer are turning into things that be instead of a reflection of me

wiseowise 2y ago
GP talks about how you develop those TUIs, not TUIs themselves. Web model is objectively better than ‘’’ Stop thinking in standard CSS units like px, em, rem, % Start thinking in Character Cells for spacing, sizing, and positioning ‘’’
- freehorse 2y ago
  It is a different design decision. You do not have to choose all capabilities of modern browsers when you do sth. Of course nobody would expect this to take off largely. But aesthetically speaking, I see nothing wrong in the design per se. It is clean, consistent, light and minimalist-like. Terminals just provide a minimalist style that is tested and also familiar to some. It is very easy to get around the website. Pages load fast. The main drawback I see is lack of multimedia support, obviously (even if supported they would be a bit out of style). But that's not a problem if you do not care about that. And that it is hard to place ads. Sure, "Web model is objectively better" but also depends what one considers as "web model" because a lot of modern web is just a bloated mess, which I find more annoying thaν a project like this.
- rollcat 2y ago
  > Web model is objectively better than [...] Hard disagree. Modern web browsers are incredibly complex beasts that evolved by amalgamating decades of experimentation, poor non-standards, and elaborate counter-measures to fix that mess. I recommend reading <https://browser.engineering https://browser.engineering>, or even just building Chromium from source, to gain some appreciation. Most applications would benefit from something much simpler. But it's often practical to use as it is, pretty much exactly like terminal emulators. The main difference being, terminal emulators are still several orders of magnitude less complex than web browsers, but in spite of that still require a lot of complexity to undo the side-effects of having a serial line between the CPU and the character grid. If you like monospaced fonts and character grids, you can probably render that with plain SDL, bitmap fonts with indexed sprite sheets (no Freetype), and in return get non-broken copy & paste, or even a dock icon. You know, the MVP of GUI. Try <https://lite-xl.com https://lite-xl.com>, it builds its GUI straight on top of SDL.
  - troupo 2y ago
    > If you like monospaced fonts and character grids, you can probably render that with plain SDL You don't even need SDL https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm
    - rollcat 2y ago
      Interesting project, but you still need to hook it up to a backend to create a window to draw pixels on. SDL is likely the most portable library to do that; you could substitute fbdev, DirectX, wgpu, glfw, win32, metal, and so on. The point is, once you have a window and a putpixel (or even better, surfaces and blitting), the rest is easy to handcraft. A standardised library would of course help.
rollcat 2y ago
> I've tried many IDEs but I'll always come back to vim. Vim and Emacs both have GUIs. As an Emacs user, I subjectively find the GUI superior - I can e.g. rebind Cmd-S to "save", and that's a reason enough. > It's a language you learn [...] You mean the serial lines and ANSI escape codes and termcap? I would say it's more like pidgin with a dozen obscure dialects, and a body language on top. Try writing a portable TUI application from scratch, without touching curses or termbox. <https://viewsourcecode.org/snaptoken/kilo/ https://viewsourcecode.org/snaptoken/kilo/> Or do you mean, how to drive a TUI application from the keyboard? Here's the painful truth: you can't quit a TUI application without learning it. In vi, it's "Esc-q!-Enter", in Emacs it's "C-x C-c", in screen it's "C-a C-\", in tmux it's "C-a C-d", and so on. Maybe pressing "q" or F10 or C-d will work, but good luck guessing. This is just to quit, and ironically - it's only the start. By contrast, on macOS it's Cmd-Q; on Windows, it's Alt-F4; and so on. Innovation happens on stable foundations, not by pulling rugs. > It's not a one size tool for all. There is no product that can be made for everyone. [...] Everyone's dotfiles are as unique as they themselves are. You know non-TUI applications are also customisable? I have Hammerspoon scripts, a dozen custom keybindings in macOS, .xsession+.Xdefaults+.Xresources, .gitconfig (I use git via Emacs+Magit), various .config/*'s (for e.g. sway), .emacs (bankrupted several times), and so on - none of these are TUI applications. Or do you mean the command line? I believe we can build a better REPL than a terminal emulator. Emacs is a decent PoC, you can also have a look at Swift Playgrounds. Maybe we can build a generic non-terminal REPL where Ctrl-C means "copy", and Ctrl-V means "paste", that would be a great start. Don't get me wrong, I'm happy if you're happy, I just don't understand the collective obsession. These tools exist, which is great, but we deserve better.
- dullcrisp 2y ago
  Hmm I just use :w<cr> to save in my graphical editors too. It’s easier to type.
  - __float 2y ago
    No, it's objectively more difficult to type [on a qwerty keyboard]. cmd-s is a single keypress and can be done with a single hand. shift-; w cr is two more and involves a back and forth over the entire keyboard.
freddie_mercury 2y ago
If it is still the best, what's the superior terminal equivalent for Photoshop, Premiere, Audacity, and Figma? Not everyone's work life revolves around text just because yours does.
- tomxor 2y ago
  > Not everyone's work life revolves around GUIs just because yours does. FTFY They both have their place, pros and cons, that fit different purposes differently. The mistake is in trying to assign superlatives. Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs, but in different contexts.
  - rollcat 2y ago
    > Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs. TUIs are GUIs - in a trench coat. A TUI program must still process input events, draw widgets, manage state & focus, etc - all the things a GUI must do. What OTOH it can't do, is even the most basic stuff, like system clipboard or displaying pictures. You have to use side channels to get that, and once you do, you throw away the TUI's one single advantage - SSH.
    - bhaak 2y ago
      But the original terminal was also already using a side channel. You used them to connect to a remote piece of hardware and weren’t running anything locally. In that sense ssh itself is also a side channel. I also don’t know why you consider manipulating the system clipboard a side channel. The terminal emulator provides a way of manipulating the clipboard but that is just convenience. Any program can access the clipboard and a TUI program can do this as well. I have a grepalike that inserts a search match into the clipboard for convience. Somewhat ironically most of the time that match gets pasted back into the terminal. I would actually like to have a network wide clipboard system. There are solution for that but I haven’t yet found any that isn’t too unwieldy.
      - 2y ago
sgarland 2y ago
What a lovely sentiment. Fully agree; staying in the terminal for as much as possible makes for far less friction when context-switching.
- jampekka 2y ago
  Text-based interfaces can be done with techniques other than simulating a very restricted device from 1978.
  - godelski 2y ago
    If your terminal is from the 70's you really should get with the times. Check out ghostty or something because things are very different these days
    - jampekka 2y ago
      Ghostty seems to support a subset of the xterm protocol. Sure, a bit more advanced than VT100, but still it still is, as the ghostty dev puts it, "very often touted as the gold standard for historical terminal behavior." https://mitchellh.com/writing/ghostty-devlog-005 https://mitchellh.com/writing/ghostty-devlog-005
      - godelski 2y ago
        I think you're reading things with the intent to support your conclusion rather than with intent to understand what is being communicated. Including the basic fact that xterm is itself an improvement upon VT100. Ghostty matching and supporting xterm protocol is different than it /being/ xterm and thus /being/ functionally identical to your 70's terminal. Of course it needs to be able to support this protocol because why would someone building a terminal emulator build something that is going to break as soon as you touch something that tries to communicate via an xterm protocol? There's a reason there's that ssh stuff at the end. Are you going to criticize a browser for supporting html and css? But I don't get your point here. Why would that even matter? You're hyper fixating on the similarity to the 70's terminal while blatantly ignoring everything that is different. Does your 70's terminal: - Support tabs? - Support panes? - Handle mouse clicks? - Support non-ansii fonts? - Colors? - Ligatures? - Glyphs and Icons? Emojis? - Support asian language input? - Use GPU acceleration? - Support shaders? - Render high resolution images? - Render the terminal at hundreds or thousands of fps? Your 70's terminal can't even do window resizing, let alone accurately render that. Then comparing it to something that realistically could run 4k videos in it. Go look at the notcurses demo[0]. I'd love to see your 70's terminal do anything close to that. I mean what do you want? In my terminal I can write my code, have full color support, view PDFs, view high resolution images, and do all this without really putting any meaningful stress on my system. I can have a bunch of tabs open viewing code, pdfs, images, several instances of gdb and still be using less CPU and memory than if I just open VSCode. So what point are you trying to make? That I interact with you program mainly with the keyboard and that despite being able to use my mouse I choose not to? Or are you just mad at the aesthetics? Or that people haven't exploited the previously mentioned capabilities to build cooler things? Honestly, I do not understand what point you are trying to make. [0] https://notcurses.com/ https://notcurses.com/

wiseowise 2y ago

GP talks about how you develop those TUIs, not TUIs themselves. Web model is objectively better than ‘’’ Stop thinking in standard CSS units like px, em, rem, % Start thinking in Character Cells for spacing, sizing, and positioning ‘’’

freehorse 2y ago
It is a different design decision. You do not have to choose all capabilities of modern browsers when you do sth. Of course nobody would expect this to take off largely. But aesthetically speaking, I see nothing wrong in the design per se. It is clean, consistent, light and minimalist-like. Terminals just provide a minimalist style that is tested and also familiar to some. It is very easy to get around the website. Pages load fast. The main drawback I see is lack of multimedia support, obviously (even if supported they would be a bit out of style). But that's not a problem if you do not care about that. And that it is hard to place ads. Sure, "Web model is objectively better" but also depends what one considers as "web model" because a lot of modern web is just a bloated mess, which I find more annoying thaν a project like this.
rollcat 2y ago
> Web model is objectively better than [...] Hard disagree. Modern web browsers are incredibly complex beasts that evolved by amalgamating decades of experimentation, poor non-standards, and elaborate counter-measures to fix that mess. I recommend reading <https://browser.engineering https://browser.engineering>, or even just building Chromium from source, to gain some appreciation. Most applications would benefit from something much simpler. But it's often practical to use as it is, pretty much exactly like terminal emulators. The main difference being, terminal emulators are still several orders of magnitude less complex than web browsers, but in spite of that still require a lot of complexity to undo the side-effects of having a serial line between the CPU and the character grid. If you like monospaced fonts and character grids, you can probably render that with plain SDL, bitmap fonts with indexed sprite sheets (no Freetype), and in return get non-broken copy & paste, or even a dock icon. You know, the MVP of GUI. Try <https://lite-xl.com https://lite-xl.com>, it builds its GUI straight on top of SDL.
- troupo 2y ago
  > If you like monospaced fonts and character grids, you can probably render that with plain SDL You don't even need SDL https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm
  - rollcat 2y ago
    Interesting project, but you still need to hook it up to a backend to create a window to draw pixels on. SDL is likely the most portable library to do that; you could substitute fbdev, DirectX, wgpu, glfw, win32, metal, and so on. The point is, once you have a window and a putpixel (or even better, surfaces and blitting), the rest is easy to handcraft. A standardised library would of course help.

rollcat 2y ago

> I've tried many IDEs but I'll always come back to vim. Vim and Emacs both have GUIs. As an Emacs user, I subjectively find the GUI superior - I can e.g. rebind Cmd-S to "save", and that's a reason enough. > It's a language you learn [...] You mean the serial lines and ANSI escape codes and termcap? I would say it's more like pidgin with a dozen obscure dialects, and a body language on top. Try writing a portable TUI application from scratch, without touching curses or termbox. <https://viewsourcecode.org/snaptoken/kilo/ https://viewsourcecode.org/snaptoken/kilo/> Or do you mean, how to drive a TUI application from the keyboard? Here's the painful truth: you can't quit a TUI application without learning it. In vi, it's "Esc-q!-Enter", in Emacs it's "C-x C-c", in screen it's "C-a C-\", in tmux it's "C-a C-d", and so on. Maybe pressing "q" or F10 or C-d will work, but good luck guessing. This is just to quit, and ironically - it's only the start. By contrast, on macOS it's Cmd-Q; on Windows, it's Alt-F4; and so on. Innovation happens on stable foundations, not by pulling rugs. > It's not a one size tool for all. There is no product that can be made for everyone. [...] Everyone's dotfiles are as unique as they themselves are. You know non-TUI applications are also customisable? I have Hammerspoon scripts, a dozen custom keybindings in macOS, .xsession+.Xdefaults+.Xresources, .gitconfig (I use git via Emacs+Magit), various .config/*'s (for e.g. sway), .emacs (bankrupted several times), and so on - none of these are TUI applications. Or do you mean the command line? I believe we can build a better REPL than a terminal emulator. Emacs is a decent PoC, you can also have a look at Swift Playgrounds. Maybe we can build a generic non-terminal REPL where Ctrl-C means "copy", and Ctrl-V means "paste", that would be a great start. Don't get me wrong, I'm happy if you're happy, I just don't understand the collective obsession. These tools exist, which is great, but we deserve better.

dullcrisp 2y ago
Hmm I just use :w<cr> to save in my graphical editors too. It’s easier to type.
- __float 2y ago
  No, it's objectively more difficult to type [on a qwerty keyboard]. cmd-s is a single keypress and can be done with a single hand. shift-; w cr is two more and involves a back and forth over the entire keyboard.

freddie_mercury 2y ago

If it is still the best, what's the superior terminal equivalent for Photoshop, Premiere, Audacity, and Figma? Not everyone's work life revolves around text just because yours does.

tomxor 2y ago
> Not everyone's work life revolves around GUIs just because yours does. FTFY They both have their place, pros and cons, that fit different purposes differently. The mistake is in trying to assign superlatives. Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs, but in different contexts.
- rollcat 2y ago
  > Two things can be true at the same time, TUIs are superior to GUIs, and GUIs are superior to TUIs. TUIs are GUIs - in a trench coat. A TUI program must still process input events, draw widgets, manage state & focus, etc - all the things a GUI must do. What OTOH it can't do, is even the most basic stuff, like system clipboard or displaying pictures. You have to use side channels to get that, and once you do, you throw away the TUI's one single advantage - SSH.
  - bhaak 2y ago
    But the original terminal was also already using a side channel. You used them to connect to a remote piece of hardware and weren’t running anything locally. In that sense ssh itself is also a side channel. I also don’t know why you consider manipulating the system clipboard a side channel. The terminal emulator provides a way of manipulating the clipboard but that is just convenience. Any program can access the clipboard and a TUI program can do this as well. I have a grepalike that inserts a search match into the clipboard for convience. Somewhat ironically most of the time that match gets pasted back into the terminal. I would actually like to have a network wide clipboard system. There are solution for that but I haven’t yet found any that isn’t too unwieldy.
    - 2y ago

sgarland 2y ago

What a lovely sentiment. Fully agree; staying in the terminal for as much as possible makes for far less friction when context-switching.

jampekka 2y ago
Text-based interfaces can be done with techniques other than simulating a very restricted device from 1978.
- godelski 2y ago
  If your terminal is from the 70's you really should get with the times. Check out ghostty or something because things are very different these days
  - jampekka 2y ago
    Ghostty seems to support a subset of the xterm protocol. Sure, a bit more advanced than VT100, but still it still is, as the ghostty dev puts it, "very often touted as the gold standard for historical terminal behavior." https://mitchellh.com/writing/ghostty-devlog-005 https://mitchellh.com/writing/ghostty-devlog-005
    - godelski 2y ago
      I think you're reading things with the intent to support your conclusion rather than with intent to understand what is being communicated. Including the basic fact that xterm is itself an improvement upon VT100. Ghostty matching and supporting xterm protocol is different than it /being/ xterm and thus /being/ functionally identical to your 70's terminal. Of course it needs to be able to support this protocol because why would someone building a terminal emulator build something that is going to break as soon as you touch something that tries to communicate via an xterm protocol? There's a reason there's that ssh stuff at the end. Are you going to criticize a browser for supporting html and css? But I don't get your point here. Why would that even matter? You're hyper fixating on the similarity to the 70's terminal while blatantly ignoring everything that is different. Does your 70's terminal: - Support tabs? - Support panes? - Handle mouse clicks? - Support non-ansii fonts? - Colors? - Ligatures? - Glyphs and Icons? Emojis? - Support asian language input? - Use GPU acceleration? - Support shaders? - Render high resolution images? - Render the terminal at hundreds or thousands of fps? Your 70's terminal can't even do window resizing, let alone accurately render that. Then comparing it to something that realistically could run 4k videos in it. Go look at the notcurses demo[0]. I'd love to see your 70's terminal do anything close to that. I mean what do you want? In my terminal I can write my code, have full color support, view PDFs, view high resolution images, and do all this without really putting any meaningful stress on my system. I can have a bunch of tabs open viewing code, pdfs, images, several instances of gdb and still be using less CPU and memory than if I just open VSCode. So what point are you trying to make? That I interact with you program mainly with the keyboard and that despite being able to use my mouse I choose not to? Or are you just mad at the aesthetics? Or that people haven't exploited the previously mentioned capabilities to build cooler things? Honestly, I do not understand what point you are trying to make. [0] https://notcurses.com/ https://notcurses.com/