GNU bug report logs - #15839
24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15839 <at> debbugs.gnu.org
Subject: bug#15839: 24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily
Date: Tue, 27 Nov 2018 01:35:31 +0200

> Sorry, but I don't really understand.
>
> There are several parts to this bug report.  I don't know
> what "the first part" refers to.

It refers to your original request cited below:

> 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.
>
> That restriction is general for Emacs, and it generally makes sense.
> It does not necessarily make sense during Isearch, however.  Why?
>
> Because the search position is one thing, and it is not lost.  What you
> might want to look at temporarily is another thing.
>
> 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.

This is implemented now with an option `nil' of the customizable
variable `search-exit-option'.  It lets you use a scroll command
(e.g. `C-v') without exiting Isearch, so you can scroll far enough
in either direction that point would be moved off screen.

> 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.
>
> One of the reasons for scrolling is to see what search hits lie beyond
> the currently shown text.  This is already partly defeated, in that
> even when you scroll some of the hits are not highlighted.  This seems
> more like a bug, but if the enhancement of #1 is done then it should
> (it needs to) take care of #2 as well: Whatever text is shown should
> have all of its search hits highlighted with lazy highlighting.

This is implemented now with the customizable variable
`lazy-highlight-buffer'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.