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#15839: 24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily Date: Fri, 8 Nov 2013 19:09:54 -0800 (PST) Message-ID: <2827fd34-4736-4583-a964-5bab51b6b2f1@default> References: <51df60b6-e152-4989-a27e-70dadb9b7474@default> <878uwyo0i4.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1383966681 15684 80.91.229.3 (9 Nov 2013 03:11:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2013 03:11:21 +0000 (UTC) Cc: 15839@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 09 04:11:25 2013 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 1VeyxI-0004Ba-Lj for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Nov 2013 04:11:24 +0100 Original-Received: from localhost ([::1]:54189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeyxI-0006HI-4U for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Nov 2013 22:11:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Veyx5-0006Fz-5D for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2013 22:11:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Veyww-0000od-Ev for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2013 22:11:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Veyww-0000oX-AU for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2013 22:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Veywv-0008V4-Sv for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2013 22:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2013 03:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15839 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15839-submit@debbugs.gnu.org id=B15839.138396660832607 (code B ref 15839); Sat, 09 Nov 2013 03:11:01 +0000 Original-Received: (at 15839) by debbugs.gnu.org; 9 Nov 2013 03:10:08 +0000 Original-Received: from localhost ([127.0.0.1]:43205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Veyw2-0008Tp-VQ for submit@debbugs.gnu.org; Fri, 08 Nov 2013 22:10:08 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17209) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Veyvy-0008TB-Hp for 15839@debbugs.gnu.org; Fri, 08 Nov 2013 22:10:03 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA939t4E024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Nov 2013 03:09:56 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA939tjN002851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Nov 2013 03:09:55 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA939sQR002842; Sat, 9 Nov 2013 03:09:54 GMT In-Reply-To: <878uwyo0i4.fsf@mail.jurta.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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: 140.186.70.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:80170 Archived-At: > > 1. Non-nil `isearch-allow-scroll' lets you use a scroll command > > (e.g. `C-v') without exiting Isearch. Unfortunately, this is > > coupled with the hard-coded behavior that you cannot scroll far > > enough in either direction that point would be moved off screen. >=20 > You can do what you want with just: > (advice-add 'isearch-post-command-hook :override (lambda ())) Good to know that. But see also the bug(s) mentioned below. Such advice will not suffice currently, for the reasons given there. There is neither the proper management of point nor the proper lazy highlighting of the scrolled area. But anyway, I am not looking for a way for an individual user to advise the code - in this case, dynamically neutering the post-command scrolling limitation code. That's not the point (besides not being very elegant). I am asking for a way for users to customize an option, namely the already existing option `isearch-allow-scroll'. I am asking for two scroll-allowing behaviors, giving users an easy choice. > And if you want more commands to escape this restriction: > (mapc (lambda (c) (put c 'isearch-scroll t)) > '(forward-char backward-char right-char left-char > forward-word backward-word right-word left-word > forward-sexp backward-sexp forward-paragraph backward- > paragraph > move-end-of-line end-of-visual-line move-beginning-of-line > beginning-of-visual-line next-line previous-line)) I'm not asking how to define additional scrolling commands. The problem is not insufficient commands that can scroll. The problem is the limitation of what the scrolling behavior is. > > That restriction is general for Emacs, and it generally makes > > sense. It does not necessarily make sense during Isearch, > > however. Why? Note the question (which I answered): Why does this restriction, which generally makes sense for general Emacs, NOT necessarily make sense for Isearch. Is this your answer to that question (?): > Because it is too confusing for users. This is like leaving point > in one place, and scrolling without changing the position of point > (with inactive Isearch). Isearch should not be different from the > default Emacs behavior. I gave a reason why it should be different. Or rather, why it should be allowed to be different (au choix). You gave no reason - you just repeated that it should be the same. At most, you gave the same reason as for Emacs in general, which I explained is not so relevant here. That is, it is not cut & dried. Some users can well prefer to be able to see more context, for the reasons I gave. And that is not so confusing as it is for general Emacs, for the reasons I gave - in particular, resumption from the same search position, with attendent automatic window return to that position. In Emacs in general, if scrolling moved beyond point, and if there were nothing that brought the window back to point when you acted at point (e.g., when finished temporarily scrolling) then you would not see what was happening at point. That would not be good at all, under any circumstances. But even in Emacs in general, if there were such an thing as=20 temporary scrolling, with a well defined finish, and if the window were then automatically restored to show point, which *did not change* by scrolling, that too would not be so confusing. We do not have such a temporary-scrolling behavior in Emacs in general, however. You cannot reasonably compare general Emacs, without any such temporary scrolling and window restoration, with what I proposed for Isearch. Apples & oranges. > > It's a bit like using `C-SPC' in a buffer, scrolling up a couple > > of screenfuls to look at something, and then using `C-u C-SPC' > > to return. But in Isearch there is no need for `C-SPC' or > > `C-u C-SPC': the search position is recorded. Search resumes > > from that same position, no matter how far away one might have > > scrolled. >=20 > It makes sense to resume search from a new position like you can > see using code above. I think you are suggesting that the search position should change when you make use of the temporary scrolling? If so, I strongly disagree. >From my point of view, the current search hit (i.e., point) does not change now, and it should never change, when you scroll. The only thing that would change with my proposal is what is shown in the window. The scrolling would be temporary, and when search is resumed the window would be restored to where it will show the current search hit again. What should happen if, after scrolling, a user quits Isearch? For that case we have a design choice: either move point to somewhere inside where the window is currently (scrolled), or move the window back to show the current search hit, i.e., point (which has not changed). I would be in favor of the latter. I think the former possibility would be problematic. Move point to which position in the window, for instance? I'm open to suggestions about that. But a priori, I would suggest that in all cases when scrolling is done during Isearch the window be restored to show the current search hit. I feel more strongly about resumption of search after scrolling: it should definitely continue where it was. I think (less strongly) that if search is quit after scrolling then the behavior should be the same as quitting at the current search position. > > The enhancement request is to let users choose whether non-nil > > `isearch-allow-scroll' should limit you to scrolling only enough > > to keep point in the window or should not limit you. This could > > be done by recognizing different non-nil values. >=20 > Maybe a new option of `isearch-allow-scroll' could allow this. That's exactly what I suggested. Non-nil always means allow scrolling, and the particular non-nil value would specify the scrolling behavior: limited or not. But see above and below about what unlimited scrolling behavior should be like (highlighting, and no change in point). =20 > > 2. What's more, the lazy highlighting of search hits is even more > > limited currently. When you scroll to the current limit, there > > can be lots of search hits that are not highlighted. >=20 > When scrolling outside the window boundaries will be allowed then > lazy highlighting should highlight the whole buffer so you could see > all matches when you quickly scroll the buffer. But in this case > lazy highlighting will become more like hi-lock mode. I cannot speak to the implementation - whether it is better to highlight the whole buffer or just the part that is currently visible. I would imagine that the latter is better, especially for large buffers. But I'm no expert on the implementation of Isearch. I can say that without the continuation of lazy highlighting into the scrolled area (e.g., what happens with your advice, above), there is little use to scrolling. The point of scrolling is, especially, to see search hits farther down or up the buffer. 3. I just noticed the following problem (emacs -Q). I can file a separate bug report for it, if you prefer. a. Set `isearch-allow-scroll' to t. b. Go to the middle of a long (multi-screenful) buffer, such as isearch.el. c. Search for something common, such as "ear". d. `C-v' a couple times, until you hit the limit. e. `M-v' repeatedly. There is no such limit in this direction. Why not? There should be. Not really consistent for the user. f. `C-v'. The entire window fills with face `isearch' (which should be only for `ear' search hits). Both (e) - its difference from (d) - and (f) seem like bugs to me. With my request (#1), both `C-v' and `M-v' would allow unlimited scrolling. And the current search position would not change by scrolling. It seems that currently `M-v' (past what should be the limit) changes the search position. Whether that's a third bug - call it (g) or is part of the (e) behavior I don't know. And that is also the behavior for `C-v' when I advise the post-command hook as you suggested: point is kept in the window, instead of staying at the current search hit. Isearch behavior should always be that point remains at the current search hit. IMO, when scrolling is restricted, that restriction should apply to both `C-v' and `M-v', and the search position should not change. When scrolling is not restricted (request #1), that non-restriction should apply to both `C-v' and `M-v', and the search position should (still) not change.