bug#37496: 27.0.50; C-s failing to search

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

I have noticed that C-s, including C-M-s is failing to search. And this
happens in all buffers. It is strange. I have not changed any settings
in the mean time.

I was using mostly Dired buffers, and C-x C-q to edit Dired buffers,
that is what I remember.

I do not know how to reproduce this. Emasc daemon was running less than
24 hours.


In GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-09-07 built on protected.rcdrun.com
Repository revision: 40eb4c51a40a37c14e882e6db3f880ba4528c089
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Hyperbola GNU/Linux-libre

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/package/text/emacs-2019-09-07 --with-modules
 --without-gpm --with-x-toolkit=lucid
 PKG_CONFIG_PATH=/home/data1/protected/GNUstep/Library/Libraries/pkgconfig:/usr/lib/pkgconfig'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_ALL: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 45545 5459)
 (symbols 48 6065 1)
 (strings 32 16272 1429)
 (string-bytes 1 520161)
 (vectors 16 9862)
 (vector-slots 8 127481 6466)
 (floats 8 22 18)
 (intervals 56 243 0)
 (buffers 992 12))

-- 
Thanks,
Jean Louis

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> From: Jean Louis <bugs@gnu.support>
> Date: Tue, 24 Sep 2019 11:51:52 +0200
> 
> 
> I have noticed that C-s, including C-M-s is failing to search. And this
> happens in all buffers. It is strange. I have not changed any settings
> in the mean time.
> 
> I was using mostly Dired buffers, and C-x C-q to edit Dired buffers,
> that is what I remember.
> 
> I do not know how to reproduce this. Emasc daemon was running less than
> 24 hours.

What does "C-h l" say after you press those searching keys?

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-24 12:39]:
> > From: Jean Louis <bugs@gnu.support>
> > Date: Tue, 24 Sep 2019 11:51:52 +0200
> > 
> > 
> > I have noticed that C-s, including C-M-s is failing to search. And this
> > happens in all buffers. It is strange. I have not changed any settings
> > in the mean time.
> > 
> > I was using mostly Dired buffers, and C-x C-q to edit Dired buffers,
> > that is what I remember.
> > 
> > I do not know how to reproduce this. Emasc daemon was running less than
> > 24 hours.
> 
> What does C-h l say after you press those searching keys?

At this moment I cannot reproduce as I restarted the daemon.

Jean

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-24 12:39]:
> > From: Jean Louis <bugs@gnu.support>
> > Date: Tue, 24 Sep 2019 11:51:52 +0200
> > 
> > 
> > I have noticed that C-s, including C-M-s is failing to search. And
> > this happens in all buffers. It is strange. I have not changed any
> > settings in the mean time.
> > 
> > I was using mostly Dired buffers, and C-x C-q to edit Dired
> > buffers, that is what I remember.
> > 
> > I do not know how to reproduce this. Emasc daemon was running less
> > than 24 hours.
> 
> What does C-h l say after you press those searching keys?

It is happening again. I did nothing special, did not change any
settings. Suddenly I cannot search any more in any of the
buffers. This is serious bug.

I just know that I was often using within Dired C-x C-q to edit files
in Dired, and often quit with C-c C-c, that is what I can remember
being somewhat unusual. Now I cannot search, and I do not know what to
do else but to restart daemon.

I will keep this way for a while if you have some idea on how to find
what is wrong here.

;; isearch-printing-char
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 <s-up>			;; windmove-up
 <next>			;; scroll-up-command
 C-x 1			;; delete-other-windows
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 <up>			;; previous-line
 C-x 2			;; split-window-below
 <s-down>		;; windmove-down
 q			;; quit-window
 <s-down>		;; windmove-down
 ^			;; dired-up-directory
 <s-up>			;; windmove-up
 <s-down>		;; windmove-down
 ^			;; dired-up-directory
 ^			;; dired-up-directory
 ^			;; dired-up-directory
 +			;; dired-create-directory
 G			;; self-insert-command
 e			;; self-insert-command
 o			;; self-insert-command
 r			;; self-insert-command
 g			;; self-insert-command
 e			;; self-insert-command
 SPC			;; self-insert-command
 J			;; self-insert-command
 o			;; self-insert-command
 h			;; self-insert-command
 n			;; self-insert-command
 s			;; self-insert-command
 o			;; self-insert-command
 n			;; self-insert-command
 <return>		;; exit-minibuffer
 C-s			;; isearch-forward
 G			;; isearch-printing-char
 e			;; isearch-printing-char
 o			;; isearch-printing-char
 r			;; isearch-printing-char
 g			;; isearch-printing-char
 e			;; isearch-printing-char
 SPC			;; isearch-printing-char
 J			;; isearch-printing-char
 o			;; isearch-printing-char
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 C-s			;; isearch-forward
 J			;; isearch-printing-char
 o			;; isearch-printing-char
 h			;; isearch-printing-char
 n			;; isearch-printing-char
 s			;; isearch-printing-char
 o			;; isearch-printing-char
 n			;; isearch-printing-char
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 M-<			;; beginning-of-buffer
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 <down>			;; dired-next-line
 C-c C-c		;; nil
 C-g			;; keyboard-quit
 C-g			;; keyboard-quit
 <up>			;; dired-previous-line
 <up>			;; dired-previous-line
 <up>			;; dired-previous-line
 <up>			;; dired-previous-line
 <up>			;; dired-previous-line
 <up>			;; dired-previous-line
 C-s			;; isearch-forward
 J			;; isearch-printing-char
 o			;; isearch-printing-char
 h			;; isearch-printing-char
 n			;; isearch-printing-char
 s			;; isearch-printing-char
 o			;; isearch-printing-char
 n			;; isearch-printing-char
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 C-x 1			;; delete-other-windows
 C-s			;; isearch-forward
 C-g			;; isearch-abort
 C-g			;; keyboard-quit
 C-h l			;; view-lossage
 C-s			;; isearch-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 C-x 1			;; delete-other-windows
 C-s			;; isearch-forward
 G			;; isearch-printing-char
 e			;; isearch-printing-char
 o			;; isearch-printing-char
 r			;; isearch-printing-char
 g			;; isearch-printing-char
 e			;; isearch-printing-char
 SPC			;; isearch-printing-char
 J			;; isearch-printing-char
 o			;; isearch-printing-char
 h			;; isearch-printing-char
 n			;; isearch-printing-char
 s			;; isearch-printing-char
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-s			;; isearch-repeat-forward
 C-g			;; isearch-abort
 C-g			;; isearch-abort
 C-h l			;; view-lossage

[back]

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Wed, 25 Sep 2019 22:45:22 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> > > I have noticed that C-s, including C-M-s is failing to search. And
> > > this happens in all buffers. It is strange. I have not changed any
> > > settings in the mean time.
> > > 
> > > I was using mostly Dired buffers, and C-x C-q to edit Dired
> > > buffers, that is what I remember.
> > > 
> > > I do not know how to reproduce this. Emasc daemon was running less
> > > than 24 hours.
> > 
> > What does C-h l say after you press those searching keys?
> 
> It is happening again. I did nothing special, did not change any
> settings. Suddenly I cannot search any more in any of the
> buffers. This is serious bug.
> 
> I just know that I was often using within Dired C-x C-q to edit files
> in Dired, and often quit with C-c C-c, that is what I can remember
> being somewhat unusual. Now I cannot search, and I do not know what to
> do else but to restart daemon.
> 
> I will keep this way for a while if you have some idea on how to find
> what is wrong here.

I see nothing wrong, though.  The "C-h l" output says that C-s does
invoke isearch-forward.  So maybe you should describe in much more
detail what keys you type and what happens as result that makes you
unable to search.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-26 09:03]:
> I see nothing wrong, though.  The C-h l output says that C-s does
> invoke isearch-forward.  So maybe you should describe in much more
> detail what keys you type and what happens as result that makes you
> unable to search.

I invoke C-s, and there is minibuffer, I am entering any term and no
term can be found in any of the buffers. I can also see that it fails
to find wrapped search, for any term, any letter or few letters or any
word. Also regular expression search does not work.

What I can say is that I am doing a lot of editing with Wdired and
that before, when I was not doing much with Wdired, I have never seen
this taking place.

Jean

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 26 Sep 2019 09:22:13 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> I invoke C-s, and there is minibuffer, I am entering any term and no
> term can be found in any of the buffers.

Even if you create a new buffer with "C-x b", type some text into it,
and then try to search for that text in that buffer?

> What I can say is that I am doing a lot of editing with Wdired and
> that before, when I was not doing much with Wdired, I have never seen
> this taking place.

Could be related to isearch-filter-predicate set up by wdired.el,
perhaps?

My first suggestion is to stop using Wdired for a while, and see if
the problem never happens then.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-26 09:40]:
> > Date: Thu, 26 Sep 2019 09:22:13 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > I invoke C-s, and there is minibuffer, I am entering any term and no
> > term can be found in any of the buffers.
> 
> Even if you create a new buffer with C-x b, type some text into it,
> and then try to search for that text in that buffer?

Yes, in any buffer or new file and buffer. It happened twice in last
days, and I know that I was editing with Wdired so much.


> > What I can say is that I am doing a lot of editing with Wdired and
> > that before, when I was not doing much with Wdired, I have never seen
> > this taking place.
> 
> Could be related to isearch-filter-predicate set up by wdired.el,
> perhaps?

That I cannot know, I would solve it if I would know it.

> My first suggestion is to stop using Wdired for a while, and see if
> the problem never happens then.

I am always using Emacs and I never got this problem before, I would
otherwise report it, right? No need to stop using Wdired to find out
if it happens, as that has been determined that it does not happen by
my previous historical usage of Emacs.

I cannot say what invokes it, I just know that I am using a lot C-x
C-q and C-c C-c and also "q" to exit Dired buffer and a lot of "^" to
go to upper directory. And just by my changed usage of Emacs in last
few days where I am editing a lot of file names and directories, I can
estimate that it relates to Wdired or Dired. And I do a lot of
searches one after the other.

Jean

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 26 Sep 2019 09:50:54 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> > Could be related to isearch-filter-predicate set up by wdired.el,
> > perhaps?
> 
> That I cannot know, I would solve it if I would know it.

You could edebug-defun in wdired-isearch-filter-read-only, and see if
it gets invoked when you type C-s, and if so, whether it somehow
thinks every search hit is to be skipped.  Can you do that?

> > My first suggestion is to stop using Wdired for a while, and see if
> > the problem never happens then.
> 
> I am always using Emacs and I never got this problem before, I would
> otherwise report it, right? No need to stop using Wdired to find out
> if it happens, as that has been determined that it does not happen by
> my previous historical usage of Emacs.

I'm not convinced, because there could be other factors at work here.

You asked for help in getting this problem tracked down, and I'm
asking you to help that process by stopping to use Wdired for a
while.  I have no other ideas for how to debug this, so if you are
unwilling to try what I'm asking, I don't know how to make any
progress here.

> I cannot say what invokes it, I just know that I am using a lot C-x
> C-q and C-c C-c and also "q" to exit Dired buffer and a lot of "^" to
> go to upper directory. And just by my changed usage of Emacs in last
> few days where I am editing a lot of file names and directories, I can
> estimate that it relates to Wdired or Dired. And I do a lot of
> searches one after the other.

Yes, I understand.  But there's not enough data here to give a clue of
the potential reasons.

Thanks.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-26 10:07]:
> You could edebug-defun in wdired-isearch-filter-read-only, and see if
> it gets invoked when you type C-s, and if so, whether it somehow
> thinks every search hit is to be skipped.  Can you do that?

When it happens, that I just invokie (edebug-defun) in the buffer?

Let me say that search is lost after doing my activities, and I do not
search during editing of Dired buffers, so not that I attempted it
during Wdired. Usually I finish Wdired with C-c C-c and then I move to
some other directory.

I will try to invoke edebug, but how to invoke it exactly?

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 26 Sep 2019 10:54:34 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> I will try to invoke edebug, but how to invoke it exactly?

First, load wdired.el (NOT wdired.elc!) manually with

   M-x load-library RET wdired.el RET

Then visit the wdired.el file with "C-x 5 f", go to the definition of
wdired-isearch-filter-read-only function, and with point anywhere
inside its definition type

   M-x edebug-defun RET

(Visiting wdired.el in a separate frame will make sure the buffer
where you invoke C-s will remain on display even if Edebug kicks in
and lets you step through the code of wdired-isearch-filter-read-only,
because Edebug will then use that other frame and leave alone the
frame where your buffer is displayed.)

Now invoke C-s.  If this displays the arrow on the left fringe of the
window where wdired.el is shown, it means that function was indeed
called.  In that case, step through the function by repeatedly
pressing SPC -- each SPC press will move to the next line -- and see
what happens there.

The expected and correct result is that either
wdired-isearch-filter-read-only is not called at all, or it is called
and returns non-nil.  If it is called and returns nil, it is the
reason why you don't find anything, because that makes Isearch skip
the match.

Thanks.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-26 11:51]:
> > Date: Thu, 26 Sep 2019 10:54:34 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > I will try to invoke edebug, but how to invoke it exactly?
> 
> First, load wdired.el (NOT wdired.elc!) manually with
> 
>    M-x load-library RET wdired.el RET
> 
> Then visit the wdired.el file with C-x 5 f, go to the definition of
> wdired-isearch-filter-read-only function, and with point anywhere
> inside its definition type
> 
>    M-x edebug-defun RET
> 
> (Visiting wdired.el in a separate frame will make sure the buffer
> where you invoke C-s will remain on display even if Edebug kicks in
> and lets you step through the code of wdired-isearch-filter-read-only,
> because Edebug will then use that other frame and leave alone the
> frame where your buffer is displayed.)
> 
> Now invoke C-s.  If this displays the arrow on the left fringe of the
> window where wdired.el is shown, it means that function was indeed
> called.  In that case, step through the function by repeatedly
> pressing SPC -- each SPC press will move to the next line -- and see
> what happens there.

I have tried this but I did not see nothing happening, no debug,
something wrong on my side. I am waiting for that to happen again so
that I try this again.

Jean

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Sat, 28 Sep 2019 13:06:44 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> I have tried this but I did not see nothing happening, no debug,
> something wrong on my side. I am waiting for that to happen again so
> that I try this again.

If Edebug doesn't kick in, it might mean the
wdired-isearch-filter-read-only function is not invoked in this
scenario, i.e. my theory is incorrect, and some other factor is at
work here.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-28 14:13]:
> > Date: Sat, 28 Sep 2019 13:06:44 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > I have tried this but I did not see nothing happening, no debug,
> > something wrong on my side. I am waiting for that to happen again so
> > that I try this again.
> 
> If Edebug doesn't kick in, it might mean the
> wdired-isearch-filter-read-only function is not invoked in this
> scenario, i.e. my theory is incorrect, and some other factor is at
> work here.

Am I in wdired if I finish editing with C-c C-c ?

Search is not working in any buffers, or newly created buffers,
overall search stops working. When that happens I am not in Wdired. I
just say I used often Wdired before it happenes.

Jean

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Sat, 28 Sep 2019 14:19:18 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> > If Edebug doesn't kick in, it might mean the
> > wdired-isearch-filter-read-only function is not invoked in this
> > scenario, i.e. my theory is incorrect, and some other factor is at
> > work here.
> 
> Am I in wdired if I finish editing with C-c C-c ?

I don't know, and I don't think it matters.

> Search is not working in any buffers, or newly created buffers,
> overall search stops working. When that happens I am not in Wdired. I
> just say I used often Wdired before it happenes.

Yes, I understand that much.  My theory was that somehow the isearch
filter set by Wdired stays in effect even after you exit Wdired, and
that the filter somehow decides that every search match should be
skipped.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-28 15:41]:
> > > If Edebug doesn't kick in, it might mean the
> > > wdired-isearch-filter-read-only function is not invoked in this
> > > scenario, i.e. my theory is incorrect, and some other factor is at
> > > work here.
> > 
> > Am I in wdired if I finish editing with C-c C-c ?
> 
> I don't know, and I don't think it matters.
> 
> > Search is not working in any buffers, or newly created buffers,
> > overall search stops working. When that happens I am not in Wdired. I
> > just say I used often Wdired before it happenes.
> 
> Yes, I understand that much.  My theory was that somehow the isearch
> filter set by Wdired stays in effect even after you exit Wdired, and
> that the filter somehow decides that every search match should be
> skipped.

Alright, I hope it will happen again to try edebugging.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-09-26 11:51]:
> > Date: Thu, 26 Sep 2019 10:54:34 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > I will try to invoke edebug, but how to invoke it exactly?
> 
> First, load wdired.el (NOT wdired.elc!) manually with
> 
>    M-x load-library RET wdired.el RET
> 
> Then visit the wdired.el file with C-x 5 f, go to the definition of
> wdired-isearch-filter-read-only function, and with point anywhere
> inside its definition type
> 
>    M-x edebug-defun RET
> 
> (Visiting wdired.el in a separate frame will make sure the buffer
> where you invoke C-s will remain on display even if Edebug kicks in
> and lets you step through the code of wdired-isearch-filter-read-only,
> because Edebug will then use that other frame and leave alone the
> frame where your buffer is displayed.)
> 
> Now invoke C-s.  If this displays the arrow on the left fringe of the
> window where wdired.el is shown, it means that function was indeed
> called.  In that case, step through the function by repeatedly
> pressing SPC -- each SPC press will move to the next line -- and see
> what happens there.
> 
> The expected and correct result is that either
> wdired-isearch-filter-read-only is not called at all, or it is called
> and returns non-nil.  If it is called and returns nil, it is the
> reason why you don't find anything, because that makes Isearch skip
> the match.
> 
> Thanks.


I could not edebug-defun on wdired-isearch-filter-read-only, nothing
was happening.

I could do edebug-defun on isearch-forward or C-s and then I got this
below:

Debugger entered: nil
  edebug--display-1(nil 0 before)
  edebug--display(nil 0 before)
  edebug-debugger(0 before nil)
  edebug-before(0)
  (edebug-after (edebug-before 0) 9 (isearch-mode t (edebug-after (edebug-before 1) 5 (not (edebug-after (edebug-before 2) 4 (null (edebug-after 0 3 regexp-p))))) nil (edebug-after (edebug-before 6) 8 (not (edebug-after 0 7 no-recursive-edit)))))
  (closure ((no-recursive-edit . 1) (regexp-p) t) nil (edebug-after (edebug-before 0) 9 (isearch-mode t (edebug-after (edebug-before 1) 5 (not (edebug-after (edebug-before 2) 4 (null (edebug-after 0 3 regexp-p))))) nil (edebug-after (edebug-before 6) 8 (not (edebug-after 0 7 no-recursive-edit))))))()
  edebug-default-enter(isearch-forward (nil 1) (closure ((no-recursive-edit . 1) (regexp-p) t) nil (edebug-after (edebug-before 0) 9 (isearch-mode t (edebug-after (edebug-before 1) 5 (not (edebug-after (edebug-before 2) 4 (null ...)))) nil (edebug-after (edebug-before 6) 8 (not (edebug-after 0 7 no-recursive-edit)))))))
  edebug-default-enter(isearch-forward (nil 1) (closure ((no-recursive-edit . 1) (regexp-p) t) nil (edebug-after (edebug-before 0) 9 (isearch-mode t (edebug-after (edebug-before 1) 5 (not (edebug-after (edebug-before 2) 4 (null ...)))) nil (edebug-after (edebug-before 6) 8 (not (edebug-after 0 7 no-recursive-edit)))))))
  edebug-enter(isearch-forward (nil 1) (closure ((no-recursive-edit . 1) (regexp-p) t) nil (edebug-after (edebug-before 0) 9 (isearch-mode t (edebug-after (edebug-before 1) 5 (not (edebug-after (edebug-before 2) 4 (null ...)))) nil (edebug-after (edebug-before 6) 8 (not (edebug-after 0 7 no-recursive-edit)))))))
  isearch-forward(nil 1)
  funcall-interactively(isearch-forward nil 1)
  call-interactively(isearch-forward nil nil)
  command-execute(isearch-forward)

And I have observed that the isearch-forward stopped functioning after
doing not so many editing with C-x C-q, just few. Suddenly I got the
problem again.

Jean

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 3 Oct 2019 20:32:12 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> I could do edebug-defun on isearch-forward or C-s and then I got this
> below:
> 
> Debugger entered: nil
>   edebug--display-1(nil 0 before)
>   edebug--display(nil 0 before)
>   edebug-debugger(0 before nil)
>   edebug-before(0)

What commands did you type that yielded this backtrace?

> And I have observed that the isearch-forward stopped functioning after
> doing not so many editing with C-x C-q, just few. Suddenly I got the
> problem again.

"C-x C-q" in what mode?  Which command does it run?

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-10-03 20:57]:
> > Date: Thu, 3 Oct 2019 20:32:12 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > I could do edebug-defun on isearch-forward or C-s and then I got this
> > below:
> > 
> > Debugger entered: nil
> >   edebug--display-1(nil 0 before)
> >   edebug--display(nil 0 before)
> >   edebug-debugger(0 before nil)
> >   edebug-before(0)
> 
> What commands did you type that yielded this backtrace?

I have turned on edebug-defun on isearch-forward as that is the key
binding on C-s and then I got the above.

> > And I have observed that the isearch-forward stopped functioning after
> > doing not so many editing with C-x C-q, just few. Suddenly I got the
> > problem again.
> 
> C-x C-q in what mode?  Which command does it run?

In Dired, when I do C-x C-q it invokes dired-toggle-read-only then I
edit the file names in Dired. Sometimes after editing then I cannot
search any more.

I have observed that I could search from menu Edit - Search String
Forward, that one worked well. Only C-s did not work.

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 3 Oct 2019 21:14:33 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> > C-x C-q in what mode?  Which command does it run?
> 
> In Dired, when I do C-x C-q it invokes dired-toggle-read-only then I
> edit the file names in Dired. Sometimes after editing then I cannot
> search any more.

Can you try C-x C-q followed by editing file names in "emacs -Q"?  I'm
trying to establish whether it's just Wdired or are there some other
factor(s) at work here.

Thanks.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-10-03 21:47]:
> > Date: Thu, 3 Oct 2019 21:14:33 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > > C-x C-q in what mode?  Which command does it run?
> > 
> > In Dired, when I do C-x C-q it invokes dired-toggle-read-only then I
> > edit the file names in Dired. Sometimes after editing then I cannot
> > search any more.
> 
> Can you try C-x C-q followed by editing file names in emacs -Q?  I'm
> trying to establish whether it's just Wdired or are there some other
> factor(s) at work here.

I will try next time. I cannot invoke the bug, it just happens
suddenly. I will try though.

bug#37496: 27.0.50; C-s failing to search

[Eli Zaretskii]

> Date: Thu, 3 Oct 2019 21:51:05 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 37496@debbugs.gnu.org
> 
> > Can you try C-x C-q followed by editing file names in emacs -Q?  I'm
> > trying to establish whether it's just Wdired or are there some other
> > factor(s) at work here.
> 
> I will try next time. I cannot invoke the bug, it just happens
> suddenly. I will try though.

Thanks.  Also, I presume your editing in Wdired entails just ordinary
changes of file names?  Or do you do there something else?  IOW, could
you try describing a typical sequence of commands in Wdired that you
usually do?  I tried just invoking Wdired several times, and of course
the problem didn't happen for me, so I wonder (assuming Wdired is the
culprit) whether there's something special I should do.

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-10-04 09:17]:
> > Date: Thu, 3 Oct 2019 21:51:05 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 37496@debbugs.gnu.org
> > 
> > > Can you try C-x C-q followed by editing file names in emacs -Q?  I'm
> > > trying to establish whether it's just Wdired or are there some other
> > > factor(s) at work here.
> > 
> > I will try next time. I cannot invoke the bug, it just happens
> > suddenly. I will try though.
> 
> Thanks.  Also, I presume your editing in Wdired entails just
> ordinary changes of file names?  Or do you do there something else?
> IOW, could you try describing a typical sequence of commands in
> Wdired that you usually do?  I tried just invoking Wdired several
> times, and of course the problem didn't happen for me, so I wonder
> (assuming Wdired is the culprit) whether there's something special I
> should do.

I was just editing file names, then quitting with C-c C-c and often
pressing ^^ to go to upper directory. I have normally two windows,
from one I move the files to the other one

Sometimes I forget to press C-c C-c, then I notice it and press it,
but could not observe how the bug is invoked.

bug#37496: 27.0.50; C-s failing to search

[Juri Linkov]

> I was just editing file names, then quitting with C-c C-c and often
> pressing ^^ to go to upper directory. I have normally two windows,
> from one I move the files to the other one
>
> Sometimes I forget to press C-c C-c, then I notice it and press it,
> but could not observe how the bug is invoked.

Next time you encounter this problem please try running this diagnostics
with just 'M-x isearch-diagnostics RET' in the buffer where isearch fails:

(defun isearch-diagnostics ()
  (interactive)
  (let* ((variables
          '(major-mode
            buffer-read-only
            isearch-mode
            isearch-success
            isearch-error
            isearch-wrapped
            isearch-adjusted
            isearch-suspended
            isearch-regexp
            isearch-case-fold-search
            isearch-invisible
            isearch-hidden
            isearch-allow-scroll
            isearch-search-fun-function
            isearch-wrap-function
            isearch-push-state-function
            isearch-mode-hook
            isearch-update-post-hook
            isearch-mode-end-hook
            isearch-filter-predicate
            dired-isearch-filenames
            dired-isearch-filenames-mode))
         (diagnostics
          (concat
           (mapconcat
            (lambda (v)
              (format "%s: %s %s" v
                      (cl-prin1-to-string (and (boundp v) (buffer-local-value v (current-buffer))))
                      (cl-prin1-to-string (and (boundp v) (default-value v)))))
            variables "\n")
           (format "\nany read-only: %S\n" (text-property-any (point-min) (point-max) 'read-only t)))))
    (display-buffer
     (with-current-buffer (get-buffer-create "*isearch-diagnostics*")
       (erase-buffer)
       (insert diagnostics)
       (current-buffer)))))

From what I see wdired doesn't restore a previous value of isearch-filter-predicate.
This is fine as long as there are no read-only properties kept in the
Dired buffer, but it seems in your case read-only properties might be
still present after finishing Wdired-mode.  If you can reproduce the bug
please also try the following patch that could fix it:

diff --git a/lisp/wdired.el b/lisp/wdired.el
index 44f083bb7f..35f1b5ebbd 100644
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -357,6 +357,8 @@ wdired-change-to-dired-mode
     (remove-text-properties
      (point-min) (point-max)
      '(front-sticky nil rear-nonsticky nil read-only nil keymap nil)))
+  (remove-function (local 'isearch-filter-predicate)
+                   #'wdired-isearch-filter-read-only)
   (use-local-map dired-mode-map)
   (force-mode-line-update)
   (setq buffer-read-only t)

bug#37496: 27.0.50; C-s failing to search

[Jean Louis]

Dear Juri,

Thank you much for M-x isearch-diagnostics function. I am keeping it
ready for case that I get into problem again. I was editing 600
directories and many PDF file names inside, and there is yet left to
be edited, so I hope to encounter the same problem again.

I would not patch that now as I cannot reproduce the bug
intentionally, I can just hope it will happen again and would let you
all know.

Jean

* Juri Linkov <juri@linkov.net> [2019-10-07 21:01]:
> Next time you encounter this problem please try running this diagnostics
> with just 'M-x isearch-diagnostics RET' in the buffer where isearch fails:
> 
> (defun isearch-diagnostics ()
>   (interactive)
>   (let* ((variables
>           '(major-mode
>             buffer-read-only
>             isearch-mode
>             isearch-success
>             isearch-error
>             isearch-wrapped
>             isearch-adjusted
>             isearch-suspended
>             isearch-regexp
>             isearch-case-fold-search
>             isearch-invisible
>             isearch-hidden
>             isearch-allow-scroll
>             isearch-search-fun-function
>             isearch-wrap-function
>             isearch-push-state-function
>             isearch-mode-hook
>             isearch-update-post-hook
>             isearch-mode-end-hook
>             isearch-filter-predicate
>             dired-isearch-filenames
>             dired-isearch-filenames-mode))
>          (diagnostics
>           (concat
>            (mapconcat
>             (lambda (v)
>               (format "%s: %s %s" v
>                       (cl-prin1-to-string (and (boundp v) (buffer-local-value v (current-buffer))))
>                       (cl-prin1-to-string (and (boundp v) (default-value v)))))
>             variables "\n")
>            (format "\nany read-only: %S\n" (text-property-any (point-min) (point-max) 'read-only t)))))
>     (display-buffer
>      (with-current-buffer (get-buffer-create "*isearch-diagnostics*")
>        (erase-buffer)
>        (insert diagnostics)
>        (current-buffer)))))
> 
> From what I see wdired doesn't restore a previous value of isearch-filter-predicate.
> This is fine as long as there are no read-only properties kept in the
> Dired buffer, but it seems in your case read-only properties might be
> still present after finishing Wdired-mode.  If you can reproduce the bug
> please also try the following patch that could fix it:
> 
> diff --git a/lisp/wdired.el b/lisp/wdired.el
> index 44f083bb7f..35f1b5ebbd 100644
> --- a/lisp/wdired.el
> +++ b/lisp/wdired.el
> @@ -357,6 +357,8 @@ wdired-change-to-dired-mode
>      (remove-text-properties
>       (point-min) (point-max)
>       '(front-sticky nil rear-nonsticky nil read-only nil keymap nil)))
> +  (remove-function (local 'isearch-filter-predicate)
> +                   #'wdired-isearch-filter-read-only)
>    (use-local-map dired-mode-map)
>    (force-mode-line-update)
>    (setq buffer-read-only t)
> 

bug#37496: 27.0.50; C-s failing to search

[Juri Linkov]

tags 37496 fixed
close 37496 27.0.60
thanks

>>From what I see wdired doesn't restore a previous value of isearch-filter-predicate.
> This is fine as long as there are no read-only properties kept in the
> Dired buffer, but it seems in your case read-only properties might be
> still present after finishing Wdired-mode.  If you can reproduce the bug
> please also try the following patch that could fix it:
>
> diff --git a/lisp/wdired.el b/lisp/wdired.el
> index 44f083bb7f..35f1b5ebbd 100644
> --- a/lisp/wdired.el
> +++ b/lisp/wdired.el
> @@ -357,6 +357,8 @@ wdired-change-to-dired-mode
>      (remove-text-properties
>       (point-min) (point-max)
>       '(front-sticky nil rear-nonsticky nil read-only nil keymap nil)))
> +  (remove-function (local 'isearch-filter-predicate)
> +                   #'wdired-isearch-filter-read-only)
>    (use-local-map dired-mode-map)
>    (force-mode-line-update)
>    (setq buffer-read-only t)

I'm pretty sure this patch fixes the bug, so I installed it to emacs-27
and closed.  Please reopen if you encounter the same bug again.