I managed to figure this out after seeing in the source code that using ~/.inputrc was deprecated. Turns out it worked on my Debian machine because it was using a much older version of fish. Also, it wasn't immediately obvious how I could make the bindings permanent, since just adding the commands to my config.fish file didn't do anything. I did end up finding the fish_key_bindings variable, but I found it very counter-intuitive that simply adding it to my config didn't have an effect.

Also, I'm attaching a darcs patch which adds the proper bindings for forward/backward-word for Terminal.app, and OS X's xterm.

And I'll definitely think about contributing some code to change the word behavior, and I'll be sure to study previous implementations, since I'm sure it's a touchy matter.

Attachment: osx-binding.darcspatch
Description: Binary data


On Jan 30, 2008, at 4:20 PM, Axel Liljencrantz wrote:

On Jan 30, 2008 12:05 AM, dackz <[EMAIL PROTECTED]> wrote:
Thanks, that works.

Something else I've noticed: ctrl+left arrow and ctrl+right arrow
don't work for me. They work fine in bash with the same terminal
(Terminal.app) and the keys actually work on a remote Debian machine I
have with fish running, with the same terminal. I've got ~/.inputrc
set to map \e[5C to forward-word and \e[5D to backward-word, yet when
I hit either key, it just prints [5D and [5C in my console. Does fish
respect what's in ~/.inputrc, or am I missing some other kind of
configuration setting?

Use the bind builtin to bind keys in fish:

bind \e[5c forward-word



Also, another thing I've been wondering: Why is unix-word-rubout (^W)
so finicky? If I type "ls --foo --bar" and hit ^W once, it erases just
"bar", then if I hit it again, it erases "foo --", and if I hit it a
third time, it erases "ls --", leaving me with nothing. Is this
configurable? I would've expected it to erase --bar, then --foo, then
ls, or at least respect the spaces between each part, even if dashes
are counted as spaces.

Because fish has gone through a huge number of reviosions to that
particular piece of code, and not a single one of them worked well all
the time.

You're more than welcome to rewrite move_word in reader.c, which is
the offending code.


Axel



On Jan 29, 2008, at 1:11 PM, Nick Pilon wrote:

On Jan 29, 2008 1:24 PM, dackz <[EMAIL PROTECTED]> wrote:
1. Despite setting CLICOLOR=1, ls ignores this setting. Making a
function to add -G into the args, works, but that threw me off for a
while. ls under bash doesn't have this issue.

Use set -x CLICOLOR 1 instead of set CLICOLOR 1. set -x exports the
variable to child processes. set just sets the variable. If you want
it to apply to all fish sessions, current and future, use set -Ux
CLICOLOR 1. -U makes the variable "universal".

--
-Nick Pilon


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users

Reply via email to