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: Wed, 28 Nov 2018 19:36:26 -0800 (PST) Message-ID: <24e8fff5-67d8-49ac-801e-1e5f49d2037f@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> 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 1543462514 22095 195.159.176.226 (29 Nov 2018 03:35:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2018 03:35:14 +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 Thu Nov 29 04:35:10 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 1gSD6b-0005ce-HV for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2018 04:35:09 +0100 Original-Received: from localhost ([::1]:52060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSD8i-0006ud-0x for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Nov 2018 22:37:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSD8W-0006tN-Ap for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2018 22:37:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSD8Q-00081w-8e for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2018 22:37:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49722) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gSD8Q-00081l-3c for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2018 22:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gSD8P-0000nl-TE for bug-gnu-emacs@gnu.org; Wed, 28 Nov 2018 22:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Nov 2018 03:37: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.15434625973051 (code B ref 15839); Thu, 29 Nov 2018 03:37:01 +0000 Original-Received: (at 15839) by debbugs.gnu.org; 29 Nov 2018 03:36:37 +0000 Original-Received: from localhost ([127.0.0.1]:53980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSD81-0000n9-0c for submit@debbugs.gnu.org; Wed, 28 Nov 2018 22:36:37 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:52022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSD7z-0000mw-6w for 15839@debbugs.gnu.org; Wed, 28 Nov 2018 22:36:35 -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 wAT3YXeY123846; Thu, 29 Nov 2018 03:36:29 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=eZeGIzii7vCKny6szre1jDIaEOi73hu96+4geZK+IWU=; b=rjw4joX3qIvlLW3LgW2pCk1eODWoaxb8GQkiJ8fsSpUm4D7BVuxVzgkYlpzSx6BUtE3x naaocycVYFdeSzF6KvJ//xSUaZQ8AN1+dE3fzN+zYOIr3Pqw2tkC43z616j0NS8j3UMa WFNDdqzgw9aj+01OG0/pAFKpFos3F3Dd0wjIeS1lS1vswv+fOWLBYtFu4dg9kNYJEtGQ AfKOGykOaOqbPApqWMUvpGV4S2RtpHZDzoMjgRkCTrj5w4FKPeSn1jPZtFXDhGcMuIHK B9PC28zjoYHPHWdHdLM/TfqND8I+Q2ho8N22r5MwDLv9G34VdlrNX8kcJJzI8K/sqdRu hg== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2nxxkqnt6y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Nov 2018 03:36:29 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAT3aSkj022987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Nov 2018 03:36:28 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAT3aRqB016005; Thu, 29 Nov 2018 03:36:27 GMT In-Reply-To: <87a7lsu7rn.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=9091 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-1811290028 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:152876 Archived-At: > > But users should preferably not need to worry > > about variable interactions. The doc for a given > > variable should make clear just what it does, and > > each variable should preferably have one behavior > > (per value chosen). >=20 > I agree that it's better to make it clear in the docstring. > Fixed in a new patch below. >=20 > > I'm guessing that nil `search-exit-option' does > > not just have "the same effect". But (see above) > > even if it does, that doesn't mean that option > > `search-exit-option' has the same effect, because > > setting it to non-nil, ONLY to NOT have the > > effect of `unlimited' `isearch-allow-scroll', > > would presumably also have some other effect > > unrelated to allowing scrolling. >=20 > I agree that `search-exit-option' is too confusing variable > for such features. So we have to offload it from all > unrelated features. >=20 > As the first step, I moved the recently added shift-select > feature from `search-exit-option' to its own clearly named > customizable variable `isearch-allow-shift-select'. >=20 > For the same reason, unlimited scrolling was moved to the new option > `unlimited' of `isearch-allow-scroll'. >=20 > Now finally everything looks right. Please try a new patch: I agree with your summary here, that is, I think we're in agreement. I didn't try to apply your patch, but I took a quick look at it. Here are some questions/comments, in case they help. 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. 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? 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? That's part of this enhancement request: scroll as far as you want, and have search hits highlighted no matter how far you scroll. If that highlighting-as-needed is implemented then I see no need to mention `lazy-highlight-buffer', and I think it's wrong to do so. There should be no more need to enable full-buffer highlighting in the `unlimited' scroll case than in any other case. You enable `lazy-highlight-buffer' when you want to ensure that all search hits are highlighted, even ones you may never look at. If `unlimited' does NOT highlight all hits that come in view then this enhancement request is still not realized, as that's a necessary part of it. 4. I think it would be better for the :tag "Disable scrolling" to say something like this: "Scrolling exits Isearch". It's not that you cannot scroll. It's just that if you do scroll you stop searching. You could say "Disable scrolling while searching", if you prefer to keep the parallel structure of the :tags. 5. Doc string of `*-allow-shift-selection': Whether motion is allowed to select text during incremental search. That will possibly make users think that this is about activating the region (selecting text). The first doc-string line should kind of stand on its own, to give an overall idea. I'd say something more like this: Motion keys yank text to the search string. 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. 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)? I really don't understand the motivations here, sorry. What problem is this option trying to solve? 8.This option should not be called `*-shift-selection' if it is not necessarily about Shift selection. The option is apparently about yanking text you move the cursor over. 9. Again, I'm not crazy about this :tag, for the same reason as above: Disable shift selection A nil option value doesn't disable anything. It just means that cursor motion ends Isearch, so you just move over the buffer text. I apologize in advance for not following some of this. Probably at least some of what I wrote is nonsense based on misunderstanding. At the very least, though, perhaps some of that misunderstanding might indicate that some of the descriptions, or some of the behaviors, are more complicated than necessary. Hope this helps, and thanks for all your work on this stuff.