Live data from Hacker News

Entering text in the terminal is complicated

jvns.ca

171–180 of 229 posts

Re: Entering text in the terminal is complicated

#171

"The other day I asked what folks on Mastodon find confusing about working in the terminal, and one thing that stood out to me was "editing a command you already typed in". This really resonated with me: even though entering some text and editing it is a very "basic" task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the…

tcsh has a (maybe) unique command line editing feature: transpose characters.

Ctrl-T

It's vi mode is not as good as libedit's (IMHO) yet each shares the same author/maintainer.

Though it's no longer the default, I believe tcsh may still be included with MacOS.

Re: Entering text in the terminal is complicated

#172
post #78
post #42

I think the lowest hanging fruit would be doing something (anything) to improve discovery of commands. I have great grokking abilities but terrible memorization skills, and I end up forgetting how to do what I want to do and maybe even have done before. Browsing man pages for every command is my bane. It's also why I dislike GUI with unlabelled icons, I never remember what each one does.

Maybe try fish? Tab completion will suggest subcommands, and if you type - or -- and hit tab, it will suggest the available options with help text generated from man pages (example: https://flaviocopes.com/images/fish-shell/autocomplete.png ). Doesn't really help with positional arguments but it's definitely enhanced the discoverability of many tools for me.

This is by far the best practical option! Life could be even better, but out of all options this one's great.

Re: Entering text in the terminal is complicated

#173
post #96

the top three default readline keybindings that would improve people's lives if they knew about them: - control-w, which julia mentions in the post, to delete the last word - control-o: when you're recalling a line from history, edited or no, runs the line and recalls the following line from history . so you can run a sequence of five commands from history by navigating to the first one and hitting control-o five tim…

I've always wondered why control-s was chosen for this, given the obvious conflict with XOFF (pause), which in my experience is the default almost everywhere. One would have to (a) know why it wasn't working and (b) be willing to disable XOFF, in order to use that key combination for the forward history feature.

Re: Entering text in the terminal is complicated

#174

Over 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…

Oh, that looks really cool! Is the current iteration of the program stable?

Re: Entering text in the terminal is complicated

#175

> license reasons, if the program’s license is not GPL-compatible – readline is GPL-licensed, not LGPL The older I get, the less patient I become with finding out some user experience sucks because of GPL / non-GPL knife fights. It's been thirty-nine years now. I think the GPL was useful at its origin, but now the benefits of open-source are proven out, the world is deeply interconnected via the Internet, and it's a…

No, the GPL license for GNU Readline is very intentional. There is a bunch of written history from Richard Stallman about it. He felt it provided such an large advantage, that some programs might switch to GPL to use GNU Readline. After 35 years of development (started in 1989 according to Wiki), it has a hefty start is someone wants to beat it with a "clean room" BSD-licensed edition.

Some HN info about Stallman's reasoning: https://news.ycombinator.com/item?id=26606328

I cannot find any specific writing from him, but I am sure I read words from him about 25 years ago.

    > I'd rather code be maximally unencumbered from interoperation.
Yes, the problem is that commercial organizations would like open source to do all the hard work for them. Then, they use the software internally, and don't give anything back -- except two pence via RedHat licensing. (We have learned this the hard way in the last 10 years of major security bugs due to underfunded projects.) However, you are free to re-implement the API and license it in a different way.

Re: Entering text in the terminal is complicated

#176
post #5

It took the author 15 years to learn basic readline commands?

Here is the exact quote in question:

    > This really resonated with me: even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end).
I think your take is a bit harsh. She is quite a popular writer, and day after day, lays out her ego out for a beating by the InterWebs each time that she posts. She is never afraid to be humble. That is part of the genius of her posts. She says what so many are afraid to say publicly -- "oh this 'simple' thing is very complex" or vice versa.

Re: Entering text in the terminal is complicated

#177
post #21

> 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 the data until the line is complete.

> and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?

Provided that "it" refers to the terminal, then yes. Normally it's the terminal itself which allows you to edit the line you are typing on. This is also provided by the default canonical mode. Even the fact that letters show up on the line when you type is a terminal feature called echoing. So are things like backspace, delete, Ctrl+C for SIGINT, Ctrl+D for EOF.

Line and text editors just turn off all of this stuff. They place the terminal in raw mode where everything you type is sent immediately to the application where it is handled immediately. A wide variety of everyday programs do stuff like this. For example, password prompts simply turn off echoing to hide the characters.

Even the traditional Unix line ending \n is actually a feature of terminals. To the terminal, \n just moves the cursor down one line, \r is also needed to go back to the beginning of the line. The true line ending is therefore \r\n. The terminal just happens to invisibly turn \n into \r\n. This too can be disabled.

Re: Entering text in the terminal is complicated

#178
post #145

I have great respect for Julia Evans and love her contributions that get shown here. But... > "I’ve always thought that vi mode seems really cool, but for some reason even though I’m a vim user I didn’t really like using it when I tried it." Really, that seems weird to me. I use zsh (btw) and the problem she describes is a non-issue. And I am not a pro. (Sorry, Julia).

I have to agree with the other commenter (drewg123). Been a Vim user for decades but don't use Vi-mode in the terminal. > the problem she describes is a non-issue. And I am not a pro. Not sure what you're saying here. Julia didn't describe a problem but a preference ("I didn’t really like using it"). I'm not sure how you can you call someone's preference a non-issue. It's a preference and we're allowed to have those…

"even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)."

This sounded to me like she was describing a problem. My bad.

And I too am allowed express opinions, no?

Re: Entering text in the terminal is complicated

#179
post #18

> took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end). And the curse of bad defaults strikes again (daily). After the realization that this is a weird default you don't train yourself for 15 years, but change it to your comfortable/common keybinds!

I'd rather press left or right arrow keys 40 times than pollute my brain with yet another keystroke to remember.

Re: Entering text in the terminal is complicated

#180
post #145

Earlier quoted context omitted.

I have to agree with the other commenter (drewg123). Been a Vim user for decades but don't use Vi-mode in the terminal. > the problem she describes is a non-issue. And I am not a pro. Not sure what you're saying here. Julia didn't describe a problem but a preference ("I didn’t really like using it"). I'm not sure how you can you call someone's preference a non-issue. It's a preference and we're allowed to have those…

"even though entering some text and editing it is a very “basic” task, it took me maybe 15 years of using the terminal every single day to get used to using Ctrl+A to go to the beginning of the line (or Ctrl+E for the end)." This sounded to me like she was describing a problem. My bad. And I too am allowed express opinions, no?

In your first comment, you said it "seems weird" that Julia doesn't like Vi-mode.

In this comment, you quote Julia talking about Emacs-mode. Which doesn't really follow on from your first comment.

Post reply on HN