silly behavior of killWord in XMonad.Prompt

newer
* UrgencyHooks made available as...

older
bringing xmonad into the threaded...

Brent Yorgey

24 Apr 2012 24 Apr '12

10:07 a.m.

I realized today that the behavior of killWord from XMonad.Prompt is surprising to me. In particular, when you iterate killWord, it deletes first a word, then a space, then the next word, then the next space, and so on. I (an emacs user) expect killWord to delete a word AND any whitespace that happens to come before it. (Hmm... I tested with vim and it seems that 'dw' deletes a word along with any TRAILING whitespace. So emacs and vim differ here... but the point is that killWord emulates neither.) I looked into it and it turns out that the behavior of killWord is even sillier than I thought. It deletes an entire word of non-whitespace characters *or a single space*. (So if there are multiple spaces you have to call killWord once for each space before you finally get to delete the word that comes after.) And if the next character is a tab it doesn't delete anything at all! For concreteness, here's the change I made: diff -rN old-XMonadContrib/XMonad/Prompt.hs new-XMonadContrib/XMonad/Prompt.hs 525,528c525 < delNextWord w = < case w of < ' ':x -> x < word -> snd . break isSpace $ word ---

...

delNextWord = snd . break isSpace . dropWhile isSpace

Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two. -Brent

Show replies by date

Norbert Zeh

24 Apr 24 Apr

10:18 a.m.

Brent Yorgey [2012.04.24 1007 -0400]:

...

Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two.

My 2c: I think the old behaviour is silly and am in favour of fixing it. I'm a 70% emacs, 30% vim user, so I lean a bit more towards an emacsesque solution. Cheers, Norbert

Mike Meyer

11:21 a.m.

Norbert Zeh wrote:

...

Brent Yorgey [2012.04.24 1007 -0400]:

...
Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two.

My 2c: I think the old behaviour is silly and am in favour of fixing it. I'm a 70% emacs, 30% vim user, so I lean a bit more towards an emacsesque solution.

Can I vote for neither? Or both? How about deleting any leading whitespace, then non-ws characters, then only if there was no leading ws delete trailing ws? -- Sent from my Android phone. Please excuse my swyping.

wagnerdm＠seas.upenn.edu

11 a.m.

Quoting Brent Yorgey :

...

could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two.

I don't use killWord, but I do use vim, and I endorse the emacs behavior. I use de more than dw anyway. ~d

Ben Boeckel

8:31 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Apr 24, 2012 at 15:00:42 GMT, wagnerdm@seas.upenn.edu wrote:

...

Quoting Brent Yorgey :

...
could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two.

I don't use killWord, but I do use vim, and I endorse the emacs behavior. I use de more than dw anyway.

While we're fixing it, maybe allowing the user to pass a isWordSeparator function (killWord' function likely) in (default to isSpace). Breaking words on '/' characters might be helpful. I'd also be interested in seeing a killWordVi function because the trailing behavior is pretty ingrained into my expectations. Note that I'm not a X.Prompt user or anything, so feel free to ignore this message; I'll probably forget about it until I use X.Prompt, if ever. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPly/pAAoJEKaxavVX4C1XSfcP/2YucyNS5BcZWx/6uq8s+SHC LkBFfocb+SYjh7DumI/lp3TI4OfhUymgxvYAVwJin6BPvq0ojeRbt+XVr+pSWHiE y66ltVaJvY7jZBcowoIWqX/rubnbfJbyc8hj6ftvD25fXZ/rydhaXKPFfpEr3ggE qj3Jlq3BgNGOkdtX9ey7hK3tg/o/TTl5MugY9ys0syqlxXATh4RT/qbvRbhsI0zP nvdjlpx09bLRBRM9qWZAy4Ty+4HP3wM3Ab5gcKPf8+Zt+XHgBGP0PmcWghb66ITS GH/q7G2HXQIgKdZB5mkIQZhyzocjiX5DAukznFEMTFj7twkPR7nnrdeYqBQ7Idt0 0s3yH8bU1OYZda53nMLGFVTzTFQV+JHSnQbBrvAF5PqQ7cVZwRZb7EOir4fCkM5H o2u03wbJwNlZSq5Pssux9LqWTszfaHTh9/Z3z8JHaXU98nDxFDQkYl1VEEVMPoqy dgELZ76CxqYYT5eaYLS1gxI52lu4sIr3rm5uhipQgj4gWbN+Po3aNcLsBqDd3BMy UV2EoCQPEbj5dbvrBICDp5fglIYykcfx9gBp1Yq9TfFJDaYjW31YLRVsbkI1lmeq 6adBDIS88XsUM3kgOpQ9szKNeaOUpHKb0jxfKYfdm4jsMviW+FePbVfqpnDyATLg TU7u3AEHDVNU10351BHT =/BMg -----END PGP SIGNATURE-----

Aleksandar Dimitrov

25 Apr 25 Apr

3:21 a.m.

...

I realized today that the behavior of killWord from XMonad.Prompt is surprising to me. In particular, when you iterate killWord, it deletes first a word, then a space, then the next word, then the next space, and so on. I (an emacs user) expect killWord to delete a word AND any whitespace that happens to come before it. (Hmm... I tested with vim and it seems that 'dw' deletes a word along with any TRAILING whitespace. So emacs and vim differ here... but the point is that killWord emulates neither.)

Vim in insert mode acts like Emacs if you hit ^W, which, I think is more relevant here, since you're in "insert mode" when using XPrompt (just like when you use ex-mode in Vim after hitting ':') and there's no "command mode."

...

diff -rN old-XMonadContrib/XMonad/Prompt.hs new-XMonadContrib/XMonad/Prompt.hs 525,528c525 < delNextWord w = < case w of < ' ':x -> x < word -> snd . break isSpace $ word ---

...
delNextWord = snd . break isSpace . dropWhile isSpace

Thoughts?

As others have said, dropping in a parameter for isSpace would be nice, or at least making it something like:

...

liftM2 (||) isSpace (=='/')

One of my reasons for switching to zsh was that when I had punched in a long path and made a mistake in the last segment of it, I might hit ^W, but then bash deletes the entire path with no possibility of undo! zsh only deletes up to the '/', which I prefer greatly. Cheers, Aleks

Justin Bogner

26 Apr 26 Apr

1:19 a.m.

Aleksandar Dimitrov writes:

...

One of my reasons for switching to zsh was that when I had punched in a long path and made a mistake in the last segment of it, I might hit ^W, but then bash deletes the entire path with no possibility of undo! zsh only deletes up to the '/', which I prefer greatly.

I don't mean to detract from your point, but bash does in fact have undo! It's the same as emacs', which is to say, fairly odd but almost mnemonic: ^_

Aleksandar Dimitrov

3:57 a.m.

On Wed, Apr 25, 2012 at 11:19:33PM -0600, Justin Bogner wrote:

...

Aleksandar Dimitrov writes:

...
One of my reasons for switching to zsh was that when I had punched in a long path and made a mistake in the last segment of it, I might hit ^W, but then bash deletes the entire path with no possibility of undo! zsh only deletes up to the '/', which I prefer greatly.

I don't mean to detract from your point, but bash does in fact have undo! It's the same as emacs', which is to say, fairly odd but almost mnemonic: ^_

Well, that'll save me some headaches next time I'm forced to use bash. Thanks! I guess I should've googled it… But XPrompt *doesn't* have undo, so I'd still love to see some sort of delimiting ^W on something else than just whitespace. Cheers, Aleks

Chris Jones

5:07 a.m.

On Wed, Apr 25, 2012 at 03:21:51AM EDT, Aleksandar Dimitrov wrote: [..]

...

One of my reasons for switching to zsh was that when I had punched in a long path and made a mistake in the last segment of it, I might hit ^W, but then bash deletes the entire path with no possibility of undo! zsh only deletes up to the '/', which I prefer greatly.

I don't know how zsh handles it but it's not bash/readline that deletes the entire path - or IOW, uses space only as the word separator.. | $ stty -a | | intr = ^C; (...) werase = ^W; lnext = ^V; ... Here, in bash/readline, I see <CTRL-ALT-h> mapped to backward-kill-word, which also uses the slash as a word separator. I assume it's the default binding. For more information: | $ bind -p | less | $ help bind | $ man readline Also,, note that you can use <CTRL-Y> to yank back something you deleted by accident via <CTRL-W>. CJ -- WHAT YOU SAY??

Brent Yorgey

9:53 a.m.

On Wed, Apr 25, 2012 at 09:21:51AM +0200, Aleksandar Dimitrov wrote:

...

Vim in insert mode acts like Emacs if you hit ^W, which, I think is more relevant here, since you're in "insert mode" when using XPrompt (just like when you use ex-mode in Vim after hitting ':') and there's no "command mode."

Ah, good to know.

...

As others have said, dropping in a parameter for isSpace would be nice, or at least making it something like:

...
liftM2 (||) isSpace (=='/')

One of my reasons for switching to zsh was that when I had punched in a long path and made a mistake in the last segment of it, I might hit ^W, but then bash deletes the entire path with no possibility of undo! zsh only deletes up to the '/', which I prefer greatly.

Hah, I use zsh but have always been annoyed how it deletes a whole path when I do backwards-kill-word! So I did a bit of googling and discovered the WORDCHARS environment variable. =) In any case, based on the feedback so far I think what I will do is (1) change killWord to have emacs-like behavior (2) add a variant killWordUsingSep which takes a separator predicate as a parameter, to be used instead of isSpace. -Brent

Brent Yorgey

10 May 10 May

1:46 p.m.

OK, I just pushed this patch: Thu May 10 13:43:17 EDT 2012 Brent Yorgey * updates to XMonad.Prompt re: word-oriented commands + change killWord and moveWord to have emacs-like behavior: first move past/kill consecutive whitespace, then move past/kill consecutive non-whitespace. + create variants killWord' and moveWord' which take a predicate specifying non-word characters. + create variants defaultXPKeymap' and emacsLikeXPKeymap' which take the same sort of predicate, which is applied to all keybindings with word-oriented commands. My config now looks something like myXPConfig = defaultXPConfig { fgColor = "#a8a3f7" , bgColor = "#3f3c6d" , promptKeymap = emacsLikeXPKeymap' myWordSep } myWordSep :: Char -> Bool myWordSep c = isSpace c || c == '/' Enjoy! -Brent On Tue, Apr 24, 2012 at 10:07:57AM -0400, Brent Yorgey wrote:

...

I realized today that the behavior of killWord from XMonad.Prompt is surprising to me. In particular, when you iterate killWord, it deletes first a word, then a space, then the next word, then the next space, and so on. I (an emacs user) expect killWord to delete a word AND any whitespace that happens to come before it. (Hmm... I tested with vim and it seems that 'dw' deletes a word along with any TRAILING whitespace. So emacs and vim differ here... but the point is that killWord emulates neither.)

I looked into it and it turns out that the behavior of killWord is even sillier than I thought. It deletes an entire word of non-whitespace characters *or a single space*. (So if there are multiple spaces you have to call killWord once for each space before you finally get to delete the word that comes after.) And if the next character is a tab it doesn't delete anything at all!

For concreteness, here's the change I made:

diff -rN old-XMonadContrib/XMonad/Prompt.hs new-XMonadContrib/XMonad/Prompt.hs 525,528c525 < delNextWord w = < case w of < ' ':x -> x < word -> snd . break isSpace $ word ---

...
delNextWord = snd . break isSpace . dropWhile isSpace

Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two.

-Brent

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

4761

Age (days ago)

4777

Last active (days ago)

List overview

Download

10 comments

8 participants

participants (8)

Aleksandar Dimitrov
Ben Boeckel
Brent Yorgey
Chris Jones
Justin Bogner
Mike Meyer
Norbert Zeh
wagnerdm＠seas.upenn.edu