What happened to "Search hit BOTTOM, continuing at TOP"?

[Tony Mechelynck]

:help 'shortmess' still says that the s flag means not to give the
"Search hit BOTTOM, continuing at TOP" (or vice-versa) message when
searching, which I understand as meaning that in the absence of this
flag, the message will be given. Well, I just noticed that in my
current gvim build (Big 8.1.1935) it isn't, and yet the flag is
absent. Maybe I unwittingly set some other option preventing it? Or
has it been retired? I found this message useful to avoid unwittingly
looping several times in succession through a file's text.

Best regards,
Tony.

[Christian Brabandt]

Do you have the `S` removed from the shortmessage option? Then it will
output the search stat (and a trailing 'W' when it wrapped). Because
otherwise this warning message will overwrite the search_stat.

Best,
Christian
--
Endlich! - Das WerbeMüllLaberZuKaufmichKommerzGeldloswerdBuntiKlickiNetz
ist da. T-Online.

[Marius Gedminas]

It's been replaced by the new [N/M] index shown on the bottom right.
Specifically, a little W appears after it, e.g.

[1/7] W

You can turn off the entire index with :set shortmess+=S and you'll get
the old "search hit TOP/BOTTOM, continuing at BOTTOM/TOP" message back.

(I like the [N/M] index, but I also think the W is way too subtle, and I
find myself looping again and again.)

Marius Gedminas
--
As a rule of thumb, I reckon Python to be an order of magnitude more wasteful
of CPU cycles and memory than my favourite low-level language, C++.
-- Thomas Guest

[Christian Brabandt]

On Do, 29 Aug 2019, Marius Gedminas wrote:

> (I like the [N/M] index, but I also think the W is way too subtle, and I
> find myself looping again and again.)

When the N/M index was first introduced, it did show the error message
and forced a small delay to make sure it can be read before the N/M
index would potentially overwrite it. However people complained about
vim being unresponsive, so it was changed and the 'W' indicator was
added as a compromise.

Best,
Christian
--
Jeder Tag an dem du nicht lächelst, ist ein verlorener Tag.
-- Charlie Chaplin

[Tony Mechelynck]

On Thu, Aug 29, 2019 at 1:30 PM Christian Brabandt <cbl...@256bit.org> wrote:
>
>
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.
>
> Best,
> Christian

Ah, that was it. Thanks Christian and Marius.

Best regards,
Tony.

[Marius Gedminas]

On Thu, Aug 29, 2019 at 01:30:06PM +0200, Christian Brabandt wrote:
> On Do, 29 Aug 2019, Marius Gedminas wrote:
>
> > (I like the [N/M] index, but I also think the W is way too subtle, and I
> > find myself looping again and again.)
>
> When the N/M index was first introduced, it did show the error message
> and forced a small delay to make sure it can be read before the N/M
> index would potentially overwrite it. However people complained about
> vim being unresponsive, so it was changed and the 'W' indicator was
> added as a compromise.

Why is overwriting a concern? There should be enough space in a
80-column wide terminal to display

search hit TOP, continuing at BOTTOM [1/3]

with no need for a pause (which would be annoying, it's what Mutt does
after it displays error messages and I feel annoyance every time it does that).

Marius Gedminas
--
A body of SF less upbeat than US SF as a whole right now probably involves a
community too paralyzed by clinical depression to pick up a pen, let alone
compose.
-- James Nicoll

[ds]

Hi!


Speaking of this " W' indicator, why was it chosen to _add_ it to the '[N/M]' string instead of _prepending_ "W " before one?

The point is, if _appended_, then at the moment of wrapping, the expected position of '[N/M]' changes slightly to the left, which isn't exactly nice (like, why the information is jumping in front of our eyes, etc). While if _prepended_, the counter itself stays exactly where it was, and only this sign "W" appears on the left. Don't know if I'm right or wrong here but I personally certainly like the prepended option better.

If you agree, then here's a patch for src/search.c, which seems to fix it (I'm not a programmer, I also don't know ANYTHING about C at all, and these few lines here may be completely wrong and stupid, so, please, feel absolutely free to change it if needed):

====
    5014c5014,5017
    <         STRCPY(t + len, " W");
    ---
    >         char t_tmp[len + 2];
    >         STRCPY(t_tmp, t);
    >         STRCPY(t + 0, "W ");
    >         STRCPY(t + 2, t_tmp);
====



--
ds

[Bram Moolenaar]

> Speaking of this " W' indicator, why was it chosen to _add_ it to the
> '[N/M]' string instead of _prepending_ "W " before one?
>
> The point is, if _appended_, then at the moment of wrapping, the expected
> position of '[N/M]' changes slightly to the left, which isn't exactly nice
> (like, why the information is jumping in front of our eyes, etc). While if
> _prepended_, the counter itself stays exactly where it was, and only this
> sign "W" appears on the left. Don't know if I'm right or wrong here but I
> personally certainly like the prepended option better.
>
> If you agree, then here's a patch for src/search.c, which seems to fix it
> (I'm not a programmer, I also don't know ANYTHING about C at all, and these
> few lines here may be completely wrong and stupid, so, please, feel
> absolutely free to change it if needed):
>
> ====
> 5014c5014,5017
> < STRCPY(t + len, " W");
> ---
> > char t_tmp[len + 2];
> > STRCPY(t_tmp, t);
> > STRCPY(t + 0, "W ");
> > STRCPY(t + 2, t_tmp);
> ====

I like it. No need to send a patch.

--
hundred-and-one symptoms of being an internet addict:
199. You read this entire list of symptoms, looking for something
that doesn't describe you.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///