I switched my Mac terminal to Warp.dev simply for the default mac text input. I can ⌥ and ⌘ left and right to select words or until the end of the line ⌘A to select all. It comes with so many other bells and whistles that I've mostly ignored for this simple convenience. I don't use emacs (or vim) keybindings in any other context and I'm not sure why the terminal forces you to.
Entering text in the terminal is complicated
191–200 of 229 posts
Re: Entering text in the terminal is complicated
#192I use M-x shell and variants in Emacs for almost all of my command line work. No problems with editing, as it is always Emacs on top. For true ncurses apps there are some limitations inside vterm or ansi term but even there, I can still use elisp and fix these problems if needed.
Re: Entering text in the terminal is complicated
#193Earlier quoted context omitted.
Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows? The Windows Command Prompt's default experience is worse than most if not all terminals you find on Linux systems. Even in play TTY, you're bound to find that the shortcuts the author mentioned work like a charm. To make my cmd.exe bearable I am using https://chrisant996.github.io/clink tl;dr You're comparin…
> Doesn't Windows, the most popular OS out there, ... The most popular desktop OS. It is nowhere to be found in the Top 500 supercomputers, is nowhere to be found on smartphones, lags in the Cloud, is nowhere to be found in the billions of appliances, etc. > Why isn't that harming Windows? It is harming Windows. That horrible cmd.exe is one of the reason Windows lost in all the other markets and has hardly any market…
Seriously.
Back in the 90's a lot of movie production was being done on the SGI IRIX computers. Jurassic Park themed ones even. Really spiffy machines with both an excellent GUI and terminal.
Cheap WIN NT boxes with nVidia GPUs on them, were seen as the beat path forward.
SGI gear is also Jurassic Park style, "Spare no expense" and was not cheap! Super expensive machines, but people got what they paid for too.
Alias, Maya were ported to Windows and off to the races right?
Nope. Unix scripting, that awesome terminal and friends made all the difference in the world.
This was true even for smaller or single person shops who would do the work in a now slower SGI because the user experience was bang on point and that meant getting the desired outcome first time no bullshit.
The minute we had nVidia drivers, Linux was in to replace the SGI machines.
And, the production community realized they could each write tools or poet tools they were good at, share and share alike (to a point) and all be in business a whole lot cheaper and faster.
That took a couple maybe few years.
The "terminal" and what can happen in one and why really does matter.
Windows Power Shell is pretty OK at this point, but it is still its own thing, not playing very nice with the other kids in the sane box.
Lol, I always thought Microsoft happening in Redmond was symbolic. It really is!
Re: Entering text in the terminal is complicated
#194> First, there’s “the baseline” – what happens if a program just accepts text by calling fgets() or whatever and doing absolutely nothing else to provide a nicer experience. [...] there are actually a few features that you get for free just from your terminal, without the program needing to do anything special at all. The things you get for free are: [...] - backspace - Ctrl+W, to delete the previous word - Ctrl+U, t…
> Does that mean that, by default, fgets() blocks until the user enters a newline Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write th…
> The terminal just happens to invisibly turn \n into \r\n.
No, it was actually done by the Unixen itself, in the part of the kernel that handled ttys: it convert '\n' to '\r\n' on writes to ttys, and '\r' to '\n' on reads from ttys. Linux only recently have moved this functionality out into the user-land layer.
Re: Entering text in the terminal is complicated
#195Earlier quoted context omitted.
> Does that mean that, by default, fgets() blocks until the user enters a newline Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write th…
> The terminal just happens to invisibly turn \n into \r\n. No, it was actually done by the Unixen itself, in the part of the kernel that handled ttys: it convert '\n' to '\r\n' on writes to ttys, and '\r' to '\n' on reads from ttys. Linux only recently have moved this functionality out into the user-land layer.
> in the part of the kernel that handled ttys
Yes, that's what I meant.
OPOST Enable implementation-defined output processing.
https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
https://github.com/torvalds/linux/blob/master/include/uapi/a...
> Linux only recently have moved this functionality out into the user-land layer.
That's certainly news to me. Numerous functions in this file allude to OPOST processing:
https://github.com/torvalds/linux/blob/master/drivers/tty/n_...
If it's not here, where did it move to?
Re: Entering text in the terminal is complicated
#196This is nice. As always, Julia's articles are always a win. Here's some stuff that's missing: Within shell scripts, you can use `stty` to change a lot of stuff about the terminal, including how it deals with inputs. You can rewire all of these defaults and behaviors. Here's an experiment I did a while ago using sh and stty: https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79... It is able to capture and unde…
> you can use `stty` to change a lot of stuff about the terminal, including how it deals with inputs
> You can rewire all of these defaults and behaviors
I've also found this article on implementing a terminal text editor to be illuminating:
https://viewsourcecode.org/snaptoken/kilo/
https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
Also, just in case anyone is wondering, as I once did, where many of these magical-looking stty parameters and symbols are coming from: they are control sequences defined a long time ago. A lot of stuff is defined in ambiguous old standards from the 70s such as ECMA-48 that include such arcane terminology not seen anywhere else.
For example, jargon like Select Graphic Rendition basically refers to a 70s version of the HTML tag.
SGRTextSGR
Text
ESC[38;2;R;G;BmTextESC[0m
Text
ESC = The literal ASCII escape character
ESC[ = CSI = Control Sequence Introducer
m = SGR = Select Graphic Rendition
38 = Set foreground color
2 = Use the RGB color space
RGB = Color
0 = Reset style back to defaults
They even had the same implementation issues we have today with browsers. Terminals were and stil are inconsistent in what they implemented and how they did it. Stuff like colors is pretty well supported but many other features aren't. For example, SGR is supposed to enable "negative image" mode, whatever that is. Standard doesn't really explain. Some terminals choose to do reverse video, other terminals do other equally valid things and to this day people have problems with it.
Re: Entering text in the terminal is complicated
#197> First, there’s “the baseline” – what happens if a program just accepts text by calling fgets() or whatever and doing absolutely nothing else to provide a nicer experience. [...] there are actually a few features that you get for free just from your terminal, without the program needing to do anything special at all. The things you get for free are: [...] - backspace - Ctrl+W, to delete the previous word - Ctrl+U, t…
Programs like zsh, bash, ksh, fish and most TUIs put the terminal into cooked mode so that they can manage the terminals behavior manually. In cooked mode, the terminal is not new line buffered and instead every character is read. The terminal only appears to be new line buffered but is actually being managed by the shell, which then in turn allows the devs to add nice features like manipulating the text buffer to do…
*raw
Cooked is when the kernel handles it (cooking it before it gets to your program)
Re: Entering text in the terminal is complicated
#198Over 20 years ago now I wrote a state machine around readline that meant you could use it as a multi-line editor. Not "multi-line" as in a single line can wrap, but a true editor that lets you move up and down, but is windowless. Here's a video: https://github.com/colmmacc/jot/raw/master/jot-demo.mp4 and the CVS repository for the Unix terminal IM client it is part of is at: https://c-hey.redbrick.dcu.ie/src/c-hey_cv…
That's pretty cool, gonna steal the idea.
I can implement that specific case with a couple of lines in zsh. Something like:
autoload -Uz zed
icommit() {
() {
zed $1
git commit -F $1 # -a too, if you must ;)
} =(:) # Or maybe even =(Beauty of this basic implementation is that the keymap is fully controllable in zed as it is simply a new ZLE widget. It works with emacs or vi mode out of the box, and is fully customisable beyond that.
You could make the interface generic by writing your own ZLE widget, so that it can be called directly from within the line editor and remove the need for wrapping commands like I did above.
¹ https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
² This at least uses, and cleans up, a temp file to handle the commit message so it isn't completely useless.
Re: Entering text in the terminal is complicated
#199Earlier quoted context omitted.
Doesn't Windows, the most popular OS out there, have a cmd.exe terminal thing? Why isn't that harming Windows? The Windows Command Prompt's default experience is worse than most if not all terminals you find on Linux systems. Even in play TTY, you're bound to find that the shortcuts the author mentioned work like a charm. To make my cmd.exe bearable I am using https://chrisant996.github.io/clink tl;dr You're comparin…
Windows has a new terminal as default that is pretty cool - I install MSYS2 and set it in the new Windows Terminal and it's all good. Gnome Terminal and other terminals on Linux are also pretty cool too. If you want the worst default terminal experience just boot macOS.
I use MSYS2 too, can't stand WSL. Foe my terminal choice, I find wezterm to be awesome for my daily 3 OS use.
Re: Entering text in the terminal is complicated
#200Earlier quoted context omitted.
If the only Linux distributions were in the style of LFS, Gentoo and Arch* you would have a point, but as long as Ubuntu, Mint, OpenSUSE, Fedora, Manjaro and the myriad other user-friendly exist I fail to see the argument. Yes, Ubuntu has a Concorde cockpit behind the scenes and yes, I can access it on my Ubuntu work* laptop and I am grateful that I have that choice. I would hate not having that level of control. Mea…
I have used ubuntu for 2 years now, and its the motivation for the post. Ubuntu (or really any distro I am aware of) is great for pensioners (email readers) and power users (career linux user), with a protracted and hellishly complicated experience in between (technologically adept, but lifelong windows user). True, if you just want to fly straight to one of the most popular cities, you can just enter it in the autop…
> technologically adept, but lifelong windows user
Windows power users are also the ones who rant about the lack of video games in the ecosystem. They already have their happy place, and are not a worthwhile target for recruitment.