Re: slow display update, maybe due to folded text

On Fri, Oct 16, 2015 at 11:15 AM, Erik Christiansen
<dvalin@internode.on.net> wrote:
[...]
> In short, colouring all 'C' keywords, merely because they are keywords,
> strikes me as equivalent to this comment in usefulness:
>
> elephants++ ; // Increment elephants.
>
> (Incidentally, the example is not artificial. Such facile comments have
> been produced by folk paid to program.)
[...]

I've seen them too. Possibly due to the self-styled "programming
experts" who never write a line of code but insist that every single
line must have a comment (and I have met such people, they are no
figment of my imagination). Myself, I am a partisan of heavy
commenting, but I stop "just short" of purely redundant comments like
the above: for instance, when writing a keymap I might code the
Unicode character of the {rhs} as part of the "code" and add the hex
codepoint and Unicode codepoint name in a comment, even to some people
that would be "almost" as redundant as what you showed. — A few
decades ago I have on occasion had to (understand and) debug spaghetti
code written by others, with no flowchart available (so my first task
was to write one from the source code), and I know what a PITA it can
be.

When I wrote assembler code, operation codes were in their own column
on the coding sheet, with labels to the left and operands to the
right, so colours were largely unnecessary (not that they were
available: the printers of that time printed only in black, and there
were no terminals: we gave Hollerith cards, and usually also magtapes
and disks, and we got back 132-column zig-zag listings in a single 10
cpi all-caps font).

Not so with C or vimscript (or even with the COBOL or ALGOL of a half
century ago): here the code runs all over the page width and the
colours start to become more useful, e.g. to distinguish variables,
commands and functions from each other, or to mark off everything
within an if 0 … endif construct (which could span ten pages of
screen) as temporarily commented off (and why use "if 0 { … }" even in
C? Simple: so you don't need to touch any /* … */ inside the range).
What _is_ possible if you find that the default colors are too much
bang-in-the-face is to use a more subdued colorscheme, either an
existing one or an own-coded one. But if you really prefer no syntax
highlighting at all, that is of course your choice, and Vim (with all
its options) is all about choice, so who am I to dispute it? After
all, even though I use syntax highlighting I disable syntax-related
autoindenting.

Best regards,
Tony.

--
--
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.