[slime-devel] Re: ?BUG? Re: repl history navigation and M-r

[Madhu]

	[f'p to myself]

* Madhu  <m3lkjmjsub.fsf at robolove.meer.net> :
| Helu, On Updating from CVS, I noticed that repl history is broken in
| the following way:
|
| Typing M-r REGEXP brings the previous matching history item in the repl.
| Immediately Typing M-r REGEXP <RET> again does not bring up an earlier
| history item as expected.
[...]
| So Currently, M-r can be used only to get at the most recent item in
| history matching REGEXP.and cannot be called successively.

The behaviour I reported is observed with GNU Emacs 21.4.1 (on
Debian).  It is not observed with GNU Emacs 22.0.91.1 where things are
according my expectations expressed in the above post.

On further investigation it turns out that
(slime-repl-history-search-in-progress-p) is always `nil' when
invoking `slime-repl-previous-matching-input' in emacs-21.

If I add a print statement to that function like this

  (defun slime-repl-history-search-in-progress-p ()
     (message "=>> %s" (list this-command last-command))
     (eq last-command 'slime-repl-history-replace))

And execute the following sequence of user actions at the repl buffer:

"foo" <RET>
"foo bar" <RET>
"foo bar car" <RET>
M-r f o o <RET>
M-r <up> <RET>


In the *Messages* buffer, with emacs21 I get:
  =>> (exit-minibuffer self-insert-command)

and in CVS emacs I get:
  =>> (slime-repl-previous-matching-input slime-repl-history-replace)


Which leads one to believe that depending on {this,last}-command
behaviour might be fragile.
--
Madhu