Re: slow display update, maybe due to folded text

On Wednesday, October 14, 2015 at 5:12:01 AM UTC-4, John Little wrote:
> IMO you have an insufficiently conspicuous cursor. I use gvim with
>
> set guicursor=a:blinkwait200-blinkon200-blinkoff200
>
> in my .gvimrc for a 5 Hz blink.*
>
> Regards, John Little
>
> *I know I'm in the minority liking a blink, but I think I save at
> least half a second every time I'm looking for the cursor.
>
> For vim in a terminal emulator, over the years I've resorted to
> various (sometimes desperate) hacks to speed up the blink. For
> example, I'm presently using KDE plasma 5.2 and there's no
> configuration for the blink rate yet in Qt 5, except to compile a
> C++ fragment to a .so and preload it with LD_PRELOAD.

I don't think it's the cursor...Over the decades, I've taken a few
cracks at optimizing the color, solidness, and blink rate. Currently,
it's just that I have lots of windows, with tiny font to maximize the
volume of content. Each window has a status line and there are the
window separators. With syntax highlight and folds, and
cursorcolumn/line turned on in all windows (and sometimes spell
checking and search highlighting to match multiple expressionds), it
gets pretty busy.

On Wednesday, October 14, 2015 at 8:12:27 AM UTC-4, Erik Christiansen
wrote:
> ISTM very intuitive that compounding excessive layers of
> highlighting results in no net highlighting, after a point. Failure
> of efforts to lay it on thicker seems to confirm that. (Though a
> blinking cursor might be a last gasp in that direction. :-)

It depends on how you use highlighting. Without syntax highlighting,
I find that all code looks the same. With it, my brain immediately
teases apart different components of a complex nested construct. I
know immediately what to look for, where to look for it, and what to
ignore. But it may be a matter of developing that cognitive habit.

As for folds...indispensible. For files of nested constructs, you can
hide away entire swaths of content almost like a nested folder tree.
You can look at a file at a high level and drill down into the details
at selected locations. But the fold does take up a bit of cognitive
space via the line that signifies its presence in the file.

The function that I posted in the original post seems like an ideal
solution if only it didn't get slowed down by folds so much.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.