From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!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: Thu, 29 Nov 2018 16:27:13 -0800 (PST) Message-ID: <5a6a3254-f742-44e9-a498-b6d5a375a873@default> References: <51df60b6-e152-4989-a27e-70dadb9b7474@default> <8736rqgk6f.fsf@mail.linkov.net> <87y39gexdo.fsf@mail.linkov.net> <877egzmmyk.fsf@mail.linkov.net> <8af20443-841d-4211-99ae-269e042a9a33@default> <875zwidonq.fsf@mail.linkov.net> <178ca8ac-fb45-4cef-a48d-d916a60860be@default> <87a7lsu7rn.fsf@mail.linkov.net> <24e8fff5-67d8-49ac-801e-1e5f49d2037f@default> <875zwfed5h.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1543537579 25356 195.159.176.226 (30 Nov 2018 00:26:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 00:26:19 +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 Fri Nov 30 01:26:15 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSWdK-0006SY-Ey for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Nov 2018 01:26:14 +0100 Original-Received: from localhost ([::1]:57260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSWfQ-0007UO-W7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2018 19:28:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSWfH-0007TG-D8 for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2018 19:28:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSWf9-0006D1-IY for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2018 19:28:11 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51071) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gSWf4-00063V-Ih for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2018 19:28:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gSWf4-0002PO-Al for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2018 19:28: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: Fri, 30 Nov 2018 00:28:02 +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.15435376449210 (code B ref 15839); Fri, 30 Nov 2018 00:28:02 +0000 Original-Received: (at 15839) by debbugs.gnu.org; 30 Nov 2018 00:27:24 +0000 Original-Received: from localhost ([127.0.0.1]:55329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSWeS-0002OT-9B for submit@debbugs.gnu.org; Thu, 29 Nov 2018 19:27:24 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:32924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSWeQ-0002OC-Qy for 15839@debbugs.gnu.org; Thu, 29 Nov 2018 19:27:23 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAU0OXg1131644; Fri, 30 Nov 2018 00:27:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Tyvpl1DT302BX6rkcNKy+EVsRUAYNXC3qhSxYIas6d4=; b=D5XaVipJNtkIBYEeia/YMWeicPAL54Rdlf7zhYqsxwGqX9wg6gz5hBg6QwIl3ocdaYJZ 1aWl6yVHuHDZjX/Wq7OYqqvz41qDS3vcMc0r2iwkqRy0xsrf6MFrgO/Oec0xegcHepZM zhGJCy+04KY9FwveDFaaO6L/bJBEVabywR6EYLzC5cSUD0Ewa1Yey9/yMgJ6nZFUauzs KZaxzizq37XLFpa6jV+9QSwUaOgBYwD7ajoshnJKl/S+VyLQczWOwqsoQRq0z3ULq/zd UwjJnTJsXNBDsZyoty6FuFuopXE5F5e+OAxrJhKy1biB/sxIXq0XTretEs2q6ttYyWUy BQ== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2nxxkquasy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Nov 2018 00:27:16 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAU0RE45029192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Nov 2018 00:27:15 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAU0REM2013870; Fri, 30 Nov 2018 00:27:14 GMT In-Reply-To: <875zwfed5h.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4771.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9092 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811300001 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:152912 Archived-At: > > 1. I'm still puzzled about this: > > > > However, the current match will never scroll offscreen. > > If `unlimited', the current match can scroll offscreen. > > > > Those two sentences don't make sense together. > > If the current match never scrolls offscreen then > > it can't be true that the current match can scroll > > offscreen. Something different needs to be said > > here. >=20 > Do you think this is better? >=20 > "If non-nil, scrolling commands can be used in Isearch mode. > However, the current match can't scroll offscreen if the value is t. > But if it's `unlimited', the current match can scroll offscreen. > You may want to enable `lazy-highlight-buffer' in this case. > If nil, scrolling commands will cancel Isearch mode." > > If you don't agree, please suggest a better wording. I prefer the standard approach: say first what the default (nil) does. Then say what non-nil does. Then state that specific non-nil values have specific non-nil behaviors - IOW, they all do what the non-nil description says, but with some differences. For example: By default (nil value) scrolling exits Isearch mode. Non-nil means you can scroll while searching, as follows: `unlimited' You can scroll any distance. other non-nil value You cannot scroll far enough that the current search hit is no longer visible (is off screen). (BTW, is it only t or is it any other non-nil value?) > > 2. And the term "offscreen" doesn't seem like a > > good choice. Don't we mean just off the window, > > i.e., out of view? So this too bothers/confuses me: > > > > "Allow scrolling within screen" > > > > I don't know what is meant by "screen" here. > > What are the limits of the "screen" within > > which I can scroll with this option value? >=20 > I guess a screen is part of the buffer visible in the window. > We use the word "screen" in other docstrings as well. Yes, but here I think we need to be clear that the part of the buffer visible in the window is any part that _includes the current search hit_, no? Isn't that what this is about - scrolling so far that that hit is "off screen" means scrolling so far that it is no longer visible in the window. The "screenful" that defines the scrolling limits is not something defined independently of the position of the current search hit. > > 3. I'm also puzzled by this: > > > > You may want to enable `lazy-highlight-buffer' > > as well. > > > > Why say that? I think it confuses people, by > > suggesting that for some reason you might need > > to do that, in order to see such highlighting > > if you scroll (e.g. "offscreen"). > > > > That's not the case, is it? (I hope not.) I > > thought that the implementation of `unlimited' > > automatically lazy-highlights everything that > > you scroll to. Is that not the case? >=20 > No, this is not the case. This is very difficult > to implement, and not worth the effort because this feature > is already available by customizing lazy-highlight-buffer. I see. That disappoints me. We have lazy highlighting but we can't use it lazily, except for the original design of being limited to a windowful? Can't we "just" let scrolling move the "window limits" as you scroll? (Yes, I'm making this up, without looking at the code.) This highlight-as-you-go should really be considered part of this enhancement request, IMO. And I mentioned it as such. But if you don't want to tackle that part initially, or if indeed it ends up being too complex in the end, then so be it, for now. > Moreover, even if implemented, it still makes no sense > because it can't highlight as quick as you scroll > thru the buffer. I don't think I agree that it "makes no sense". 1. You might well scroll slowly sometimes, looking closely at search hits. Being able to see hits highlighted is always better than not. 2. If lazy highlighting can generally keep up with holding down `C-s', which it does pretty well now, then it should be able to do about the same wrt scrolling. Sure, there can be many search hits within a small area of text, but even so, I don't see this as a problem. And just as we (I guess) do for fast highlighting when you hold `C-s' down, we can presumably skip highlighting any hits that are no longer on the screen because you've moved past them. 3. Even if highlighting were sometimes slower than what you might scroll, it would catch up when you stop. Heck, if the alternative is full-buffer highlighting, that has to be even slower, no? > The problem is that you haven't tried my patch > with lazy-highlight-buffer enabled. If you tried > you wouldn't want any other implementation. OK, I'll take your word for it, I guess. But I don't see why highlighting only a portion of the buffer (and it might often be a tiny portion) should be less performant than highlighting the entire buffer. Is that really the case? > > 6. `*-allow-shift-selection' behavior: > > > > Why is the value `move'? Is that the best word? > > > > What happens with `move' if you use a shifted > > motion key? If it acts the same as `t' then what > > you call "shifted" is really "-only_ when shifted". > > What you call just "motion" seems like just both > > shifted and unshifted. > > > > Why do we even have two such choices? Why would > > someone who wants to yank chars by moving over > > them want to have to use Shift, ever? Is it so > > that they can use unshifted to exit Isearch and > > move the cursor? I guess so. Maybe that could > > be made clearer (dunno). > > > > 7. OK, no, `move' is apparently more complicated > > than that (all the more reason why it shouldn't > > be called `move'.) This text is a mouthful: > > > > by motion commands that have the `isearch-move' > > property on their symbols equal to `enabled', > > or [for which] the shift-translated command is > > not disabled by the value `disabled' of the same > > property. > > > > That sounds a bit like a legal text. You can just > > repeat "property `isearch-move'" instead of saying > > "the same property" - that would be clearer. But > > the sentence probably needs to be split. And it > > may be a sign that the behavior is too complicated. Is that part of what I wrote not clear, at least? I do advise splitting that sentence up, at a minimum. > > Why do we have this complicated behavior? Why > > not just have a `move' value that lets you yank > > text without having to use Shift (i.e. using Shift > > or not)? What's the point of having to put such a > > property on some command symbols? > > > > And if there really is a use case for doing that > > to certain commands, so that _only they_ manifest > > a difference between `t' and `move' behavior, > > then why not have only the `move' behavior (no `t' > > behavior)? >=20 > Sorry, I don't understand what do you suggest here. It's not clear to me what the behavior is or what problem it's trying to solve. You want to be able to yank text, that you move the cursor over in the buffer, onto the search string. Case `t': Some people want to do that using Shift selection. Why shift? Why wouldn't they just want to do it by moving the cursor (without bothering to shift)? Is it because they want to be able to, separately, move the unshifted cursor to exit Isearch and move over buffer text? Is that the idea? I guess so. Case `move': And for those people who don't want to give up having cursor movement exit Isearch, and who don't want to have to use Shift, we offer another way to yank to the search string by moving the cursor: Users or libraries can specify, for certain cursor movement commands, that mere unshifted cursor movement will yank. Is that right? This all sounds complicated, but if there really are such use cases (e.g., different users) then OK. For case `move', why do we have two different ways to specify the motion commands that we want to let yank text? 1. commands that have the `isearch-move' property on their symbols equal to `enabled' 2. shift-translated commands that have the `isearch-move' property on their symbols not equal to `disabled' I don't even follow that, especially #2. I guess there are at least 4 possibilities for property `isearch-move'? * `enabled' * not `disabled' (on symbol of shift-translated command) * nil * something else What other values for symbol of shift-translated command, besides `disabled', and what do they do? Why two ways to specify the commands that we let yank by moving the cursor? And what about the use case I mentioned: just be able to use any motion commands to yank text, without using Shift? Why assume that everyone wants to be able to use at least some cursor-motion commands to exit Isearch? This case is like implicitly putting the required `isearch-move' value on all commands. I'm not really arguing for any given behavior. I'm saying I don't really understand where all of this is coming from. Have different users actually requested something for these different possible use cases? Is some other library involved perhaps? What's behind this? It seems like a lot, just to let you yank buffer text by moving the cursor. FWIW, I can give an example of something a bit similar that I have in my code. (I don't know how useful it is.) I mention it because your use of a property value on a command made me think of it. I can see the value of letting only some motion commands (chosen by a user) do something other than exit Isearch. It's option `isearchp-initiate-edit-commands'. Default: (backward-char left-char backward-sexp backward-word left-word) Commands whose key bindings initiate Isearch edit. When invoked by a key sequence, Isearch edits the search string, applying the command to it immediately. Commands you might want to include here are typically commands that move point to the left, possibly deleting text along the way. Set this to `nil' if you always want all such commands to exit Isearch and act on the buffer text. IOW, `C-b' (by default), does not exit Isearch but instead, it's short for `M-e C-b'. The option is intended only for backward motion commands. But the idea seems similar to what you have for value `move': limit the behavior to particular commands. You do it with a symbol property; I did it with a list-valued option. (BTW, with `*-allow-shift-selection', if a user moves the cursor backward do you yank those chars onto the search string? I guess so. In which order: order of traversal or order of appearance in the buffer?) My questions about `*-allow-shift-selection' are first about the use cases, only secondarily about the doc. Both seem complicated to me, and I particularly wonder why the use cases. But I don't really need to understand. I reviewed what you wrote about that only because you included it in a reply to this (other) bug report. Ignore my feedback about `*-allow-shift-selection' if you like - no problem. > > The option is apparently about yanking text you > > move the cursor over. >=20 > So I renamed it to `isearch-allow-yank-on-move', > and its options to `no-shift' and `shift'. I would remove the "allow". The option is named after the non-nil behavior (as is common), which is to yank whatever you move the cursor over. > Thanks for the suggestion, I changed it to > "Motion keys exits Isearch". exits -> exit Thx - Drew