A border at fixed width
a.lost....@gmail.com
at certain width. This is very helpful if you prefer, for example,
your code to not exceed 80 columns, but still don't want the wrapping
if it does exceed 80 columns.
I hacked up VIM to do that using cursorcolumn and hardcoding it to 80.
See the image (http://www.freeimagehosting.net/image.php?
bbb1827717.jpg). It would be very useful to have this as a feature in
VIM so user can set the border to any specific width as they want.
Thanks
lost.stranger
a.lost....@gmail.com
including .jpg to see the image.
"http://www.freeimagehosting.net/image.php?bbb1827717.jpg"
Thanks,
Lost.Stranger
On Sep 14, 10:59 am, "a.lost.stran...@gmail.com"
Tony Mechelynck
:match Todo /\%>80v.\+/
will highlight anything after virtual column 80 in the colors of the
Todo highlight group. (You may want to choose a different group if you
feel that Todo looks too much like Search.)
"Virtual" column so we count a hard tab as a variable number of columns,
not as one byte. Match "after 80" rather than "at 81" so even if a
modeline (or something) sets a weird 'tabstop' for a buffer, making tabs
straddle columns 80-81, the first character (if any) after column 80
will still match.
See
:help /ordinary-atom
:help /\%>v
Best regards,
Tony.
--
The Army needs leaders the way a foot needs a big toe.
-- Bill Murray
a.lost....@gmail.com
wrote:
line always on the specified column is much more helpful specially
when reading code (without being too distracting when code exceeds 80
column). May be it is a taste issue but I prefer the vertical column
(as in my screenshot) rather than this highlighting.
Tony Mechelynck
If, as I mentioned, some weird 'tabstop' setting (set, maybe, by a
modeline) causes tabs to straddle columns 80-81 (e.g. by having a file
with the following last line:
vim: ts=33
), whenever a tab straddles col.81 there will be no character sitting
exactly in column 81 on that line (in this case, let's say, a line with
three hard tabs then some text) and your single-column highlight will fail.
Also, AFAIK Vim cannot highlight in a special colour anything beyond the
end of the line, except of course the 'cursorcolumn' but I don't think
you would want to always keep your cursor in column 81. ;-)
Best regards,
Tony.
--
A man goes to a tailor to try on a new custom-made suit. The
first thing he notices is that the arms are too long.
"No problem," says the tailor. "Just bend them at the elbow
and hold them out in front of you. See, now it's fine."
"But the collar is up around my ears!"
"It's nothing. Just hunch your back up a little ... no, a
little more ... that's it."
"But I'm stepping on my cuffs!" the man cries in desperation.
"Nu, bend you knees a little to take up the slack. There you
go. Look in the mirror -- the suit fits perfectly."
So, twisted like a pretzel, the man lurches out onto the
street. Reba and Florence see him go by.
"Oh, look," says Reba, "that poor man!"
"Yes," says Florence, "but what a beautiful suit."
-- Arthur Naiman, "Every Goy's Guide to Yiddish"
John Beckett
> IMHO, this does not provide the exact same feature. Having a
> guide line always on the specified column is much more
> helpful specially when reading code (without being too
> distracting when code exceeds 80 column). May be it is a
> taste issue but I prefer the vertical column (as in my
> screenshot) rather than this highlighting.
Vim won't show you a margin line. Tony has said what Vim can do, but you might like
to read more details:
http://vim.wikia.com/wiki/Highlight_long_lines
FYI many Vim people go into a frenzy whenever something appears on the screen other
than their text (I'm one of those). You wouldn't believe the complaints that people
made when syntax highlighting was made the default.
John
lost.s...@gmail.com
default. <B>VIM developers</B> - interested in receiving a patch for
this? We can add an option showguideline with syntax as set
showguideline=true,30,80,... where 30, 80 are columns where guide line
is needed. set showguideline=false would be default which means no
guidelines.
Thanks
Lost.Stranger
Matt Wozniski
>
> On Sep 14, 8:17 pm, "John Beckett" wrote:
>> a.lost.stranger wrote:
>> > IMHO, this does not provide the exact same feature. Having a
>> > guide line always on the specified column is much more
>> > helpful specially when reading code (without being too
>> > distracting when code exceeds 80 column). May be it is a
>> > taste issue but I prefer the vertical column (as in my
>> > screenshot) rather than this highlighting.
>>
>> Vim won't show you a margin line. Tony has said what Vim can do, but you might like
>> to read more details:http://vim.wikia.com/wiki/Highlight_long_lines
>>
>> FYI many Vim people go into a frenzy whenever something appears on the screen other
>> than their text (I'm one of those). You wouldn't believe the complaints that people
>> made when syntax highlighting was made the default.
>
> default. <B>VIM developers</B> - interested in receiving a patch for
> this? We can add an option showguideline with syntax as set
> showguideline=true,30,80,... where 30, 80 are columns where guide line
> is needed. set showguideline=false would be default which means no
> guidelines.
Well, I think the option would definitely be useful, considering how
often people ask for guidelines, and how poor a substitute :match is.
On the other hand, it might be nice to instead fix up the behavior of
matches to be able to highlight empty text... If that were done, this
would be as simple as :match Error /\%80v/ - After all, I don't see
why anyone would want the behavior that matches currently give if they
highlight virtual columns with no text....
~Matt
fritzophrenic
On Sep 15, 8:12 am, "Matt Wozniski" <m...@drexel.edu> wrote:
> I don't see
> why anyone would want the behavior that matches currently give if they
> highlight virtual columns with no text....
>
> ~Matt
because only those lines get highlighted.
Also, how can you tell if the line is empty, and a virtual column is
being highlighted, or if you have a _lot_ of whitespace, so that the
actual content of a line is beyond the edge of your window? I would
probably continue with the current behavior given by matches, even if
the suggested option becomes availabe.
That being said...this would be a cool feature, useful to many people.
I would not be adverse to its inclusion, even if I'd rarely use it
myself.
Matt Wozniski
>
> On Sep 15, 8:12 am, "Matt Wozniski" <m...@drexel.edu> wrote:
>> I don't see
>> why anyone would want the behavior that matches currently give if they
>> highlight virtual columns with no text....
>
> because only those lines get highlighted.
Only long lines would continue past the guide line as well - and given
that the match overrides syntax highlighting, I'd rather only see it
highlighting just the one column, rather than losing syntax
highlighting for the rest of the line.
> Also, how can you tell if the line is empty, and a virtual column is
> being highlighted, or if you have a _lot_ of whitespace, so that the
> actual content of a line is beyond the edge of your window? I would
> probably continue with the current behavior given by matches, even if
> the suggested option becomes availabe.
The same way as you do it without matches, using 'list' and
'listchars'. For instance, I use:
:set list listchars=tab:▷⋅,trail:⋅,nbsp:⋅
which looks very nice in my chosen font.
> That being said...this would be a cool feature, useful to many people.
> I would not be adverse to its inclusion, even if I'd rarely use it
> myself.
~Matt
A. S. Budden
> On Tue, Sep 16, 2008 at 12:15 AM, fritzophrenic wrote:
>>
>> On Sep 15, 8:12 am, "Matt Wozniski" <m...@drexel.edu> wrote:
>>> I don't see
>>> why anyone would want the behavior that matches currently give if they
>>> highlight virtual columns with no text....
>>
>> Because then your attention is drawn to lines that are too long,
>> because only those lines get highlighted.
>
> Only long lines would continue past the guide line as well - and given
> that the match overrides syntax highlighting, I'd rather only see it
> highlighting just the one column, rather than losing syntax
> highlighting for the rest of the line.
>
>> Also, how can you tell if the line is empty, and a virtual column is
>> being highlighted, or if you have a _lot_ of whitespace, so that the
>> actual content of a line is beyond the edge of your window? I would
>> probably continue with the current behavior given by matches, even if
>> the suggested option becomes availabe.
>
> The same way as you do it without matches, using 'list' and
> 'listchars'. For instance, I use:
> :set list listchars=tab:▷⋅,trail:⋅,nbsp:⋅
> which looks very nice in my chosen font.
Or, for a lot of purposes, I quite like:
:call matchadd('Error', '\s\+$')
But that's a personal preference thing (and only for some languages/filetypes).
Al
fritzophrenic
On Sep 16, 9:09 am, "A. S. Budden" <abud...@gmail.com> wrote:
>
> Or, for a lot of purposes, I quite like:
>
> :call matchadd('Error', '\s\+$')
>
> But that's a personal preference thing (and only for some languages/filetypes).
>
warningmsg group). I personally _hate_ the look of listchars.
But I was referring to lines like this (hopefully not autowrapped when
I send it):
Oh my. A long line!
Lines like the above are only seen by list chars, or by highlighting
everything in a line after a certain number of character positions.
As for matches over-writing syntax highlighting...I have my long line
matches set up to a very subtle background color. I know of no syntax
highlighting (aside from Error, and TODO which really shouldn't occur
at the _end_ of a long line) that uses the background color, at least
not by default.
fritzophrenic
On Sep 16, 10:35 am, fritzophrenic <fritzophre...@gmail.com> wrote:
> But I was referring to lines like this (hopefully not autowrapped when
> I send it):
>
> Oh my. A long line!
>
> Lines like the above are only seen by list chars, or by highlighting
> everything in a line after a certain number of character positions.
>
Picture a line that includes 100 spaces, then some text. Not sure why
you'd ever have this, but I've actually seen it once in a _very_
poorly formatted auto-generated file.
Just having a single column highlighted would never give any
indication that text exists outside the window. You could :set wrap,
but I almost always have nowrap set for source code. Highlighting
whitespace at the end of lines would fail as well.
The only options I know of to show this well would be listchars, or a
subtle backgound highlight on long lines.
Richard Hartmann
> The same way as you do it without matches, using 'list' and
> 'listchars'. For instance, I use:
> :set list listchars=tab:▷⋅,trail:⋅,nbsp:⋅
> which looks very nice in my chosen font.
You might want to use this, instead:
if &encoding == "utf-8"
set listchars=eol:$,trail:·,tab:»·,extends:>,precedes:<
else
set listchars=eol:$,trail:-,tab:>-,extends:>,precedes:<
endif
Or some other setup that takes availiability of UTF-8 into
account.
On the topic of multiple(!) arbitrary vertical marker lines & syntax
highlighting that works on (too) long lines: Yes, please :)
Richard