Skip to content
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

Closed
sheldon opened this issue Aug 24, 2015 · 22 comments
Closed

Comments

@sheldon
Copy link

sheldon commented Aug 24, 2015

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

@faho
Copy link
Member

faho commented Aug 24, 2015

It should be in one of these bindings:

bind \e\eOC nextd-or-forward-word
bind \e\eOD prevd-or-backward-word
bind \e\e[C nextd-or-forward-word
bind \e\e[D prevd-or-backward-word
bind \eO3C nextd-or-forward-word
bind \eO3D prevd-or-backward-word
bind \e[3C nextd-or-forward-word
bind \e[3D prevd-or-backward-word
bind \e[1;3C nextd-or-forward-word
bind \e[1;3D prevd-or-backward-word

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)

@sheldon
Copy link
Author

sheldon commented Aug 29, 2015

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 SET fish_key_bindings:fish_default_key_bindings. Do you think the defaults don't have these bound perhaps? Or is there a way to check that, or check what my terminal is sending?

@faho
Copy link
Member

faho commented Aug 29, 2015

The defaults should have them, though it's possible we're missing an escape.

Just run bind to see your bindings.

@sheldon
Copy link
Author

sheldon commented Aug 29, 2015

Here's my output, looks correct to me:

sels@marvin ~> bind | grep nextd-or-forward-word
bind \e\eOC nextd-or-forward-word
bind \e\e\[C nextd-or-forward-word
bind \eO3C nextd-or-forward-word
bind \e\[3C nextd-or-forward-word
bind \e\[1\;3C nextd-or-forward-word

thanks for the quick response and help 👍

@sheldon
Copy link
Author

sheldon commented Aug 30, 2015

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 ^[b and ^[f from Terminal.app in OSX. ^\[ is the same as \e.

The output from bind in fish shell has

bind \eb backward-word
bind \ef forward-word

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

@sheldon sheldon changed the title directory history not working with alt-left / alt-right directory history not working with alt-left / alt-right on Terminal.app in OSX Aug 30, 2015
@faho
Copy link
Member

faho commented Aug 30, 2015

This shows alt-left and alt-right output ^[b and ^[f from Terminal.app in OSX.

Yeah, that's pretty broken - being unable to distinguish alt-left from alt-b... (goes off to the corner to grumble)

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?

I'd agree. Anyone else?

Nice work tracking this down by the way!

@floam floam added the bug Something that's not working as intended label Jul 5, 2016
@floam floam added this to the fish-future milestone Jul 5, 2016
@jcrben
Copy link

jcrben commented Nov 26, 2016

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

@faho
Copy link
Member

faho commented Nov 26, 2016

@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).

@jcrben
Copy link

jcrben commented Nov 26, 2016

@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 nextd-or-forward-word work?

UPDATE: seems like it's working with the below:

bind \e\[1\;9D 'prevd-or-backward-word'
bind \e\[1\;9C 'nextd-or-forward-word'

@faho
Copy link
Member

faho commented Nov 26, 2016

shouldn't manually binding the key to the nextd-or-forward-word work?

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
Copy link

jcrben commented Nov 26, 2016

Are you sure about your conclusion? I'm using iTerm, not Terminal.app.

Using the CTRL+V trick mentioned above, I get ^[[1;9D for the alt+left arrow while alt+b is ^[b. Thus I needed to run bind \e\[1\;9D 'prevd-or-backward-word' to fix.

I've also set alt keys to ESC+ and set the key mapping to the xterm defaults:
image

@krader1961
Copy link
Contributor

@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 fish_key_reader which makes understanding what various keys send much clearer than the [ctrl-V] trick or using tools like xxd or od.

@jcrben
Copy link

jcrben commented Nov 27, 2016

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 xterm Defaults and Terminal.app Compatibility.

@elias6
Copy link

elias6 commented Jul 21, 2021

Would it be possible to make alt-left and alt-right just work, without needing this workaround, by binding \eb to 'prevd-or-backward-word' and \ef to 'nextd-or-forward-word'?

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?

@faho
Copy link
Member

faho commented Jul 22, 2021

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).

@elias6
Copy link

elias6 commented Jul 22, 2021

@faho would my idea break anything important?

If the user has entered text on the command line, backward-word and prevd-or-backward-word do the same thing, and forward-word and nextd-or-forward-word do the same thing, so there would be no change in behavior if we call one instead of the other.

And if there is no text, backward-word and forward-word do nothing useful, so there would be no loss of functionality if we call something else instead. The worst that would happen is some users may get annoyed if they accidentally go back or forward, but that seems much better than the directory history not working at all for many users (without requiring awkward workarounds that are not at all obvious).

@faho
Copy link
Member

faho commented Jul 23, 2021

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.

@faho faho closed this as completed in 7167ba6 Jul 23, 2021
@faho faho modified the milestones: fish-future, fish 3.4.0 Jul 23, 2021
@faho faho added enhancement and removed bug Something that's not working as intended labels Jul 23, 2021
@elias6
Copy link

elias6 commented Jul 23, 2021

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 \eb and \ef in all terminals.

@faho
Copy link
Member

faho commented Jul 23, 2021

Why was this closed?

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.

@elias6
Copy link

elias6 commented Jul 23, 2021

What? If it was fixed, then why can't I go back and forward by pressing alt-left and alt-right?

@faho
Copy link
Member

faho commented Jul 23, 2021

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.

@elias6
Copy link

elias6 commented Jul 23, 2021

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants