From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Date: Mon, 31 Aug 2015 14:35:31 -0700 (PDT) Message-ID: <719ef340-0997-40fe-b1d8-c20c2a69155e@default> References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441056985 30926 80.91.229.3 (31 Aug 2015 21:36:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Aug 2015 21:36:25 +0000 (UTC) Cc: 21092@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 31 23:36:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWWkO-0000Ud-3B for geb-bug-gnu-emacs@m.gmane.org; Mon, 31 Aug 2015 23:36:12 +0200 Original-Received: from localhost ([::1]:41238 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWWkO-0008Rb-00 for geb-bug-gnu-emacs@m.gmane.org; Mon, 31 Aug 2015 17:36:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWWkJ-0008RR-93 for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2015 17:36:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWWkE-0007H2-7l for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2015 17:36:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWWkE-0007Gu-4R for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2015 17:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZWWkD-0008Rr-Qn for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2015 17:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2015 21:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21092 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21092-submit@debbugs.gnu.org id=B21092.144105693832431 (code B ref 21092); Mon, 31 Aug 2015 21:36:01 +0000 Original-Received: (at 21092) by debbugs.gnu.org; 31 Aug 2015 21:35:38 +0000 Original-Received: from localhost ([127.0.0.1]:44175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWWjq-0008R0-3n for submit@debbugs.gnu.org; Mon, 31 Aug 2015 17:35:38 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43762) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWWjm-0008Qp-A6 for 21092@debbugs.gnu.org; Mon, 31 Aug 2015 17:35:35 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7VLZWMs005982 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Aug 2015 21:35:33 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7VLZW5J028679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 21:35:32 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7VLZW5h011455; Mon, 31 Aug 2015 21:35:32 GMT In-Reply-To: <87y4grw7kx.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106024 Archived-At: > > You clearly do not want this done. >=20 > Not at all. I only disagree that it's a bug. Good to hear. But it sure didn't sound like it: J >>> There is no need to highlight all matches in the buffer J >>> during Isearch. E >> What if someone wants to? J > Why would someone want such a strange thing? Anyway, I'm glad you agree now that such a strange thing can be useful. > =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 is just an optimization va= riable > along with =E2=80=98lazy-highlight-initial-delay=E2=80=99, =E2=80=98lazy-= highlight-interval=E2=80=99 > that users might want to tweak to improve performance where nil of > =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 allows highlighting in one= loop > that avoids delays on fast processors (it makes sense to change > its default value to nil to match the modern hardware). >=20 > A new feature to highlight the whole buffer would be useful as well > to reduce flickering during Isearch. Currently when e.g. scrolling > by one line lazy-highlight clears all matches on the screen, and > re-highlights them with an additional line taken into account. > That's because lazy-highlight is non-incremental. Whole buffer OR rest-of-buffer forward or backward. Au choix. Both behaviors are useful. > Highlighting the whole buffer could fix this visual effect. > So unlike the current screen-limited lazy-highlighting that reacts > to window-start/window-end changes, once whole-buffer lazy-highlighting > finds all matches in the buffer it doesn't need to re-highlight them > during Isearch navigation. >=20 > A new option could be named e.g. (defcustom lazy-highlight-buffer nil) > Again, its default value is depending on the average hardware. > While I believe that highlighting all matches on the screen > is suitable for most users, I'm not sure about highlighting > all matches in a (possibly large) buffer in one loop. It's not clear how you see the two options interacting (or not). If you are telling Isearch to highlight all matches and you are also telling it to highlight at most 10, for example. And what about the current nil value of `lazy-highlight-max-at-a-time', which also says (currently) that it means highlight "all"? Not clear why you want a separate option for this. It cannot be used in combination with `lazy-highlight-max-at-a-time', can it? If the behaviors are mutually exclusive, then why not just add another value or two for `lazy-highlight-max-at-a-time'? A second question concerns how to control whether this acts only in the current search direction or in both directions. In the patch I sent, a user gets all matches in the search direction. If s?he wants all matches in both directions it is enough to briefly hit the other direction key (e.g. hit `C-r' if searching forward). The use I make of the all-matches behavior will be togglable,=20 and I will want to control what the behaviors toggled are. For exmaple, I might want a toggle between max=3D10 and whole-buffer. Or between whole-buffer and remainder-of-buffer (in search direction). > > whether it's searching within the active region (not needed, > > since a user can always narrow the buffer); > > Because it's more useful to extend the bounds of the active > region using Isearch. Dunno what that means. Please elaborate. And please say why you think it is always more useful than limiting search to the region. Whatever you mean by it, why should it be a question only of design-time either-or? In Isearch+, limitation of search to the active region is optional, and you can change the behavior anytime on the fly (toggle `C-x n'). (Deactivation of the active region is also optional.) > > search within text- or overlay-property zones; >=20 > There is an unfinished feature request bug#15245. On-demand replacement of search hits is available in Isearch+. At the time I replied in that bug thread, I guess I had not yet added this feature. It seems I added it a month after I posted there. Anyway, that too is available. AFAIK, with Isearch+ you can do all that is requested in the bug. And as you say in the bug thread, you can also limit `query-replace' to such text zones using `isearch-filter-predicate'. > > on-demand replacement of search hits during search >=20 > Can you find a bug# for this? It's not a bug, AFAIK. It's an Isearch+ feature. http://www.emacswiki.org/emacs/IsearchPlus#isearchp-replace-on-demand You can perform an arbitrary action on the current search hit, on demand. By default, the action is replacement. > > Please at least fix the doc so that it matches what the > > code does, whether or not that matches what the original > > intention was. >=20 > Then the docstring could point to the new option > =E2=80=98lazy-highlight-buffer=E2=80=99. See above. I'm all for adding the ability to highlight beyond the current window, and I am glad to hear you are also for it. But it's unclear why a separate option should be used, instead of additional option values for `lazy-highlight-max-at-a-time'. And it's unclear how a user can get up-to-the-buffer/region-limit behavior in one direction only.