On Tuesday, October 1, 2013 12:04:06 PM UTC-5, David Barnett wrote: > Even if the language syntax mandates maximum line lengths, you probably don't > want to force +t. This will insert line breaks even in the middle of string > literals, and it's a pain for users to figure out what happened, undo the bad > linebreak, then fix the long lines properly. It would be better to find a > syntax-aware method of breaking long lines, or failing that, leave it up to > users. Anyway, the default is 'tcq', so forcing +t won't do anything except > fight with users who have explicitly disabled it. > > > > I've seen lots of HighlightLongLines hacks floating around, and they're all > brittle (e.g., they don't catch updates to &textwidth, and they don't > cooperate well with other syntax files). It would be nice if vim officially > supported something for it in addition to &colorcolumn (e.g. highlighting > ONLY long lines so you can give them a screaming red color and not make other > lines look ugly). Then if it's truly part of the standard, you have options > to bake that into the built-in files. >
I once used a variant of this: http://vim.wikia.com/wiki/Highlight_long_lines#Toggle_matching_based_on_textwidth which would fire on autocmds (I think it was WinEnter and CursorHold) to re-apply the highlight based on textwidth. But then colorcolumn was introduced and I got rid of it. -- -- 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/groups/opt_out.
