bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

Recipe from 'emacs -Q':
  C-h r C-s e M-s o

The header line of the *Occur* buffer contains garbage.  It should
simply say:
  <n> matches in <m> lines for "e"


In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-07-31 on LEG570
Repository revision: 8d332aeccab2208e6c6bd434738565e6abf12043
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252


-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Eli Zaretskii]

> Date: Sat, 1 Aug 2015 14:22:06 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> Recipe from 'emacs -Q':
>   C-h r C-s e M-s o
> 
> The header line of the *Occur* buffer contains garbage.

It's not garbage, it shows you the regexp it searched for.  It might
be confusing at first sight, but it isn't garbage.

> It should simply say:
>   <n> matches in <m> lines for "e"

But it didn't search for "e", it searched for the regexp that is
shown.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

On Sat, Aug 1, 2015 at 2:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 1 Aug 2015 14:22:06 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>>
>> Recipe from 'emacs -Q':
>>   C-h r C-s e M-s o
>>
>> The header line of the *Occur* buffer contains garbage.
>
> It's not garbage, it shows you the regexp it searched for.  It might
> be confusing at first sight, but it isn't garbage.
>
>> It should simply say:
>>   <n> matches in <m> lines for "e"
>
> But it didn't search for "e", it searched for the regexp that is
> shown.

Yes, the regexp.  I suspected that, and I still made the bug report,
because IMO, a user who makes a simple (non-regexp) Isearch doesn't
care about the implementation details such as the internal regexp used
to perform the actual search.  Therefore, in that sense it is garbage.

Showing that long string there is plain ridiculous, IMO.

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Eli Zaretskii]

> Date: Sat, 1 Aug 2015 14:57:49 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 21176@debbugs.gnu.org
> 
> > But it didn't search for "e", it searched for the regexp that is
> > shown.
> 
> Yes, the regexp.  I suspected that, and I still made the bug report,
> because IMO, a user who makes a simple (non-regexp) Isearch doesn't
> care about the implementation details such as the internal regexp used
> to perform the actual search.  Therefore, in that sense it is garbage.
> 
> Showing that long string there is plain ridiculous, IMO.

Would you also submit a bug report if one of the matches was è or ĕ or
ⓔ?

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

On Sat, Aug 1, 2015 at 3:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 1 Aug 2015 14:57:49 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: 21176@debbugs.gnu.org
>>
>> > But it didn't search for "e", it searched for the regexp that is
>> > shown.
>>
>> Yes, the regexp.  I suspected that, and I still made the bug report,
>> because IMO, a user who makes a simple (non-regexp) Isearch doesn't
>> care about the implementation details such as the internal regexp used
>> to perform the actual search.  Therefore, in that sense it is garbage.
>>
>> Showing that long string there is plain ridiculous, IMO.
>
> Would you also submit a bug report if one of the matches was è or ĕ or
> ⓔ?

Yes, I would, because the _search string_ (i.e. the string supplied by
the user to search for) was just "e", not a regexp.

The fact that "è", "ĕ" or "ⓔ" can be matches in this case is due to
the combination of (a) the search string, _plus_ (b) the current
Isearch options (char-fold enabled in this case).

So, the header line of *Occur* buffers could perhaps show, in addition
to the search string, some Isearch options -- like the Isearch prompt
string does.  But showing that huge, auto-generated regexp in place of
the original search string makes little sense, IMO.

--
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Juri Linkov]

> The fact that "è", "ĕ" or "ⓔ" can be matches in this case is due to
> the combination of (a) the search string, _plus_ (b) the current
> Isearch options (char-fold enabled in this case).

Also you could try ‘M-s w text M-s o’ and see:

  1 match for "\<text\>" in buffer: *scratch*

where the search regexp includes additional \<...\>, etc.
What do you expect in this case?

> So, the header line of *Occur* buffers could perhaps show, in addition
> to the search string, some Isearch options -- like the Isearch prompt
> string does.  But showing that huge, auto-generated regexp in place of
> the original search string makes little sense, IMO.

Maybe the Occur header should be the same as Isearch message,
but this requires closer integration between Isearch and Occur.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

>> The fact that "è", "ĕ" or "ⓔ" can be matches in this case is due to
>> the combination of (a) the search string, _plus_ (b) the current
>> Isearch options (char-fold enabled in this case).
>
> Also you could try ‘M-s w text M-s o’ and see:
>
>   1 match for "\<text\>" in buffer: *scratch*
>
> where the search regexp includes additional \<...\>, etc.
> What do you expect in this case?

As I said in my last mail: just show the original search string
provided by the user ("text" in this example) and perhaps the search
options that were active at the moment of populating the *Occur*
buffer (word-type-search or something like that in this example).

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Stefan Monnier]

> Maybe the Occur header should be the same as Isearch message,
> but this requires closer integration between Isearch and Occur.

That would make a lot of sense,


        Stefan

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Angelo Graziosi]

Eli Zaretskii wrote:
> Would you also submit a bug report if one of the matches was è or ĕ or
> ⓔ?

I don't understand why, if one search for 'e', it will report all those 
other matches..

I fully concord with Dani's analysis. The end user (who often does not 
even know the meaning of the word 'regexp') will consider all that 
"garbage" (including the recent "Char-fold"... What does it mean?)

This has just the result to keep people away from Emacs...


Angelo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Alexis]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> (including the recent "Char-fold"... What does it mean?)
>
> This has just the result to keep people away from Emacs...

Not me. i appreciate the ongoing efforts to continue to improve 
Emacs' support for multiple scripts and languages.

In particular, assuming i understand the in-development 
'char-fold' functionality correctly - and i might not be! - i can 
immediately imagine uses for it. If i'm searching a 
German-language text file for the word 'grün', which i know has 
occasionally been spelled as 'gruen', it would be useful to be 
able to use 'char-fold' to find both forms. Similarly, it would be 
useful to be able to do a search to find all instances of either 
TM or ™. That is, in terms of Unicode, i would find it useful to 
be able to find all forms of compatible code point sequences.

Others' Mileage May Vary.


Alexis.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

FWIW: I love the "char-fold search" feature.  I find it very useful
and powerful.

This bug report is just about the header line of the *Occur* buffer.

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

>> Would you also submit a bug report if one of the matches was è or ĕ or
>> ⓔ?
>
>
> I don't understand why, if one search for 'e', it will report all those
> other matches..

If you want to search for 'e', literally, you can disable the
"char-fold" search option.  For example typing [M-s '] during the
Isearch session.

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

>> Maybe the Occur header should be the same as Isearch message,
>> but this requires closer integration between Isearch and Occur.
>
> That would make a lot of sense,

This bug (which is merged with bug 21180) seems to be fixed.  Why is
it still open?  Should we close it?

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Glenn Morris]

Dani Moncayo wrote:

> This bug (which is merged with bug 21180) seems to be fixed.  Why is
> it still open?  Should we close it?

This project is drowning in bug reports.
I wish people would be more "aggressive" about closing them.
If you think something is fixed, close it!
It doesn't stop further discussion, and it's trivial to reopen things.
People aren't shy of saying something is still a problem, but they are
shy of closing things.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Juri Linkov]

>>> Maybe the Occur header should be the same as Isearch message,
>>> but this requires closer integration between Isearch and Occur.
>>
>> That would make a lot of sense,
>
> This bug (which is merged with bug 21180) seems to be fixed.  Why is
> it still open?  Should we close it?

Is it really fixed?  I still see the bug you reported.  But good news
is that now I'll have time to finish this before the feature freeze.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

> Is it really fixed?

I think so.

> I still see the bug you reported.

I don't.  With a build made on 2015-10-09 (last Friday), the recipe I
gave in my initial message gives a successful result: I see this text
in the header line of the *Occur* buffer:

  3824 matches in 856 lines for "e" in buffer: *info*

which IMO is fine.

>  But good news
> is that now I'll have time to finish this before the feature freeze.

If you see something that is still wrong, please go ahead.

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Juri Linkov]

>> Is it really fixed?
>
> I think so.
>
>> I still see the bug you reported.
>
> I don't.  With a build made on 2015-10-09 (last Friday), the recipe I
> gave in my initial message gives a successful result: I see this text
> in the header line of the *Occur* buffer:
>
>   3824 matches in 856 lines for "e" in buffer: *info*
>
> which IMO is fine.

I still see garbage that you reported with (setq character-fold-search t).

>>  But good news
>> is that now I'll have time to finish this before the feature freeze.
>
> If you see something that is still wrong, please go ahead.

While your bug report is closed, I can't fix it.

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Dani Moncayo]

> I still see garbage that you reported with (setq character-fold-search t).

Oh, I didn't notice that the default value of that variable was
changed to nil.  Then you're right - the bug isn't fixed yet.

> While your bug report is closed, I can't fix it.

Can't you?  The status of a bug report should not prevent you from
doing anything. ;)

Ok, I've just re-opened the bug report.

Thanks.

-- 
Dani Moncayo

bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers

[Juri Linkov]

>> I still see garbage that you reported with (setq character-fold-search t).
>
> Oh, I didn't notice that the default value of that variable was
> changed to nil.  Then you're right - the bug isn't fixed yet.
>
>> While your bug report is closed, I can't fix it.
>
> Can't you?  The status of a bug report should not prevent you from
> doing anything. ;)
>
> Ok, I've just re-opened the bug report.

Thanks, it's more comfortable to fix open bugs rather than closed :)

For this bug the only good solution I see is like in this patch:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4fc9b38..16ed9af 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1831,7 +1839,12 @@ (defun isearch-occur (regexp &optional nlines)
 		 isearch-regexp-lax-whitespace
 	       isearch-lax-whitespace)
 	     search-whitespace-regexp)))
-    (occur regexp nlines)))
+    (occur (if isearch-word
+	       (propertize regexp
+			   'isearch-string isearch-string
+			   'isearch-word-mode (isearch--describe-word-mode isearch-word))
+	     regexp)
+	   nlines)))
 
 (declare-function hi-lock-read-face-name "hi-lock" ())
 
diff --git a/lisp/replace.el b/lisp/replace.el
index 3a908ac..718499f 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -1657,8 +1657,12 @@ (defun occur-engine (regexp buffers out-buf nlines case-fold
 						  lines (if (= lines 1) "" "s")))
 				   ;; Don't display regexp for multi-buffer.
 				   (if (> (length buffers) 1)
-				       "" (format " for \"%s\""
-						  (query-replace-descr regexp)))
+				       "" (format " for %s\"%s\""
+                                                  (or (get-text-property 0 'isearch-word-mode regexp)
+                                                      "")
+                                                  (query-replace-descr
+                                                   (or (get-text-property 0 'isearch-string regexp)
+                                                       regexp))))
 				   (buffer-name buf))
 			   'read-only t))
 		  (setq end (point))