Re: Strange behaviour in zsh's emacs bindings

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

} On Fri, 16 Jan 2009, Andres Goens wrote:
} > I have been using the zsh with emacs bindings for some time now and
} > have noticed that the killing/moving forward of a single word (M-d,
} > M-^H, M-f,M-b) does not work the way it works under emacs (or bash
} > with emacs bindings, for example) as it treats strings like
} > "/this/is/a/long/path" as a single word, as it does with strings
} > separated with points

This is so that an entire file name is generally considered to be a
single word.  The zsh emacs bindings are not really emacs bindings,
they're a sort of best approximation of the semantics of words from
the old BSD 4.x TTY driver combined with (most of) the keybindings
of emacs circa the same time period (early 90s).

The idea was to be unsurprising to people who came from a shell that
did not have its own editor, but usable for people familiar with
emacs.  Hence the default binding of ctrl+w to backward-kill-word
rather than to kill-region.

There are a lot of zsh features that are like that, which people who
never lived in the time when most shells didn't subsume editors tend
now to interpret as bugs.

On Jan 16,  3:17pm, Benjamin R. Haskell wrote:
} 
} You should remove '.' and '/' from the WORDCHARS variable.

Correct.

} I haven't used emacs in a long time, so I'm not sure what else might
} be inconsistent between the two. And maybe someone else can chime in
} with the default value of WORDCHARS?

% zsh -fc 'typeset -p WORDCHARS'
typeset WORDCHARS='*?_-.[]~=/&;!#$%^(){}<>'