On Monday, May 6, 2019 at 3:37:43 PM UTC-4, Bram Moolenaar wrote:
> > On Sunday, May 5, 2019 at 4:07:29 PM UTC-4, Bram Moolenaar wrote:
> > > > > > After this merge, I experience a noticeable decrease in 
> > > > > > responsiveness
> > > > > > compared to an earlier version, when a search hits TOP/BOTTOM and
> > > > > > continues on the other end of a large document.
> > > > > 
> > > > > 
> > > > > 
> > > > > That is to be expected.  In most files it is OK, but for long files 
> > > > > you
> > > > > 
> > > > > might want to add the "S" flag to 'shortmess'.  That is actually the
> > > > > 
> > > > > default, thus you probably set 'shortmess' somewhere. Use this to find
> > > > > 
> > > > > out where:
> > > > > 
> > > > >       :verbose set shortmess?
> > > > 
> > > > I can confirm this regression exists even when `&shortmess` contains 
> > > > "S".  Also, the file I tested with is not in any way a big file (only 
> > > > 8.5kb).
> > > > 
> > > > Please revert until this is fixed.
> > > 
> > > Try commenting out these lines in search.c:
> > > 
> > >   if (!shortmess(SHM_SEARCH)
> > >           && ((dirc == '/' && LT_POS(pos, curwin->w_cursor))
> > >                       || (dirc == '?' && LT_POS(curwin->w_cursor, pos))))
> > >       ui_delay(500L, FALSE);  // leave some time for top_bot_msg
> > > 
> > > 
> > > That is part of the patch that isn't directly related to the "S" flag
> > > and I was wondering if this is good idea.  You can also add the "s" flag
> > > to 'shortmess' to see if that makes a difference.
> > 
> > I commented out those lines (while leaving &shm alone), and the
> > behavior seems to have gone back to the way it should be.  I hope they
> > will be deleted in the repo.  There should be no delay when the search
> > "cycles around".
> 
> Then we would either see the "hit bottom continuing at top" message or
> the search count.  

Why would we see that?  I'm talking about when &shortmes contains "S".  Under 
that condition, there should be no delay at all.

> Not ideal.  What I think we can do: Show an
> indication of wrapping around in the search count message.  A simple "W"
> avoids translation problems.

So is the idea that what gets displayed will depend on whether &shortmess  
contains "S"?  I.e., if &shm contains "S", then everything works like it did 
before, but if &shm doesn't contain "S" then users will see "W" in the count 
mesage?

If we can show a "W" next to "N of M" on the first match after cycling, why 
can't we show "search hit bottom continuing at top" next to it? 

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui