unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: 15839@debbugs.gnu.org
Subject: bug#15839: 24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily
Date: Wed, 28 Nov 2018 07:15:11 -0800 (PST)	[thread overview]
Message-ID: <178ca8ac-fb45-4cef-a48d-d916a60860be@default> (raw)
In-Reply-To: <875zwidonq.fsf@mail.linkov.net>

> > I don't want to customize one variable to be able to
> > scroll farther, and another variable to have what's
> > shown by that scrolling have lazy-highlighting
> > (especially if the latter requires lazy-highlighting
> > the entire buffer, rather than just what I see when
> > scrolling).
> 
> Fine.  If you are lazy to customize two variables,
> after you customize one variable we could automatically
> change the value of the second variable.

That was not my point.

First is a question: Would customizing those two
variables in that way affect ONLY the specific
behavior I requested?  I don't expect so.

But even if the answer to that question is yes,
it's not clear from the descriptions of those
variables that that behavior follows as the only,
specific behavior.

If you implement code that does what I requested,
providing a single place for users to control it
(which should logically be `isearch-allow-scroll',
I think) - and that controls only it (does not
affect some other behavior) that will be great.

(Maybe you've done that - if you say so then I'll
take a closer look.)

IOW, how that implementation gets done under the
covers is not so important to a user.  If it's
best that it somehow make use of existing code -
even existing user options, that's OK.

It's not clear to me that the purpose of those
two variables is to realize the feature requested
here.  Is it, really?

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).

You should not, e.g., discover that by choosing a
var value to make a background red you have also
inadvertently turned off the ability to have blue
foreground text.

> > I want to be able to use `isearch-allow-scroll' to
> > let me scroll as far as I want, and see search hits
> > lazy-highlighted in what parts of the buffer I
> > scroll to.
> 
> Fine, we could allow the same feature to be enabled
> by two different variables.
> 
> @@ -2747,8 +2747,15 @@ isearch-allow-scroll
>    "Whether scrolling is allowed during incremental search.
>  If non-nil, scrolling commands can be used in Isearch mode.
>  However, the current match will never scroll offscreen.
> +If `unlimited', the current match can scroll offscreen.

Those last two sentences should be rephrased in
the usual manner: `unlimited' means... Any other
non-nil value means... 

> +This has the same effect as the value `nil'
> of `search-exit-option'.

Does it really?  If that's the only effect of
`search-exit-option' then yes, we don't need a
separate option.  But if that were true then
why did `search-exit-option' exist previously,
and why didn't it do this previously?  And why
was it called `search...' and not `isearch...'?

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.

Sorry that I'm arguing from ignorance here so
far, and not bothering to get informed in detail
about these existing options.

I'm essentially guessing that trying to repurpose
some combination of them to achieve this request
is not a great idea.  If I'm wrong, please try to
present the counter argument straightforwardly.
I'm open to being convinced, but a first sense is
that this is likely not the right approach.

If you just tell me I'm wrong then I'll take a
closer look at what you're proposing.  But first
please consider what I say here, in case it's
valid.

>  If nil, scrolling commands will first cancel
>  Isearch mode."

BTW, why do we say "first" there?  First before
what?  There is no other action after this, is
there?  I.e., there is no "second" or "and" that
follows this "first", right?  Or is there some
additional context that makes that "first" mean
something?

Thanks for working on this.  Let me know, if you
think I'm wrong and should just take a closer
look at what you've proposed.





  reply	other threads:[~2018-11-28 15:15 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08 23:02 bug#15839: 24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily Drew Adams
2013-11-09  0:57 ` Juri Linkov
2013-11-09  3:09   ` Drew Adams
2013-11-10 13:46 ` Stefan Monnier
2013-11-10 16:52   ` Drew Adams
2013-11-11 19:08     ` Drew Adams
2018-11-24 22:45 ` Juri Linkov
2018-11-25  3:14   ` Drew Adams
2018-11-25 20:15     ` Juri Linkov
2018-11-26  0:16       ` Drew Adams
2018-11-26 23:35         ` Juri Linkov
2018-11-27  0:49           ` Drew Adams
2018-11-28  0:35             ` Juri Linkov
2018-11-28 15:15               ` Drew Adams [this message]
2018-11-28 23:01                 ` Juri Linkov
2018-11-29  3:36                   ` Drew Adams
2018-11-29 22:23                     ` Juri Linkov
2018-11-30  0:27                       ` Drew Adams
2018-11-30  7:28                         ` Eli Zaretskii
     [not found]                         ` <<83lg5bc9d6.fsf@gnu.org>
2018-11-30 15:33                           ` Drew Adams
2018-12-04  0:29                         ` Juri Linkov
2018-12-04 14:46                           ` Drew Adams
2018-12-04 20:46                             ` Drew Adams
2018-12-04 21:38                               ` Juri Linkov
2018-12-05  0:32                                 ` Drew Adams
2018-12-05 23:44                                   ` Juri Linkov
2018-12-06  1:20                                     ` Drew Adams
2018-12-05 12:59                           ` Michael Heerdegen
2018-12-05 23:49                             ` Juri Linkov
2018-12-06 12:15                               ` Michael Heerdegen
2018-12-06 23:03                                 ` Juri Linkov
2018-12-07 12:42                                   ` Michael Heerdegen
2018-12-08 23:38                                     ` Juri Linkov
2018-12-09  1:13                                       ` Michael Heerdegen
2018-12-10  0:21                                         ` Juri Linkov
2018-12-10  0:58                                           ` Michael Heerdegen
2018-12-11  0:37                                             ` Juri Linkov
2018-12-11 18:22                                               ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178ca8ac-fb45-4cef-a48d-d916a60860be@default \
    --to=drew.adams@oracle.com \
    --cc=15839@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).