138
submitted 6 days ago by podbrushkin@mander.xyz to c/linux@lemmy.ml

In all GUI text editors, web browsers and IDE's you can move a cursor:

  • left/right arrows - move by char;
  • ctrl+left/right - move by word;
  • home/end - move to start/end of line.

Add Shift to any of above combination and everything you jumped through now is selected and you can: Ctrl+C, Ctrl+X,Delete to copy/cut/delete selection.

Also, you can Ctrl+Delete and Ctrl+Backspace to delete a next/previous word.

Also, you can Ctrl+Home/End to jump to start of first line or end of last line.

I want this to work when I type in a command in my Terminal.

Is it possible in Linux? It's a vanilla experience in Windows+Powershell, thanks to default PSReadlLine extension. It works both in conhost.exe and in Windows Terminal, but doesn't work in WT + cmd.exe, which makes me think it's PSReadLine which is responsible for this technological perfection.

"But you can't copy with Ctrl+C, it's..." - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.

I'm not bound to any distro or terminal application, but right now I don't see these incredible text editing techniques working even in Ubuntu+Powershell+PSReadLine, to say nothing about the Bash. I've tried installing WezTerm, but it doesn't have text selection either, at least by default. And I'm inclined to think it has nothing to do with terminal emulators at all, since it works in conhost.exe+Powershell.

top 50 comments
sorted by: hot top controversial new old
[-] podbrushkin@mander.xyz 14 points 5 days ago* (last edited 4 days ago)

I've got what I wanted with wezterm + powershell. I can edit my commands the same way I edit any text anywhere in the system, both in Windows and Linux, and I can copy-paste back and forth between terminal and any other app. This is awesome. This is freedom. This is UX done right.

I will paste below some observations I've made.

Possible solutions for Bash

Blesh

https://github.com/akinomyoga/ble.sh/wiki/Manual-%C2%A74-Editing

  • Super simple installation.
  • Home/End - Jump to start/end as expected. ✅
  • Ctrl+Backspace removes left char instead of left word. ❌
  • Ctrl+Delete removes next word as it should. ✅
  • Shift+arrows - char-wise text selection ✅
  • Shift+Ctrl+arrows - word-wise text selection ✅
  • Shift+Home/End don't do anything. ❌
  • Backspace/Delete: When smth is selected they delete it. ✅
  • Copy/Paste/Cut: ❌
    • It's Alt+W/Ctrl+Y/Ctrl+W instead of Ctrl+C/Ctrl+V/Ctrl+X.
    • All work with selection as expected.
    • All work with internal buffer instead of system clipboard.
  • System clipboard:
    • Can't copy selection to clipboard, can't paste clipboard into selection.
    • Ctrl+Shift+C/V work as they do in vanilla bash: copy what is selected with mouse to clipboard, paste from clipboard.
  • Ctrl+C prints current command and starts new one like in vanilla bash.

zsh-shift-select

  • Stated to have best compatibiliy with Alacritty.
    • Alacritty requires Cargo (440MB).
      • cannot install package alacritty 0.16.1, it requires rustc 1.85.0 or newer, while the currently active rustc version is 1.75.0 Fail. Will use Gnome Terminal instead.
  • Needs zsh, super simple installation.
    • Zsh should be default shell, gnome-shell crashed with SIGSEGV.
    • Plugin itself has simple installation, just git clone .zsh file and source it in .zshrc
  • Ctrl+arrows - prints CD instead of moving word-wise ❌
  • Ctrl+Backspace, Ctrl+Delete - are not deleting left/right word ❌
  • Home/End - Jump to start/end as expected. ✅
  • Shift+Left/Right - char-wise text selection ✅
  • Shift+Ctrl+arrows - word-wise text selection ✅
  • Shift+Home/End don't do anything. ❌
  • Shift+Up/Down - Select one line up/down ✅
  • Backspace/Delete - When smth is selected - delete it. ✅
  • Copy/Paste/Cut: ❌
    • Documented as Alt+W/Ctrl+Y/Ctrl+W instead of Ctrl+C/Ctrl+V/Ctrl+X.
    • Alt+W/Ctrl+Y work as copy/paste.
    • Ctrl+W removes previous word instead of Cut selection.
    • Work with internal buffer instead of system clipboard.
  • System clipboard:
    • Ctrl+Shift+C/V work as they do in blesh and vanilla bash.
    • Can't copy selection to clipboard, can't paste clipboard into selection.
  • Ctrl+C prints current command and starts new one like in vanilla bash.

wezterm + Powershell

PSReadLine starts with EditMode = Emacs by default.

Set-PSReadLineOption -EditMode Windows Fixes Ctrl+arrows, Ctrl+backspace, Shift+Ctrl+arrows.

Set-PSReadLineKeyHandler -Chord Ctrl+Delete -Function KillWord - Fixes Ctrl+Delete.

Set-PSReadLineKeyHandler -Chord Ctrl+o -Function AddLine - allows Ctrl+o instead of Shift+Enter to create a new line without trying to execute. Shift+Enter is not possible in Linux.

Reassigning Shift+Home/End in Gnome Terminal from scrolling viewport to something else is a rabbit hole, so I switched to wezterm, which fixed Shift+Home/End, and apparently also fixed a bug of Shift+arrows printing D;D;D; instead of selecting. But broke Shift+Ctrl+arrows. But you can fix it back by disabling this assignment in lua config.

Ctrl+C/V/X work fine, but without system clipboard synchronization. To fix it, install xclip. If it makes terminal freeze on Ctrl+C/X, update PSReadLine module.

  • Ctrl+arrows ✅
  • Ctrl+Backspace, Ctrl+Delete ✅
  • Home/End ✅
  • Shift+Left/Right ✅
  • Shift+Ctrl+arrows ✅
  • Shift+Home/End ✅
  • Shift+Up/Down ❌
  • Shift+Enter - Ctrl+o instead ✅
  • Ctrl+C,Ctrl+V,Ctrl+X - Flawless ✅

Windows + conhost + Powershell Core

PSReadLine starts with EditMode = Windows by default.

  • Ctrl+arrows ✅
  • Ctrl+Backspace, Ctrl+Delete ✅
  • Home/End ✅
  • Shift+Left/Right ✅
  • Shift+Ctrl+arrows ✅
  • Shift+Home/End ✅
  • Shift+Up/Down ❌
  • Shift+Enter ✅
  • Esc - clear current command ✅
  • Ctrl+C,Ctrl+V,Ctrl+X - Flawless, all with system clipboard. ✅
[-] pathos@lemmy.ml 1 points 4 days ago

Any particular recommendation?

[-] podbrushkin@mander.xyz 1 points 4 days ago

For Bash - try blesh, it will enable some of common controls by default, and probably you will be able to manually enable other shortcuts. PSReadLine is calling xclip each time for copy/paste action for clipboard sync, probably it will be possible with Blesh too.

[-] Alaknar@sopuli.xyz 1 points 4 days ago

Please keep at it! I've been looking for a while and I'm shocked how difficult such a seemingly simple thing is to get on Linux...

[-] podbrushkin@mander.xyz 1 points 4 days ago

I've got what I wanted, but I'm a powershell user. For Bash, blesh looks very promising - it's functionally same component as PSReadLine which makes all this stuff possible in pwsh.

[-] Xylight@lemdro.id 3 points 4 days ago* (last edited 1 day ago)

Call me cringe but this all works in Fish which is what I primarily use

[-] balsoft@lemmy.ml 21 points 6 days ago

I think this is one of many un-features in Linux world where

  • It would benefit a beginner
  • It sounds simple but actually quite complicated to get right (especially if you aim to keep compatibility with things)
  • Anyone possessing the skills to implement it neither needs it nor cares about it

As such, for you individually, I suggest just getting more comfortable with tmux (or zellij) and vi-like keybinds for text manipulation. Once you learn those (and set your readline mode to vi), you won't look back. Oh, also, try Ctrl+x Ctrl+e in bash, it might help.

Or switch to emacs and using it as a terminal emulator. In that case you will have to learn and use emacs keybindings, but the selection semantics in the "terminal" will be the same as in the "editor".

[-] podbrushkin@mander.xyz 1 points 5 days ago

one of many un-features in Linux

What exactly? Shift-selection is already possible with Blesh. I think I've seen scripts for synchronizing buffer with clipboard. And everything else is a matter of redefining existing shortcuts.

I've heard about Linux being highly customizable and decentralized OS, and suddenly I can't define my own shortcuts because there is a list of un-features?

I don't care about Vi and Emacs, I already have my workflow and I'm trying to transfer it to Linux. When I will succeed, then (maybe) I will spend some time to explore other ways of interacting with terminal. Otherwise, it's not freedom, it's becoming a victim of OS.

[-] balsoft@lemmy.ml 1 points 4 days ago* (last edited 4 days ago)

I’ve heard about Linux being highly customizable and decentralized OS, and suddenly I can’t define my own shortcuts because there is a list of un-features?

You can customize it to do whatever you want. Heck, you can write your own terminal emulator that does exactly what you need. But some things can be harder to do than others and require skills and experience. Once someone implements those harder things, they become a "feature". Before then, therefore, they are an "un-feature". See https://xkcd.com/1349/

E.g. it is probably possible to set up your shell to use shift-selection for the command you're currently editing, but shift-selection for the output of a previous command will require terminal support. You will have to make sure that the two don't interfere with each other, which can be quite complicated.

I already have my workflow and I’m trying to transfer it to Linux

Linux is a different OS that, by default, does things differently from others. You can configure it to emulate some other UX, but it won't necessarily be easy. In the meantime, you can install the micro editor, set EDITOR=micro, and then Ctrl+x Ctrl+e in bash to edit the command in a more familiar setting.

[-] podbrushkin@mander.xyz 1 points 4 days ago

I'm fine, I got what I wanted. Apparently, it isn't un-feature of Linux, it's un-feature of ReadLine which is shipped with Bash.

[-] ChaoticNeutralCzech@feddit.org 2 points 5 days ago

Add Windows-like Alt codes to the list. They're not perfect (they use a DOS codepage and A-F in the Unicode extension clash with shortcuts in other programs like Firefox, although not passing them through via xkb would solve this) but people use them a lot, especially in my country. At? Alt+64. Backtick? Alt+96. Caret? Alt+94. Hash? Alt+38. Musical note? Alt+13. Yes, we can type most of these on the Czech layout with AltGr but people don't know this and/or prefer things that work on the commonly default English layout too.

[-] balsoft@lemmy.ml 3 points 5 days ago* (last edited 5 days ago)

I prefer compose keys because they are easier to remember.

Oh, also, I think GTK apps have that Ctrl+shift+U thing which allows you to enter characters by code. Never really got used to it though.

[-] ChaoticNeutralCzech@feddit.org 1 points 5 days ago* (last edited 5 days ago)

I'm getting used to Compose and AltGr. Unexpected Keyboard for Android helps learn compose codes by visualizing them but it's still a bit of resistance. And yes, Compose can also be used to input Unicode hex codes.

Either way, I created a custom layout for AltGr and Shift+AltGr layers that is more convenient for me than remembering Compose and Unicode codes.

[-] turbowafflz@lemmy.world 12 points 6 days ago

I think if we want something like that to be consistent everywhere we need to stop using Ctrl so much as a modifier for non-terminal tasks. It doesn't solve everything, but using Alt or Super for copy and paste like Haiku and MacOS do is a big step in the right direction. It's just hard to change an established custom without making the whole experience less consistent

[-] podbrushkin@mander.xyz 10 points 6 days ago

It’s nice to see you think of it as of movement towards consistency. I also look at it this way.

But what is it about Ctrl? Text editing is historically the main task of computers, and Ctrl is the main “modifier” key. To me it seems fair it’s dedicated for some text editing shortcuts. Probably they are consistent since 1980’s.

[-] pr06lefs@lemmy.ml 12 points 6 days ago* (last edited 6 days ago)

but ctrl-c to cancel terminal tasks predates the 1980s. the inconsistency came in when apple decided to ignore that precedent and introduce ctrl-c, ctrl-x, and ctrl-v as shortcuts in their graphical UI.

to achieve consistency, probably better to invent a new terminal type that does away with the accumulated cruft of 50 years. problem is you would also need new cli programs to go with it.

[-] Alaknar@sopuli.xyz 6 points 6 days ago

Your comment reads extremely weird, considering both Mac and Windows handle this with zero issues.

It's super simple: if you're in Select mode (any text is selected), Ctrl+C copies. In any other case, Ctrl-C is the cancel command.

[-] someacnt@sh.itjust.works 3 points 6 days ago

It exerts too much Control to the users.

I'll see myself out

[-] everett@lemmy.ml 4 points 6 days ago

You can Ctrl-see yourself out.

[-] ZenAspirate@sh.itjust.works 9 points 6 days ago* (last edited 6 days ago)

I think Ctrl A and Ctrl E are home and end in cli

[-] Blaiz0r@lemmy.ml 6 points 6 days ago

I feel your pain, the only one's I know are...

  • CTRL+a = cursor to beginning of line
  • SHIFT+CTRL+c = Copy
  • SHIFT+CTRL+x = Cut
  • SHIFT+CTRL+v = Paste
[-] Alaknar@sopuli.xyz 6 points 6 days ago

You can add:

  • CTRL+K = delete everything from the cursor to the right.
  • CTRL+U = delete everything from the cursor to the left.
[-] rgalex@lemmy.world 2 points 5 days ago

And just to complement those, CTRL+Y to "yank" back whatever was deleted with CTR+K or CTRL+U.

[-] Oinks 5 points 6 days ago* (last edited 6 days ago)

There's apparently a ZSH plugin for this with a quite a few stars, though I haven't used it and can't speak for how well it works. In other shells what you want just doesn't exist to my knowledge, though it should be possible to script it with enough effort.

The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:

  • Terminal emulator keybindings will step on shell keybindings, and the shell will never know about it because it can't actually see the keys being pressed.
  • Even if the terminal doesn't care about a key, it might be impossible or error-prone to detect anyway. This applies to surprisingly regular keys like Tab.
  • As you've noticed some terminals try to get clever and do things like making Ctrl-C copy if you've selected text. The shell doesn't know about this either.
  • Most shells and TUI apps have selection modes. These are independent from terminal selections.
  • There's no standard way of using the clipboard in Linux, but multiple different ones that may or may not work.

All of these problems gets worse if you add multiplexers like tmux by the way.

Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don't quite share your idea of what reasonable keybindings look like (and it's also a little bit broken, though for mostly unrelated reason).

Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).

[-] felsiq@piefed.zip 6 points 6 days ago

I have everything you mentioned (except maybe the selection only stuff, I don’t use it and forget if I set it up at all) set up in my zsh+kitty setup, so it’s definitely possible. If you want I can dig thru my zshrc and kitty config for the relevant parts once I’m at my pc later.

People in here saying it’s a bad idea for things like compatibility with other shells make some good points, but I think they’re missing one important aspect - fuck other shells, what do I care? 95% of my time in the terminal is spent on my own machine and I may as well make it convenient for myself. The odd time I ssh into another box without my keybinds I’ll be a bit less efficient, but that’s a worthwhile trade off imo.

[-] podbrushkin@mander.xyz 2 points 6 days ago

In Gnome Terminal: Ctrl+arrows work, Ctrl+delete work, home/end work, Ctrl+backspace — not, and there is no text selection, of course. So, something is working as expected without config at all, and for what isn’t working, config will not help.

load more comments (1 replies)
[-] Remus86@lemmy.zip 5 points 6 days ago

I know in zsh, fish, and nushell, you can press a key combo to jump into a text editor of your choice. You write your command there, with all the power and shortcuts in emacs, vim, nano (whatever you like to use). Then you save and exit, and it appears in your command line, ready to execute.

[-] pr06lefs@lemmy.ml 6 points 6 days ago* (last edited 6 days ago)

I get those 3 bulleted features in my terminal, alacritty. But not with Shift. For highlighting I'm pretty much limited to selecting text with the mouse and ctrl-shift-c.

For more sophisticated text selection, tmux comes to mind. Default key bindings appear to be emacs-esque, though vi style is possible too. Custom keybindings are possible as well. It does seem like you may be forced to enter a special mode for selection rather than having that available all the time with just shift.

[-] podbrushkin@mander.xyz 5 points 6 days ago* (last edited 6 days ago)

For more sophisticated text selection

Here it is. What I’m asking for is not sophisticated at all, quite the opposite. I ask for keybindings which work in almost all text editing areas, in all applications, all operating systems. Vi and eMacs are steps in opposite direction. I think I even used a vi-mode in terminal a couple of years ago. I doubt it’s possible to simplify command editing with it.

[-] Ferk@lemmy.ml 5 points 6 days ago* (last edited 6 days ago)

The thing is that vi and emacs have existed since long before those other new editors came around.

What you want is possible to do by configuring your ~/.inputrc (see readline manual page for details), it's just that the defaults are different because they are from a time when many keyboards didn't even have arrow keys (and the ones that had them were in non-standard positions) so most of the shortcuts that became standard in those days are completely different than the ones common today. Given that the terminal is meant to emulate old style DEC VT100 terminals (that's why it's called terminal "emulator") it made sense to use those default that people had grown used to.

Personally, I've grown used to Ctrl+a, Ctrl+k, Ctrl+w, Ctrl+e and Ctrl+y ..I dont have to reach to wherever the Home key is in whatever keyboard I happen to be using at the moment (specially with modern 75%/60%-sized keyboards today). Or use a combination that also requires shift and having to hold so many keys together. In fact I went the opposite direction and customized my Powershell profile while I'm on windows to keep many of those old shortcuts in the Windows pwsh terminal as well.

[-] Alaknar@sopuli.xyz 4 points 6 days ago

The thing is that vi and emacs have existed since long before those other new editors came around.

What a weird thing to say... So what that they existed before? Who cares?

Ctrl/Shift modifiers work in a very consistent way in the entirety of Windows, most of Mac, and... everywhere in Linux except the terminal.

It boggles my mind that there isn't a simple switch to toggle between "classic" and "modern" style for keybinds.

[-] Ferk@lemmy.ml 2 points 4 days ago* (last edited 4 days ago)

Is it weird to explain the reason why something is as it is? If you were already aware of it then it shouldn't be as baffling.

There are also modern terminals and shells that do things the way you expect in a more convenient way, but maybe you also know this, OP mentioned powershell, that can be used in Linux too. It's just that this hasn't been a focus for traditional and slim/lightweight terminals coupled with traditional shells which is typically the popular combination amongst heavy terminal users, many of the slim terminal apps stay away from GUI toolkits that are what normally give consistency in settings to the GUI apps. And because they are slim and try to eliminate what isn't absolutely needed, typically they don't do configuration profiles, specially given that it's relatively easy in Linux to backup and reuse your configuration across installs. It's more of a job at the OS/sysadmin level.

There's also not a real standardized setup in Linux as a whole. There are environments that default using the Super (Windows) key for all window management, or use TUI terminal apps for most things so they get terminal navigation keys for all their apps. Some people even configure Gtk/Qt to use vim/emacs style for navigation in text boxes because for them it's the other way around, all their apps use terminal shortcuts because.. well.. they are terminal apps.

[-] Alaknar@sopuli.xyz 1 points 4 days ago* (last edited 4 days ago)

Is it weird to explain the reason why something is as it is? If you were already aware of it then it shouldn’t be as baffling.

Imagine this conversation:

OP: Hi guys, I'm looking for yellow tomatoes, do you know where can I get them?

You: Well, tomatoes are usually red because of [valid biological reason].

You see how weird that is?

There are also modern terminals and shells that do things the way you expect in a more convenient way, but maybe you also know this

Clearly, neither me nor the OP know this. If that wasn't the case, I would've provided OP with an answer to the question they posted!

OP mentioned powershell, he just use that (pwsh) in Linux

PowerShell still runs inside a terminal emulator (e.g. Fish), so it changes nothing in the input/output behaviour.

personally I haven’t tried the more GUI-friendly terminals

"GUI-friendly terminals"? What does that mean, in the context of the conversation?

Why are you talking about GUI?

[-] Ferk@lemmy.ml 1 points 4 days ago* (last edited 4 days ago)

You're not being fair, that wasn't the conversation thread at all.. I didn't reply to OP's initial message directly.

It was more like this:

  1. OP: Hi guys, I’m looking for yellow tomatoes, do you know where can I get them?

  2. Commenter: I go to this store, they have tomatoes that are yellow enough for me.. for more sophistication you need to go to a much further away local shop.

  3. OP Response: My question isn't sophisticated! ...all I want is my tomatoes to be of the same color as all the other yellow vegetables I exclusively eat, all yellow, tomatoes and ketchup being red is a step in the opposite direction.

  4. Me: there's a reason why the red ones are sold, [valid cultural reason]. But you can still change them, here's a manual / recipe to turn them yellow when cooking.

As you see, when I was talking about reasons it was mainly directed to the apparent indignation of comment "3", when the person was painting their request as something that should be seen as the more reasonable / less sophisticated approach.. so I gave the reason to show how the opposite is also more reasonable / less sophisticated from another point of view.

But even then, I did link to the manual for readline to configure the input handling. It's not like I just dismissed the initial question like your simplification implied.

PowerShell still runs inside a terminal emulator (e.g. Fish), so it changes nothing in the input/output behaviour.

You can definitely change the input/output behavior by changing the program that runs on the terminal... in fact, when I posted that link earlier, what I said is that you can configure this in readline, which is a library that bash and many other programs that run in the terminal (not all, not fish, for example) use for interpreting the input, so all terminal programs using the readline library for handling interactive input have the same shortcuts. It's not the terminal the one with those shortcuts coded into it.

“GUI-friendly terminals”? What does that mean, in the context of the conversation? Why are you talking about GUI?

Because a terminal emulator is a GUI app... OP wasn't talking about about real terminals, nor about a virtual console session in Linux (which runs without any GUI), but about a terminal emulator you open in a window within a graphical compositor.

My point was that most of the popular (amongst terminal nerds) GUI app terminals stay away from the traditional GUI toolkits when possible because they want to keep the app slim and lightweight. And it's those toolkits the ones that orchestrate the standardization of the typical Windows-like shortcuts (similar as the readline library, but for GUI apps). This is also why in many terminals you don't even have a menu when you right click, since those menus are usually done with GUI toolkits. But there are also heavy-weight terminals like the ones bundled in some more user-friendly DEs that do include GUI toolkits as dependencies, so they might actually have an easier go at playing nice with other conventions in their respective DEs. However, you'd still need to pair it with a shell that also plays nice (or configure it to play nice, if possible).

[-] Mio@feddit.nu 3 points 6 days ago

Ctrl + a or crtl + e is start or end of line?

[-] coltn@lemmy.ml 3 points 6 days ago

I think most of this works for me in zsh. But also tmux can help with selection; I believe by default you use your prefix then open bracket (Ctrl-b + [) to put your self in selection mode. I have some configs to use vim bindings in selection mode.

Tmux selection:

# Yanking
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi C-v send-keys -X rectangle-toggle
bind-key -T copy-mode-vi y send-keys -X copy-selection-and-cancel

zsh keybinding:

# Key Bindings
# set vim mode
bindkey -v

# create a zkbd compatible hash;
# to add other keys to this hash, see: man 5 terminfo
typeset -g -A key

key[Home]="${terminfo[khome]}"
key[End]="${terminfo[kend]}"
key[Insert]="${terminfo[kich1]}"
key[Backspace]="${terminfo[kbs]}"
key[Delete]="${terminfo[kdch1]}"
key[Up]="${terminfo[kcuu1]}"
key[Down]="${terminfo[kcud1]}"
key[Left]="${terminfo[kcub1]}"
key[Right]="${terminfo[kcuf1]}"
key[PageUp]="${terminfo[kpp]}"
key[PageDown]="${terminfo[knp]}"
key[Shift-Tab]="${terminfo[kcbt]}"

# setup key accordingly
[[ -n "${key[Home]}"      ]] && bindkey -- "${key[Home]}"       beginning-of-line
[[ -n "${key[End]}"       ]] && bindkey -- "${key[End]}"        end-of-line
[[ -n "${key[Insert]}"    ]] && bindkey -- "${key[Insert]}"     overwrite-mode
[[ -n "${key[Backspace]}" ]] && bindkey -- "${key[Backspace]}"  backward-delete-char
[[ -n "${key[Delete]}"    ]] && bindkey -- "${key[Delete]}"     delete-char
[[ -n "${key[Up]}"        ]] && bindkey -- "${key[Up]}"         up-line-or-history
[[ -n "${key[Down]}"      ]] && bindkey -- "${key[Down]}"       down-line-or-history
[[ -n "${key[Left]}"      ]] && bindkey -- "${key[Left]}"       backward-char
[[ -n "${key[Right]}"     ]] && bindkey -- "${key[Right]}"      forward-char
[[ -n "${key[PageUp]}"    ]] && bindkey -- "${key[PageUp]}"     beginning-of-buffer-or-history
[[ -n "${key[PageDown]}"  ]] && bindkey -- "${key[PageDown]}"   end-of-buffer-or-history
[[ -n "${key[Shift-Tab]}" ]] && bindkey -- "${key[Shift-Tab]}"  reverse-menu-complete

# Finally, make sure the terminal is in application mode, when zle is
# active. Only then are the values from $terminfo valid.
if (( ${+terminfo[smkx]} && ${+terminfo[rmkx]} )); then
	autoload -Uz add-zle-hook-widget
	function zle_application_mode_start { echoti smkx }
	function zle_application_mode_stop { echoti rmkx }
	add-zle-hook-widget -Uz zle-line-init zle_application_mode_start
	add-zle-hook-widget -Uz zle-line-finish zle_application_mode_stop
fi


# History - use current line up to cursor to search through history with arrow keys
autoload -Uz up-line-or-beginning-search down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search

[[ -n "${key[Up]}"   ]] && bindkey -- "${key[Up]}"   up-line-or-beginning-search
[[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-beginning-search
[-] brax@sh.itjust.works 2 points 6 days ago
  • ctrl + left/right move by word

I will forever hate the way vim moves by the start of the word and not the end of the word... The number of times I want to remove the last letter/s of a word at the end of a line and end up on the next line is too damn high.

Also, don't forget about ctrl + w to delete a full word.

[-] eleijeep@piefed.social 4 points 6 days ago

You need to learn about e and E motions, but also $ will take you to the end of the line.

[-] brax@sh.itjust.works 3 points 6 days ago

The problem is that I don't think any of those work in Insert mode, and I hope I'm about to be proven wrong lol

[-] Ignot@lemmy.world 4 points 6 days ago

It's two clicks, but b then e takes you to the end of the previous word in neo/vi/m

[-] brax@sh.itjust.works 2 points 6 days ago

Might have to set a custom keybind for that one to chain ctrl+right/ctrl+left to throw a :b e after

Thx for the protip... Now all I need to do is learn how to quit it. 🤣

[-] Ignot@lemmy.world 3 points 6 days ago

Nobody knows how to do that! I've been running the same session since 2005 :(

[-] brax@sh.itjust.works 3 points 6 days ago

Q q quit Quit QUIT x ex exit EXIT Exit EX X Leave leave LEAVE T terminate TERMINATE. SEND HELP

Oh sorry, just pasting my vim window

[-] folekaule@lemmy.world 2 points 6 days ago

This is one of the reasons I prefer using ctrl-insert/shift-insert when it's available. Unfortunately the Insert key seems to have disappeared from a lot of keyboards. Scroll lock sometimes works instead of ctrl-s and ctrl-q. I would be ok remapping ctrl-c to ctrl-break, but I still use ctrl-z to background a job. Would be great if terminals had a quick easy way to select your preference of Microsoft, unix, or CUA shortcuts.

[-] cypherpunks@lemmy.ml 2 points 6 days ago* (last edited 6 days ago)

“But you can’t copy with Ctrl+C, it’s…” - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.

What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected? In every one I've ever used, ctrl-c still sends SIGINT even with text selected (and one must must use ctrl-shift-C/ctrl-shift-V to copy/paste).

I don't have any suggestion for getting the behavior you're asking for, but besides the normal ctrl-(shift)-C/V clipboard FYI you also have two other types of clipboard-like things: one which works anywhere (not only in the terminal) and is actually always automatically copying anything you select and lets you paste from it with middle click (this originated with X Windows but i think most Wayland compositors have also implemented it by now), and another which is found in GNU Readline (used by bash and numerous other REPLs) called the "kill buffer" which can be pasted (or "yanked") from and cut (or "killed") to using Emacs keyboard shortcuts (which also include various cursor movement controls).

Notes:

  • the kill buffer is local to a given readline context, it's not shared across different shell windows.
  • the list of emacs keybindings in that wikipedia article i linked is currently confusingly referring to the kill buffer as "the clipboard"
  • you can drastically reconfigure your readline keybindings and other behavior by editing your .inputrc file, but you cannot achieve what you were originally asking for because there is no concept of text selection in readline.

HTH!

[-] podbrushkin@mander.xyz 4 points 6 days ago

What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?

This is what I experienced in conhost.exe (legacy windows console experience, predecessor of Windows Terminal) + Powershell. In windows terminal it works this way too. This is why I suspect it’s related not to terminal itself (conhost.exe/wt.exe/gnome terminal etc), and not to specific shell (bash/powershell), but to an extension for shell (ReadLine,PSReadLine).

As for various types of buffers and clipboards, I always felt like one system-wide clipboard with clipboard history is enough. When I cut something from terminal, quite often I paste it into another app, and not back to terminal.

[-] Ephera@lemmy.ml 3 points 6 days ago

What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?

I know that the terminal emulator built into the JetBrains IDEs works that way...

load more comments
view more: next ›
this post was submitted on 29 Oct 2025
138 points (100.0% liked)

Linux

59372 readers
413 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS