a recent checkin to cvs eliminated a very useful (ymmv) feature: M-r and M-s behaved just like C-s when it was sequently pressed more then once.
i use that feature more than anything in the repl navigation. was it intentional?
Helu * "Attila Lendvai" b54b34af0701141454g238654f6m26e5c8f04e16d8ae@XXXX : | | [1 <text/plain; UTF-8 (base64)>] | a recent checkin to cvs eliminated a very useful (ymmv) feature: M-r | and M-s behaved just like C-s when it was sequently pressed more then | once.
[I haven't updated in a while so I still get this behaviour -- with this behaviour, I dont know how to handle this scenario: Type a few characters, press M-r a few times getting a few matches, and _then_ modify the regexp being searched for, without having to start over]
May I suggest adding a contrib.el file or a contrib/ directory in the main repository in which typical customizations/variants/add-ons (useful in the view of the authors) can be collected. This might help keeping basic slime lean.
(Perhaps this M-r M-s issue might be a good starting point)
-- Madhu
| [1 <text/plain; UTF-8 (base64)>] | a recent checkin to cvs eliminated a very useful (ymmv) feature: M-r | and M-s behaved just like C-s when it was sequently pressed more then | once.
[I haven't updated in a while so I still get this behaviour -- with this behaviour, I dont know how to handle this scenario: Type a few characters, press M-r a few times getting a few matches, and _then_ modify the regexp being searched for, without having to start over]
an arrow key (in fact any other key then M-r), M-r again (history position is not reset), M-p for history in the minibuffer and modify the regexp. not as cool as C-s but good enough without a lot of extra code.
Helu, On Updated 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.
Note: the search through history is not complete.
Typically the second time I type M-r, I uparrow and modify/refine the REGEXP for searching backwards from the point of the earlier search.
So Currently, M-r can be used only to get at the most recent item in history matching REGEXP.and cannot be called successively.
(M-r is bound to slime-repl-previous-matching-input)
slime-history-repl-map is no longer present. I have not spent the time to understand the new mechanism yet, and thought I'd ask here first How is the new repl history mechanism meant to be used? Perhaps I'm missing something?
-- Regards Madhu
* "Attila Lendvai" b54b34af0701160442i2de472a6ja9409129b957e125@XXX : |> | a recent checkin to cvs eliminated a very useful (ymmv) feature: M-r |> | and M-s behaved just like C-s when it was sequently pressed more then |> | once. |> |> [I haven't updated in a while so I still get this behaviour -- with |> this behaviour, I dont know how to handle this scenario: Type a few |> characters, press M-r a few times getting a few matches, and _then_ |> modify the regexp being searched for, without having to start over] | | an arrow key (in fact any other key then M-r), M-r again (history | position is not reset), M-p for history in the minibuffer and modify | the regexp. not as cool as C-s but good enough without a lot of extra | code.
slime-history-repl-map is no longer present. I have not spent the time to understand the new mechanism yet, and thought I'd ask here first How is the new repl history mechanism meant to be used? Perhaps I'm missing something?
as you've probably read in my previous inquiry mail, there was a refactor of the repl navigation in the official CVS and in the process some features have been removed and some bugs were introduced, especially regarding the M-r stuff. (C-g not working while reading a regexp, the double M-r feature was removed, C-up/down walks among the matches instead of uncoditionally stepping one, starting the repl history navigation does not jump to the prompt - some off the top of my head).
i've restored the removed features and fixed the bugs i've found. you can find the details here:
http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-wdim-slime;a=summa...
[f'p to myself]
* Madhu m3lkjmjsub.fsf@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
* Madhu [2007-01-29 06:38+0100] writes:
Helu, On Updated 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.
Expected by whom? Can't you press M-r REGEXP followed by M-p/M-n if you need the next item?
[unable to send email to cl.net]
* Helmut Eller m2d54xe76h.fsf@common-lisp.net :
| * Madhu [2007-01-29 06:38+0100] writes: | |> Helu, On Updated 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. | | Expected by whom? Can't you press M-r REGEXP followed by M-p/M-n if | you need the next item?
Did you See my detailed mesage Dated 29 Jan 2007 17:32:18 +0530 m3bqkinir9.fsf@robolove.meer.net
To answer yuor question, yes. But the BUG I'm reporting (under emacs21) is that typing M-r REGEXP and typing M-r REGEXP does not bring the previous MATCHING REGEXP up.
-- Madhu
In case I was not clear, To answer your question, under emacs 21, M-r REGEXP followed by M-p/M-n does not work as expected by you -- it does not bring the previous MATCHING item. It brings up the previous item.
-- Madhu
|> Helu, On Updated 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. | | Expected by whom? Can't you press M-r REGEXP followed by M-p/M-n if | you need the next item?
* Madhu [2007-01-30 02:43+0100] writes:
In case I was not clear, To answer your question, under emacs 21, M-r REGEXP followed by M-p/M-n does not work as expected by you -- it does not bring the previous MATCHING item. It brings up the previous item.
What Emacs version do you have? It brings up the previous item here in 20.7, 21.4.1 and 22.
* Helmut Eller 86fy9tgd7j.fsf@aragorn.online-marketwatch.com :
| What Emacs version do you have? It brings up the previous item here | in 20.7, 21.4.1 and 22.
It fails to bring the previous matching item in GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-03-17 on trouble, modified by Debian
even if started with -q -no-site-init.
I spent some time to track down the exact faiure point of your code and sent it in a different post in this thread.
-- Madhu
* Helmut Eller m2d54xe76h.fsf@common-lisp.net : | * Madhu [2007-01-29 06:38+0100] writes: | |> Helu, On Updated 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. | | Expected by whom? Can't you press M-r REGEXP followed by M-p/M-n if | you need the next item?
The behaviour described above is how emacs minibuffer history search works, and how the history search for comint modes work.
Slime's repl history search started off conforming to that behaviour but currently differs.
FWIW I'm attaching a file which has the definitions of Slime's original history functions from April 2006 which work when loaded on top of a current slime (Jul 2007) and revert the functionality to that era
-
Attila Lendvai -
Helmut Eller -
Madhu