-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
directory history not working with alt-left / alt-right on Terminal.app in OSX #2330
Comments
It should be in one of these bindings:
So check if these are bound. If they are, your terminal might be sending a different string - which one are you using? (If that's the issue, you can confirm it by binding the functions to other keys) |
Hey @faho Thanks for the suggestion. I've tried checking in ~/.config/fish and can't find any references to nextd-or-forward-word, and when searching for bind the only thing I'm finding is |
The defaults should have them, though it's possible we're missing an escape. Just run |
Here's my output, looks correct to me:
thanks for the quick response and help 👍 |
I managed to track this down, so here's the solve in case anyone else is looking for it. Running bash and using ctrl-v followed by a keystroke will output it's character sequence. This shows alt-left and alt-right output The output from bind in fish shell has
which means Terminal.app won't search the directory history instead of word skipping when the command line is empty on that particular terminal app. Not sure if this should remain a bug, but it took a while to figure out for me. Unless there's a reason not to, I think all bindings of forward-word and backward-word should be changed to the nextd-or-forward-word and prevd-or-backward-word variants? Especially to support that feature out the box on OSX's builtin Terminal.app |
Yeah, that's pretty broken - being unable to distinguish alt-left from alt-b... (goes off to the corner to grumble)
I'd agree. Anyone else? Nice work tracking this down by the way! |
Is there a recommended workaround for this since the fix hasn't shipped? For some reason I was having trouble binding the commands to those optional ones - still pretty new to fish. There is the workaround described at https://coderwall.com/p/ygcaqg/get-alt-arrow-keys-working-in-fish-on-os and it does seem to work but it feels a bit dirty |
@jcrben: That workaround (binding alt+arrow to more usual sequences) isn't actually bad. It would actually be the only thing to allow you to bind alt-b to something different from alt-left (and other combinations). I'm actually a bit annoyed that that's not the default - those would be the sequences that actual xterm sends, and IIRC Terminal.app identifies as xterm (via $TERM). |
@faho it may not be bad in that sense, but I sometimes switch shells and I find that binding keys like this to the terminal rather than shell messes with things and confuses me later on. shouldn't manually binding the key to the UPDATE: seems like it's working with the below:
|
Yes, that'll work. I kinda like the workaround (and wish apple would just do it, turning it into a solution) because it brings Terminal.app in line with xterm, which it proclaims to be, and because it allows you to bind alt-left differently from alt-b - since currently it just tells the app that you've pressed alt-b when you pressed alt-left. There are some key combinations in a terminal that can't be distinguished from others (e.g. ctrl-i and tab), but it's a major PITA and they should be reduced as much as possible, not increased. Now, I can see why you'd like alt-left to do the same thing as alt-b - in emacs modifier-b does some backwards-movement, i.e. ctrl-b is moving backwards a character, alt-b moving backwards a word, and this is also the readline (and hence bash) default, so by making alt-left send alt-b, you get that automatically. But it's bad to not allow binding them differently. Anyway, I think I'll make the change in the defaults. I'm just annoyed that we have to. |
@jcrben: I don't see where you mentioned the terminal you were using prior to your most recent comment. The O.P. was using Terminal.app which does in fact have the behavior described. Whereas iTerm2 gets it right using the xterm default key bindings. P.S., Fish includes a program named |
Yeah, sorry about that. I was actually running fish 2.1.2 and now that I've upgraded to 2.4 it seems like it is working properly for me out of the box. Still absorbing a lot of new information... I'll report back if I find anything that needs changing, but right now it's 👍 Seems to work properly using both |
Would it be possible to make alt-left and alt-right just work, without needing this workaround, by binding My guess is it would be, although I haven't tried it. But is this a practical solution? Or is there some downside I'm unaware of? |
That those are the same as alt+b / alt+f, which we use for other things. It appears Terminal.app here wants this to act differently, so they picked those sequences. Which we could act against, but it claims to be "xterm", and we definitely don't want to break the distinction for all terminals claiming to be xterm, so it would have to only be done if e.g. $TERM_PROGRAM was set to Terminal.app. Which would be possible, but someone on macos would have to do it (which excludes me). |
@faho would my idea break anything important? If the user has entered text on the command line, And if there is no text, |
This is a workaround for a bad design decision in a proprietary, single-platform terminal. Key combinations in a terminal are at a premium, and the terminal should offer as many as possible. Collapsing them is quite awkward. Working around that should not impact more sensible terminals. Again: Write a patch that checks $TERM_PROGRAM in the bind function. Make it bind \eb and friends, but only in Terminal.app. |
Why was this closed? Yes, it was a bad decision to make the Mac Terminal treat alt-left like alt-B and alt-right like alt-F, and I agree that terminals should offer as many key combinations as possible. But is that not a reason to work around it by assigning the things we want alt-left to do to alt-B, and likewise for alt-right? I don't see how this is "collapsing" key combos. I don't see what the harm is in binding |
Because it was fixed in 7167ba6, by working around Terminal.app, by binding \eb to what alt-left does and \ef to what alt-right does. |
What? If it was fixed, then why can't I go back and forward by pressing alt-left and alt-right? |
Because the fix isn't released yet. It will be released in the upcoming fish 3.4.0. It's already included in the master branch, which is when we close issues. |
Oh... I didn't understand that this was already fixed in a version that hasn't yet been released. I guess I will eagerly wait for it. Thanks for explaining. |
Hi
I've tried a little debugging but can't seem to narrow this down. dirh works fine showing a list of previous directories. alt-left / alt-right work fine for skipping words or completing commands 1 argument at a time. For some reason alt-left / alt-right at an empty command line don't switch directories in the history.
Any chance there's some way I can figure this out? It seems like a great feature!
Thanks
The text was updated successfully, but these errors were encountered: