Ring a bell if search hit top/bottom and is continuing

[coot]

Also add 'bo' option value: topbot, which removes the bell.

[chdiza]

The default should be for the bell to NOT ring. Please don't make everyone tweak their vimrc just to get the behavior that's always been there.

Also, according to the docs (at :h belloff, after the list), normal mode bells are all governed by error. But a search hitting top/bottom is a normal mode event.

[coot]

Ups, you're absolutely right! Though I would like to have more control over bell in normal mode, for me the bell is useful only on the search hit top/bottom event.

[brammool]

Most users don't like adding a bell, even a visual one. Let's not do this.

[fritzophrenic]

Please reconsider. The "search hit bottom, continuing at top" is very easy to miss. Setting "nowrapscan" is too drastic. As far as I know it's not possible for Vim to act like most other programs with search support, which will reach the bottom and ASK whether to continue searching at the top.

[chrisbra]

On Do, 25 Aug 2016, fritzophrenic wrote:

Please reconsider. The "search hit bottom, continuing at top" is very
easy to miss. Setting "nowrapscan" is too drastic. As far as I know
it's not possible for Vim to act like most other programs with search
support, which will reach the bottom and ASK whether to continue
searching at the top.

Then, perhaps don't ring the bell, but do something other?

Best,

Christian

Die höchste Form der Eitelkeit ist die Ruhmesliebe.
-- George de Santayana

[fritzophrenic]

On Thu, Aug 25, 2016 at 9:56 AM, Christian Brabandt <
notifications@github.com> wrote:

On Do, 25 Aug 2016, fritzophrenic wrote:

Please reconsider. The "search hit bottom, continuing at top" is very
easy to miss. Setting "nowrapscan" is too drastic. As far as I know
it's not possible for Vim to act like most other programs with search
support, which will reach the bottom and ASK whether to continue
searching at the top.

Then, perhaps don't ring the bell, but do something other?

A different solution to the problem would be acceptable. But it needs to be
attention-grabbing. :-)

At one point there was a proposal for an autocmd event which could trigger
on errors. That would probably have allowed setting nowrapscan, catching
the error for no more matches, and starting over again from the top. But
that proposal got rejected IIRC.

[coot]

I've been using this patch for some time. I don't like a bell, but this
was the easiest solution that grabs attention and it works well for me
(I use the bell only for this purpose).
Another thing I can think of is to flash the screen, this can seem
drastic but the background color for that could be configurable - while
the bell is not and it might not work well you're listening to music.
Another idea would be to just change flash the status line. All of them
could be implemented if vim had an autocommand group for this case.

Cheers,
Marcin

On 08:00 Thu 25 Aug , fritzophrenic wrote:

On Thu, Aug 25, 2016 at 9:56 AM, Christian Brabandt <
notifications@github.com> wrote:

On Do, 25 Aug 2016, fritzophrenic wrote:

Please reconsider. The "search hit bottom, continuing at top" is very
easy to miss. Setting "nowrapscan" is too drastic. As far as I know
it's not possible for Vim to act like most other programs with search
support, which will reach the bottom and ASK whether to continue
searching at the top.

Then, perhaps don't ring the bell, but do something other?

A different solution to the problem would be acceptable. But it needs to be
attention-grabbing. :-)

At one point there was a proposal for an autocmd event which could trigger
on errors. That would probably have allowed setting nowrapscan, catching
the error for no more matches, and starting over again from the top. But
that proposal got rejected IIRC.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#695 (comment)

[netjune]

Maybe wen can borrow the idea from emacs: Only show an warnning message
at the first time; Do wrapscan at the second time.

[fritzophrenic]

Looks like pull request #1009 was added as an alternate way to get the user's attention in a user-configurable manner, by adding an autocmd event to let the user specify an action.