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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to