21–30 of 124 posts
`diff --color=auto` is nice, but `vimdiff` is superior
diff -u a.txt b.txt | colordiffEarlier quoted context omitted.
I kinda like using tooling with 40 years of refinement. Is it perfect? No. Do I need to resize a window with a progress bar? No. Would it be nice? Yeah, I guess. Am I underestimating the benefits? Almost certainly. But what are the other sharp edges that come with the shiny new thing? Would it be an electron app? Yes, probably. Would it work? Maybe, in a couple years. There would be some major bugs first, and a lot o…
It looks to me that the reality is closer to "40 years of hack over something that was not meant to be a standard (a popular hardware terminal from the 80s)". I'll give you just one example of the madness that is sometimes required: the escape code \e[1m is doing "bold on". It's counterpart to reset \e[21m, is supposed to do "bold off", but in practice some terminals do "double underline" instead because this standar…
This means that it’s difficult to write a flashy app with bold text, links and images.
I like programs with minimal text ui, so I don’t mind.
Earlier quoted context omitted.
It looks to me that the reality is closer to "40 years of hack over something that was not meant to be a standard (a popular hardware terminal from the 80s)". I'll give you just one example of the madness that is sometimes required: the escape code \e[1m is doing "bold on". It's counterpart to reset \e[21m, is supposed to do "bold off", but in practice some terminals do "double underline" instead because this standar…
I’d say all this is a feature. This means that it’s difficult to write a flashy app with bold text, links and images. I like programs with minimal text ui, so I don’t mind.
I feel like we need a complete rewrite of terminal emulators/bash/whatever. It should be super easy to make a CLI with nice colors, good loading icons, etc. without having to deal with all kinds of color codes and cursor movement. When I press "enter" while a script is showing some progress bar, or resize the terminal window, it should handle it nicely like every other application. I use the command line whenever pos…
> I feel like we need a complete rewrite of terminal emulators/bash/whatever. A complete rewrite would be an opportunity to overlook important ideas, compromise on goals and make design mistakes. I’d strongly prefer slow, iterative approach here.
I'm inclined to "if it ain't broke don't fix it", but it's also just as true that this greedy algorithm just leaves us at a local optima.
`diff --color=auto` is nice, but `vimdiff` is superior
There is also `colordiff` which works both as a standalone diff tool, but also as a colorizer filter for other diff tools. For example: diff -u a.txt b.txt | colordiff
I use the following config.
[core]
pager = /usr/share/git-core/contrib/diff-highlight | less
[color "diff-highlight"]
oldNormal = red
oldHighlight = 16 bold red
newNormal = green
newHighlight = 16 bold greenI feel like we need a complete rewrite of terminal emulators/bash/whatever. It should be super easy to make a CLI with nice colors, good loading icons, etc. without having to deal with all kinds of color codes and cursor movement. When I press "enter" while a script is showing some progress bar, or resize the terminal window, it should handle it nicely like every other application. I use the command line whenever pos…
I kinda like using tooling with 40 years of refinement. Is it perfect? No. Do I need to resize a window with a progress bar? No. Would it be nice? Yeah, I guess. Am I underestimating the benefits? Almost certainly. But what are the other sharp edges that come with the shiny new thing? Would it be an electron app? Yes, probably. Would it work? Maybe, in a couple years. There would be some major bugs first, and a lot o…
1. You can't have an interactive program in a pipeline. For example, you can't do `gpg --decrypt foo.txt.gpg | nano | gpg --encrypt` because keyboard input on the console is handled through stdin. You can work around this by using a graphical editor in the pipeline, but this should be possible entirely over the command line.
2. You can't have hotkeys that are just modifier keys because the modifier keys only change the byte sent when pressing another key. So could couldn't have a hotkey "Shift" but you can have a hotkey "Shift-n".
3. How do you tell the difference between an escape sequence and the escape key? Escape sequences start with exactly the same byte used by the escape key
4. While we have escape sequences to move the cursor and detect the cursor location, in order to find dimensions of the terminal we have to resort to an ioctl.
5. Termcap. Because we can't assume some standard set of terminal features, and since my FreeBSD servers don't have a termcap file for alacritty, when I ssh into my FreeBSD servers my backspace key doesn't work (along with a lot of other things).
6. This ones a bit optional, but it would be nice to have a standard protocol for telling the terminal to render an image.
7. Abruptly killing a program that has put the terminal into raw mode leaves your terminal in raw mode.
What would I do to fix this:
1. Move keyboard input to a different file handle than pipes. This would require software to be patched, or at least a compatibility layer written to merge the pipes for legacy software.
2. Remap all the keyboard bytes. Every key press and every key up sends data to the keyboard input stream. Let the program maintain a keyup/keydown state map for handling modifier keys. This would require software to be patched or at least a compatibility layer written to remap the bytes.
3. As part of the new encoding for #2, we should make a better encoding for input. The current system seems a lot more "grown" than designed. I'd love to see something similar to UTF-8 where we get to encode a variable-length integer with the benefits of indicating byte length in the first byte and being able to detect if we're in a continuation byte. We could even use UTF-8 verbatim for most of the keyboard input but we'd need a special section for escape sequences like moving the cursor. I don't know enough about unicode to know if theres a section we could use for that, but worst case scenario we could use the 5 and 6-byte length utf-8 sequences that never made it to the final utf-8 spec despite being possible in the encoding.
4. As part of #3, add escape sequences to detect terminal dimensions.
5. Establish a new minimum set of features that are assumed to work, incorporating all these refinements over the past 40 years.
6. This could be part of the new encoding for #3
7. Automatically revert terminal to its original non-raw-mode state at the end of a program.
Finally, I'd recommend this blog post to appreciate how much of a mess terminal programming is: https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
Really tempted to install starship but I also do a bunch of sensitive stuff with my terminal. Should I be worried about using this? I understand it's open source, yet still not confident.
Every render of the prompt is fully stateless. Starship has no tracking, telemetry, and never calls home. :)
My friend is developing a colour palette based on Solarized:
https://github.com/jan-warchol/selenized
but with more perceptual uniformity.