isearch+ provoces error when starting eshell

isearch+ provoces error when starting eshell

[Gregor Zattler]

Dear Emacs developers, users, Drew,

in emacs24 when isearch+ is loaded, starting eshell gives:

byte-code: Key sequence C-c C-c starts with non-prefix key C-c

and somehow freezes.  It's possible to give a `ls' command but
not twice.

Minimal example:
emacs-snapshot -Q -nw -l ~/.emacs.d/elpa/isearch+-20130513.1521/isearch+.el -f eshell

There is no problem with emacs23:
emacs23 -Q -nw -l ~/.emacs.d/elpa/isearch+-20130513.1521/isearch+.el -f eshell
works as expected.


I don't know which part is to blame for the error.  Debugging
this is beyond my skills. 

Is this something I should file a bug report for?  Where?

Thanks for your attention, Gregor

RE: isearch+ provoces error when starting eshell

[Drew Adams]

> in emacs24 when isearch+ is loaded, starting eshell gives:
> byte-code: Key sequence C-c C-c starts with non-prefix key C-c
> and somehow freezes.  It's possible to give a `ls' command but
> not twice.
> 
> Minimal example:
> emacs-snapshot -Q -nw -l ~/.emacs.d/elpa/isearch+-20130513.1521/isearch+.el
> -f eshell
>
> Is this something I should file a bug report for?  Where?

Hi Gregor,

You can report Isearch+ problems to me directly.

I cannot reproduce the problem you see.  I tried the following with
Emacs 24.3 (on MS Windows), which should be equivalent to what you are
doing.  I don't know anything about `emacs-snapshot', or what that
Isearch version is in your elpa directory.  But I assume it is more or
less the same as what I have.

emacs -Q -nw -l "C:\mydir\isearch+.el" -f eshell

Likewise, if I use `emacs -Q -nw' and then load isearch+.el (or
isearch+.elc), and then do `M-x eshell'.

I can do C-c C-c and ls, any number of times each.

The only key bindings involving C-c in Isearch+ are these in
`isearch-mode-map' (which means they are in effect while searching,
i.e., after C-s).  They are each bound to `isearchp-yank-char':

C-c
C-y C-c

But your error message seems to come from the byte-compiler.
When I byte-compile isearch+.el in Emacs 24 I get no such error.
And if I then load isearch+.elc instead of .el, I see no difference.

I can think of two possibilities, neither of which seems like it
should really explain the problem you're seeing:

1. I neglected to include (eval-when-compile (require 'cl)) in the file.
I've just added it now and uploaded isearch+.el to Emacs Wiki, here:
http://www.emacswiki.org/emacs-en/download/isearch%2b.el
You might try that to see if it makes a difference (I doubt it).

2. I believe there have been some byte-compiler problems in some recent
Emacs development builds.  Perhaps that is the problem.  I'm by no means
sure there are any such problems, but I think I saw some messages about
it.  No idea whether, if there are some byte-compiler problems, they are
relevant to what you're seeing here.

Anyway, try loading the source file (not .elc) directly.  Try this, to
see if it makes any difference:

Delete isearch+.elc, so you use the source file.

emacs -Q -nw

Then `M-x load-file isearch+.el' in its directory (or ensure it is in
your `load-path' and use `load-library').

Then `M-x eshell' and the rest of your recipe (C-c C-c ls C-c C-c etc.).

Let me know if you make any progress.  Perhaps there is a bug in Emacs
or in isearch+.el, but so far I cannot repro what you see.  Sorry. 

bisected to commit since when this error occours (was: Re: isearch+ provoces error when starting eshell)

[Gregor Zattler]

[also to emacs-devel since it is perhaps a bug in gnu emacs]

Hi Drew, Emacs developers,
* Drew Adams <drew.adams@oracle.com> [31. May. 2013]:
>> in emacs24 when isearch+ is loaded, starting eshell gives:
>> byte-code: Key sequence C-c C-c starts with non-prefix key C-c
>> and somehow freezes.  It's possible to give a `ls' command but
>> not twice.
>> 
>> Minimal example:
>> emacs-snapshot -Q -nw -l ~/.emacs.d/elpa/isearch+-20130513.1521/isearch+.el -f eshell
>>
>> Is this something I should file a bug report for?  Where?

> You can report Isearch+ problems to me directly.
> 
> I cannot reproduce the problem you see.  I tried the following with
> Emacs 24.3 (on MS Windows), which should be equivalent to what you are
> doing.  

I built Emacs 24.3 from source and I confirm that this issue is not
present in Emacs 23 and Emacs 24.3.  I did a  git bisect  then
(see below).

> I don't know anything about `emacs-snapshot', 

it's a weekly release of Emacs trunk for debian and ubuntu.

> or what that
> Isearch version is in your elpa directory.  But I assume it is more or
> less the same as what I have.
> 
> emacs -Q -nw -l "C:\mydir\isearch+.el" -f eshell
> 
> Likewise, if I use `emacs -Q -nw' and then load isearch+.el (or
> isearch+.elc), and then do `M-x eshell'.
> 
> I can do C-c C-c and ls, any number of times each.
> 
> The only key bindings involving C-c in Isearch+ are these in
> `isearch-mode-map' (which means they are in effect while searching,
> i.e., after C-s).  They are each bound to `isearchp-yank-char':
> 
> C-c
> C-y C-c
> 
> But your error message seems to come from the byte-compiler.
> When I byte-compile isearch+.el in Emacs 24 I get no such error.
> And if I then load isearch+.elc instead of .el, I see no difference.
> 
> I can think of two possibilities, neither of which seems like it
> should really explain the problem you're seeing:
> 
> 1. I neglected to include (eval-when-compile (require 'cl)) in the file.
> I've just added it now and uploaded isearch+.el to Emacs Wiki, here:
> http://www.emacswiki.org/emacs-en/download/isearch%2b.el
> You might try that to see if it makes a difference (I doubt it).

I deleted isearch.elc and downloaded your newest version: same
problem with newest Emacs and not with emacs23 and 24.3.

> 2. I believe there have been some byte-compiler problems in some recent
> Emacs development builds.  Perhaps that is the problem.  I'm by no means
> sure there are any such problems, but I think I saw some messages about
> it.  No idea whether, if there are some byte-compiler problems, they are
> relevant to what you're seeing here.
> 
> Anyway, try loading the source file (not .elc) directly.  Try this, to
> see if it makes any difference:
> 
> Delete isearch+.elc, so you use the source file.
> 
> emacs -Q -nw
> 
> Then `M-x load-file isearch+.el' in its directory (or ensure it is in
> your `load-path' and use `load-library').
> 
> Then `M-x eshell' and the rest of your recipe (C-c C-c ls C-c C-c etc.).

I tried this and I even deleted eshell.elc but with the same
result (fail with newest emacs).  

> Let me know if you make any progress.  Perhaps there is a bug in Emacs
> or in isearch+.el, but so far I cannot repro what you see.  Sorry. 

I bisected the Emacs version history.  Result is:

ffc1d3e25cdae710e0f6057620af05c023a6e710 is the first bad commit
commit ffc1d3e25cdae710e0f6057620af05c023a6e710
Author: Glenn Morris <rgm@gnu.org>
Date:   Tue May 7 00:57:02 2013 -0700

    * lisp/eshell/em-hist.el (eshell-isearch-map): Initialize in the defvar.
    Remove explicit eshell-isearch-cancel-map.

This commit changes the keymap for eshell.  But I have no clue of
elisp and therefore am not in the position to judge if the commit
is wrong or if it exposes some bug in isearch+ or eshell.



Thanks for your attention, Gregor

RE: bisected to commit since when this error occours (was: Re: isearch+ provoces error when starting eshell)

[Drew Adams]

> [also to emacs-devel since it is perhaps a bug in gnu emacs]

Probably not a great idea, but I've left the cc for now.  If it
turns out that there is an Emacs problem we can file a bug report etc.

My guess, without looking (and I have no time to look now; sorry), 
is that there is no Emacs bug here, but that I need to update Isearch+
to accommodate whatever changes were made to Emacs.

I will take a look when I can (not too soon, I'm afraid). 

> I built Emacs 24.3 from source and I confirm that this issue is not
> present in Emacs 23 and Emacs 24.3.  I did a  git bisect  then
> (see below).
> 
> I bisected the Emacs version history.  Result is:
> 
> ffc1d3e25cdae710e0f6057620af05c023a6e710 is the first bad commit
> commit ffc1d3e25cdae710e0f6057620af05c023a6e710
> Author: Glenn Morris <rgm@gnu.org>
> Date:   Tue May 7 00:57:02 2013 -0700
> 
>     * lisp/eshell/em-hist.el (eshell-isearch-map): Initialize in the defvar.
>     Remove explicit eshell-isearch-cancel-map.
> 
> This commit changes the keymap for eshell.  But I have no clue of
> elisp and therefore am not in the position to judge if the commit
> is wrong or if it exposes some bug in isearch+ or eshell.

Thanks for narrowing things down.  That will help a lot, no doubt.
As I say, I will take a look when I can.

Perhaps someone from Emacs Dev will recognize an obvious bug introduced
by the changes you cite.  My guess is that there is no Emacs bug, but you
never know.  There might have also been some recent changes to isearch.el
and `isearch-mode-map' that affect this.  Dunno.

Re: bisected to commit since when this error occours (was: Re: isearch+ provoces error when starting eshell)

[Gregor Zattler]

Hi Drew, Emacs developers,
* Gregor Zattler <telegraph@gmx.net> [02. Jun. 2013]:
>>> in emacs24 when isearch+ is loaded, starting eshell gives:
>>> byte-code: Key sequence C-c C-c starts with non-prefix key C-c
>>> and somehow freezes.  It's possible to give a `ls' command but
>>> not twice.
>>> 
>>> Minimal example:
>>> emacs-snapshot -Q -nw -l ~/.emacs.d/elpa/isearch+-20130513.1521/isearch+.el -f eshell

> I bisected the Emacs version history.  Result is:
> 
> ffc1d3e25cdae710e0f6057620af05c023a6e710 is the first bad commit
> commit ffc1d3e25cdae710e0f6057620af05c023a6e710
> Author: Glenn Morris <rgm@gnu.org>
> Date:   Tue May 7 00:57:02 2013 -0700
> 
>     * lisp/eshell/em-hist.el (eshell-isearch-map): Initialize in the defvar.
>     Remove explicit eshell-isearch-cancel-map.
> 
> This commit changes the keymap for eshell.  But I have no clue of
> elisp and therefore am not in the position to judge if the commit
> is wrong or if it exposes some bug in isearch+ or eshell.

FWIW I reverted this commit on top of newest Emacs trunk: It
compiles fine, the error is gone and some testing did not show
any side effects but since I do not understand the commits intend
I could not really test if something's now missing... 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-