Powershell, as much as I like to hate on it, has a surperior line editor (PSReadLine) than that of Bash (Readline). Out of the box, it works just like most people would expect: you can press Shift + arrow keys to select a region of text. I have long wished to have this feature in Bash.
I am a big fan of akinomyoga's Bash Line Editor (ble.sh), but for whatever reason, when I log in to the system at work, it adds too much lag. If you want to add text selection to Bash, you should check it out. For most people I don't expect that it would add too much lag. It's packed with features and the maintainer was very accomodating to my stupid questions on his issue board.
A while back I stumbled upon something very interesting in the release notes for Readline v8.2 (2022): a new option has been added to .inputrc: enable-active-region. When I saw this I rejoiced: "Text selection is here!", but google search results turned up nothing. Nobody has been talking about this option as far as I can tell. At the time, I tried to demo this feature, failed to get it to work, and gave up. I knew it worked because I could see the highlighted region when I copy/pasted, but I couldn't seem to get the active region to reveal itself in any other way.
Recently I tried again and got similar results, until I found a Reddit thread which dropped a critical piece of information: the active region will reveal itself if you use the exchange-point-and-mark command. Knowing this, I was able to confirm that I am not crazy and the set-mark command actually was working. I could also confirm that copy-region-as-kill followed by yank would indeed copy/paste the region! So my title is clickbait and Bash has always had text selection. The problem was that as soon as you moved the cursor the region would get deactivated again, so the region basically has no visual feedback most of the time. For me to have the feature I always wanted, all I have to do is bolt on some visual feedback. How hard can it be?
Bolting On Visual Feedback
First I grep'ed the code for region activation (rl_activate_mark), and the results were not encouraging. The region is activated when using copy/paste, search, and exchange-point-and-mark. After playing around for a bit I had my big eureka moment: if I exchange-point-and-mark, and then I exchange-point-and-mark again, what I end up with is the point and the mark in the same positions where they started, and the region activated! So here's what I came up with:
- after I call
set-mark, set the environment variableREADLINE_KEEP_REGION_ACTIVEto 1 - after I call a navigation command (ex:
forward-character), ifREADLINE_KEEP_REGION_ACTIVE, activate the region usingechange-point-and-markx2 - after I call
abort, set the environment variableREADLINE_KEEP_REGION_ACTIVEto 0
The environment variable was necessary because without it, my region would stay active forever.
Implementing this was tricky: Bash lets you register arbitrary Bash commands to a keybind using bind -x, and Readline lets you register arbitrary Readline commands to a keybind using macros, but what I needed was a Readline command wrapped in a Bash conditional. What I came up with was this: overload a normal navigation keybind with a sequence of 3 keybinds: setup_navigation_hook (CtrlAltF11), the normal command, and then activate_navigation_hook (CtrlAltF12). setup_navigation_hook is a Bash function: if READLINE_KEEP_REGION_ACTIVE is 0, unbind CtrlAltF12, and if READLINE_KEEP_REGION_ACTIVE is 1, register exchange-point-and-markx2 to CtrlAltF12.
Here it is...
https://gist.github.com/simonLeary42/594065d2beee66f74767482c5a5176b7
As you can see, I set my mark at the beginning of the word "hello", and each time I move my cursor to the right, my active region grows to the right. Truly groundbreaking stuff.
Turd Polishing
Unsurprisingly, if you include CtrlB in the sequence bound to CtrlB, you get a recursion error. So every time I hooked a keybind, I had to find another keybind somewhere with the same command that I could wrap around. Since I use the Emacs keybinds, I chose to make each Emacs keybind wrap around the corresponding layperson's keybind (for lack of a better term). For example CtrlB wraps around Left Arrow, CtrlF wraps around Right Arrow, CtrlA wraps around Home, and so on. This means that I have a lot of keybinds hard coded at the top of my file. I did put in some effort to make the file readable and customizable, however. See this keybind definition:
local control='\C-'
local alt='\e'
# ...
local shell_backward_word_smart="${alt}${control}b"
Terminal Quirks
The behavior of modifier keys like Alt (or Option on Mac) is configurable by the terminal emulator, so it's difficult to create keybinds that "just work" on anyone's machine. But I did learn that you can find out exactly what your terminal emulator is doing using just cat -v (AKA cat --show-nonprinting if using coreutils):
simon@wheatley:~ $ cat -v
^[b
Here I pressed AltB, and learned that my terminal emulator sent the escape character instead of Alt. Readline uses C-style escape sequences, so if you just replace ^[ with \e, you get the Readline-compatible keybind \eb.
Bash Local Variables
I also ran into some trouble with variable namespaces when I tried to encapsulate my Bash logic in a function to avoid polluting the global environment. It turns out that nested functions are allowed, but no extra effort is made to prevent the inner function from losing access to the local variables defined in the outer function. So as soon as the outer function exits, the variables are unbound and the inner function becomes broken. I tried using an alias as a crude sort of closure, but I ran into string quoting issues, and I hate string quoting issues. Eventually I caved and I solved this problem with a few global variables. Painfully, instead of a local variable like $activate_navigation_hook, I was stuck with global $_readline_region_active_navigation_activate_navigation_hook. But I was able to cope using Bash's variable reference feature. In the global scope, I declare my ugly variable, then when I define my configuration I create a reference to that global with a tolerable name, modify it, and then when I want to reference that global I create a reference again:
_readline_region_active_navigation_activate_navigation_hook=''
function _readline_region_active_navigation() {
declare -n activate_navigation_hook=_readline_region_active_navigation_activate_navigation_hook
# ...
activate_navigation_hook="$alt_control_f12"
# ...
function _readline_setup_navigation_hook() {
declare -n activate_navigation_hook=_readline_region_active_navigation_activate_navigation_hook
# ...
bind '"'"$activate_navigation_hook"'": "'"..."'"'
}
}
I can live with this, although I'd love to be informed of a better way.
Unsolved Problems
If you select some text, and then you copy, you have to remember to abort. Otherwise, the next time you move your cursor, you select another region. This is just a visual annoyance, it doesn't change what you just copied. In Emacs, the region would be automatically deactivated when you copy. There's no reason I couldn't add this as another hook. I just worry that once I do, I will keep discovering more and more places where I expect the region to be deactivated.
In Conclusion
This was a fun one-day project that might actually improve my quality of life going forward. It's also entirely possible that getting cozy with highly bespoke shell customizations is going to bite me in the ass later when I SSH into another machine without them. It seems not out-of-the-question to me that Readline could someday incorporate this behavior in the future, perhaps as an opt-in with the old behavior as the default. After briefly looking at Readline's code, it doesn't look like the navigation commands are explicitly deactivating the region, so it may not have been intentional. We shall see.
