emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CEDET/senator kill the buffer-local value of isearch-search-fun-function


From: Tassilo Horn
Subject: CEDET/senator kill the buffer-local value of isearch-search-fun-function (was: isearch for doc-view.el)
Date: Mon, 05 Nov 2007 17:42:49 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> I'm trying to implement that now, but I have some problems with it.
>> I set isearch-search-fun-function buffer-locally to
>> doc-view-isearch-function in doc-view-mode.  If I describe this
>> variable in a doc-view buffer, it says it hat the desired value.  But
>> when I hit C-s to start isearch and edebug isearch-search-fun it
>> shows up that isearch-search-fun-function is nil then.  But why is
>> that?
>
> Don't know.  It seems to work more or less here.

Here it does not.

I have the same problem with e.g. longlines-mode, which sets
isearch-search-fun-function buffer-locally, too.  Here's what I do.

,----
| 1. C-x C-f somefile
| 2. M-x longlines-mode
| 3. C-h v isearch-search-fun-function => longlines-search-function
| 4. C-s foo C-g
| 5. C-h v isearch-search-fun-function => nil
`----

If I edebug-defun isearch-search-string before I start step 4 I can see
that the value of isearch-search-fun-function already is nil in that
function.

However, I can only reproduce this with `emacs -q', not with `emacs -Q',
so it seems some addon package I have installed causes this problem.

Ok, now I found the culprit by grepping all sources of the addon
packages I use.  It is CEDET (1.0_pre4).  In senator.el there's some
setting and killing of the buffer-local value of
isearch-search-fun-function.  I deinstalled cedet, and now it works.

Eric, can you have a look at this?

> (other than an error because the pdf->png sentinel called
> doc-view-search...  with 0 args).

Thanks, I deleted this.

> Also avoid the set-buffer....set-buffer style: use with-current-buffer
> instead, it's cleaner and more robust.

Of course, you're right.

Bye,
Tassilo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]