very nice, lovely tui. Does it support viewing the diff of unstaged files? I tend to do a lot of commit amending locally so would be nice if I could see the status of these before I amend the commit
Now it defaults to comparing current branch vs `main` for PR review, but I will definitely see the value in a `local changes` mode for pre-commit checks!
This doesn’t sound like a “you might not need tmux” argument. It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true. But the workarounds described are just reimplementing tmux features by taping together a bunch of tools. A better argument I think is - a lot of people do need tmux, so perhaps we should rethink protocols etc to make many of these features more native
At one point I was wondering if there was a preexisting protocol for a character-based framebuffer of some sort, that we could then use to slice the problem in a different way: a framebuffer multipliexer running terminal emulators inside it instead of a terminal multiplexer emulating multiple terminals into a framebuffer and then translating it back into terminal controls for the parent.
Unfortunately, my conclusion was that the only independent character-based terminal tradition is IBM’s 3270 stuff, but even setting aside IBM weirdness it’s simply not that. (Yes, there’s also such a protocol within tmux but it’s not really compatible with anything else.)
> It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true.
Start thinking of tmux, screen, ssh, etc as terminal emulators, and everything will suddenly make sense.
> perhaps we should rethink protocols etc to make many of these features more native
I've been opposing terminal emulators (NOTE: emulators, not REPLs) for a long while. I also do believe we can collectively do better than emulating 1970s hardware. I do believe we can build applications where "ctrl-c" means copy, and selecting more than one screen's worth of text is possible. It's not hard, we're just stubborn.
nitpick: ctrl-c never meant copy until windows started to dominate. it didn't even mean that in DOS. selecting more than one screens worth of text is possible in gui terminals and also in tmux.
but i agree with your general point: we can collectively do better than emulating 1970s hardware
Nit: didn’t Ctrl-X/C/V come from the original Macintosh? I thought Windows initially followed IBM’s CUA, where cut / copy / paste are instead Shift-Delete / Ctrl-Insert / Shift-Insert (and those still work too).
The original Macintosh had Command-X/C/V, and Windows 3.0 adopted that in addition to the existing CUA shortcuts, but changed Command to Control, as Alt was already in use for menus and form control shortcuts on Windows. So it’s true that Ctrl+C for Copy only became a thing with Windows.
Apple provided a new modifier key (Command, or ⌘) for our GUI shell. Or Open Apple/Closed Apple if you go back to the Apple II days. Control still works like it should.
Microsoft said "Hey that's useful, but we don't make hardware, and we don't have a Command key, so let's break things and reuse Control in our copycat GUI, and ignore all of the historical uses of control characters. What could go wrong?"
And then Linux (Gnome??) said "Hey we don't make hardware either, let's do what Microsoft did, because lots of people are familiar with it, and even though the historical uses of control characters are really important on Unix-like operating systems."
you are right, apple didn't clobber ctrl-c and i should have realized that (facepalm). it IS microsofts fault. makes one wish microsoft started making keyboards earlier. maybe we would have gotten that command key everywhere.
on the linux end we didn't really have much choice then. we wanted to get people to switch from windows.
but technically, neither microsoft now linux clobbered ctrl-c in the terminal. if i remember ctrl-c does not work to select text in a DOS window, and it does not on a linux terminal either.
TIL from this talk: https://youtu.be/ajfb5LSbQVM that all the control keys that we still use today have a corresponding encoding in ASCII: https://en.wikipedia.org/wiki/Control_character#In_ASCII and that the control-keys were designed to emit those characters. i kind of implicitly knew that, but never made the direct connection, especially that it was ASCII that defined which control key would be assigned to which control character.
> nitpick: ctrl-c never meant copy until windows started to dominate. it didn't even mean that in DOS.
VT102 wasn't designed with multiplexing in mind. The device was meant as a primary way to interact with a computer, not to perform the tasks of one - your physical keyboard also doesn't understand "copy".
> selecting more than one screens worth of text is possible in gui terminals and also in tmux.
It is but it isn't. You want to copy a multiline snippet of code you just wrote, you will have to manually strip away $PS1 & $PS2. You want to copy from vi into another window, you can't use the mouse - and you have to use a side channel.
I have 20+ unfixable issues outlined, and I'm in the process of writing a blog post... But at my current rate, it could become a book.
ok, yes, i was just talking about the simple case. you are right that the issue is more complicated, so i actually agree with you. i am talking about similar problems here: https://news.ycombinator.com/item?id=44757142
i am looking forward to your post. i added your blog to my rss reader
I've built a standalone PoC REPL with an inferior process as a uni student (2010), it was ca 200 lines of Python and Tk. Stuff you get for free: text selection, copy/paste, multiline editing, proportional fonts, etc. It's not a hard problem, but there seems to be little collective interest to push such efforts forward.
The best idea I've seen so far is Swift Playgrounds. You get a text editor, start writing a script, run it at your own convenience, standard stuff. The good stuff is, it takes a snapshot of the running process at every line, and allows you to travel back in time, inspect the state in a debugger, and rerun from any single point. When you hit run, it restarts from the first new line, so you never pay the upfront cost of a prior heavy computation.
You get every benefit of a REPL, plus every benefit of a simple IDE, plus a time travelling debugger, plus vertical integration.
I recently spent a weekend building this fun little project when a friend and I were comparing legacy codebases we'd worked on. I had the sudden idea that it would be funny to compile old TODO comments to see who else procrastinates tech debt as much as some we've seen.
The site is pretty slow; namely cloning and git blaming on repos with a large git history is naturally slow. If anyone has any fun hacks to make this more efficient - the code for this is open source!
https://github.com/rupert648/willdolater.dev
reply