* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers @ 2015-08-01 12:22 Dani Moncayo 2015-08-01 12:44 ` Eli Zaretskii 2015-08-04 12:05 ` Angelo Graziosi 0 siblings, 2 replies; 19+ messages in thread From: Dani Moncayo @ 2015-08-01 12:22 UTC (permalink / raw) To: 21176 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 12:22 bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers Dani Moncayo @ 2015-08-01 12:44 ` Eli Zaretskii 2015-08-01 12:57 ` Dani Moncayo 2015-08-04 12:05 ` Angelo Graziosi 1 sibling, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2015-08-01 12:44 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 12:44 ` Eli Zaretskii @ 2015-08-01 12:57 ` Dani Moncayo 2015-08-01 13:23 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dani Moncayo @ 2015-08-01 12:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21176 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 12:57 ` Dani Moncayo @ 2015-08-01 13:23 ` Eli Zaretskii 2015-08-01 15:01 ` Dani Moncayo 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2015-08-01 13:23 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 > 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 ⓔ? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 13:23 ` Eli Zaretskii @ 2015-08-01 15:01 ` Dani Moncayo 2015-08-02 20:34 ` Juri Linkov 0 siblings, 1 reply; 19+ messages in thread From: Dani Moncayo @ 2015-08-01 15:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21176 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 15:01 ` Dani Moncayo @ 2015-08-02 20:34 ` Juri Linkov 2015-08-03 6:41 ` Dani Moncayo 2015-08-03 21:49 ` Stefan Monnier 0 siblings, 2 replies; 19+ messages in thread From: Juri Linkov @ 2015-08-02 20:34 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-02 20:34 ` Juri Linkov @ 2015-08-03 6:41 ` Dani Moncayo 2015-08-03 21:49 ` Stefan Monnier 1 sibling, 0 replies; 19+ messages in thread From: Dani Moncayo @ 2015-08-03 6:41 UTC (permalink / raw) To: Juri Linkov; +Cc: 21176 >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-02 20:34 ` Juri Linkov 2015-08-03 6:41 ` Dani Moncayo @ 2015-08-03 21:49 ` Stefan Monnier 2015-10-10 7:56 ` Dani Moncayo 1 sibling, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2015-08-03 21:49 UTC (permalink / raw) To: Juri Linkov; +Cc: 21176 > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-03 21:49 ` Stefan Monnier @ 2015-10-10 7:56 ` Dani Moncayo 2015-10-11 0:40 ` Glenn Morris 2015-10-12 20:21 ` Juri Linkov 0 siblings, 2 replies; 19+ messages in thread From: Dani Moncayo @ 2015-10-10 7:56 UTC (permalink / raw) To: 21176 >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-10 7:56 ` Dani Moncayo @ 2015-10-11 0:40 ` Glenn Morris 2015-10-12 20:21 ` Juri Linkov 1 sibling, 0 replies; 19+ messages in thread From: Glenn Morris @ 2015-10-11 0:40 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-10 7:56 ` Dani Moncayo 2015-10-11 0:40 ` Glenn Morris @ 2015-10-12 20:21 ` Juri Linkov 2015-10-12 21:05 ` Dani Moncayo 1 sibling, 1 reply; 19+ messages in thread From: Juri Linkov @ 2015-10-12 20:21 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 >>> 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-12 20:21 ` Juri Linkov @ 2015-10-12 21:05 ` Dani Moncayo 2015-10-13 22:05 ` Juri Linkov 0 siblings, 1 reply; 19+ messages in thread From: Dani Moncayo @ 2015-10-12 21:05 UTC (permalink / raw) To: Juri Linkov; +Cc: 21176 > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-12 21:05 ` Dani Moncayo @ 2015-10-13 22:05 ` Juri Linkov 2015-10-13 22:25 ` Dani Moncayo 0 siblings, 1 reply; 19+ messages in thread From: Juri Linkov @ 2015-10-13 22:05 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 >> 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-13 22:05 ` Juri Linkov @ 2015-10-13 22:25 ` Dani Moncayo 2015-10-14 16:09 ` Juri Linkov 0 siblings, 1 reply; 19+ messages in thread From: Dani Moncayo @ 2015-10-13 22:25 UTC (permalink / raw) To: Juri Linkov; +Cc: 21176 > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-10-13 22:25 ` Dani Moncayo @ 2015-10-14 16:09 ` Juri Linkov 0 siblings, 0 replies; 19+ messages in thread From: Juri Linkov @ 2015-10-14 16:09 UTC (permalink / raw) To: Dani Moncayo; +Cc: 21176 >> 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)) ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-01 12:22 bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers Dani Moncayo 2015-08-01 12:44 ` Eli Zaretskii @ 2015-08-04 12:05 ` Angelo Graziosi 2015-08-04 12:32 ` Alexis 2015-08-04 12:50 ` Dani Moncayo 1 sibling, 2 replies; 19+ messages in thread From: Angelo Graziosi @ 2015-08-04 12:05 UTC (permalink / raw) To: 21176 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-04 12:05 ` Angelo Graziosi @ 2015-08-04 12:32 ` Alexis 2015-08-04 12:44 ` Dani Moncayo 2015-08-04 12:50 ` Dani Moncayo 1 sibling, 1 reply; 19+ messages in thread From: Alexis @ 2015-08-04 12:32 UTC (permalink / raw) To: 21176 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-04 12:32 ` Alexis @ 2015-08-04 12:44 ` Dani Moncayo 0 siblings, 0 replies; 19+ messages in thread From: Dani Moncayo @ 2015-08-04 12:44 UTC (permalink / raw) To: 21176 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers 2015-08-04 12:05 ` Angelo Graziosi 2015-08-04 12:32 ` Alexis @ 2015-08-04 12:50 ` Dani Moncayo 1 sibling, 0 replies; 19+ messages in thread From: Dani Moncayo @ 2015-08-04 12:50 UTC (permalink / raw) To: Angelo Graziosi; +Cc: 21176 >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-10-14 16:09 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-01 12:22 bug#21176: 25.0.50; Garbage in the header line of *Occur* buffers Dani Moncayo 2015-08-01 12:44 ` Eli Zaretskii 2015-08-01 12:57 ` Dani Moncayo 2015-08-01 13:23 ` Eli Zaretskii 2015-08-01 15:01 ` Dani Moncayo 2015-08-02 20:34 ` Juri Linkov 2015-08-03 6:41 ` Dani Moncayo 2015-08-03 21:49 ` Stefan Monnier 2015-10-10 7:56 ` Dani Moncayo 2015-10-11 0:40 ` Glenn Morris 2015-10-12 20:21 ` Juri Linkov 2015-10-12 21:05 ` Dani Moncayo 2015-10-13 22:05 ` Juri Linkov 2015-10-13 22:25 ` Dani Moncayo 2015-10-14 16:09 ` Juri Linkov 2015-08-04 12:05 ` Angelo Graziosi 2015-08-04 12:32 ` Alexis 2015-08-04 12:44 ` Dani Moncayo 2015-08-04 12:50 ` Dani Moncayo
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).