Re: Add support for guidecolumn in VIM

[_Lone]

On Jun 1, 6:28 pm, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
 On 28/05/09 05:10, _Lone wrote:
 [...]

  I looked at adding 1px highlighting instead of whole character
  background. But it seems it would be very difficult. The reason is
  that the way highlighting works is by storing the background color for
  character which is how various highlights are done.

 When talking aboiut the background, yes; but there are a lot other kinds
 of highlights, especially in the GUI:

         gui=NONE
         gui=reverse
         gui=bold
         gui=italic
         gui=underline
         gui=undercurl

         guibg=color
         guifg=color
         guisp=color

 What about extending these categories? (with appropriate ifdefs in the
 source)? For term and cterm (including GUI-enabled Linux Vim in Console
 mode) the choice would be more limited, probably by default term=reverse
 and ctermbg=color, or somesuch. Of course a new highlight group would
 have to be created, perhaps with a new 'highlight' option setting and
 default -- or maybe not, after all I don't see CursorLine and
 CursorColumn listed there.



  I also looked at wide-character problem and that too looks very hard
  to sovle though I would spend some more time this week if I can fix
  that.

 As I think had been noted, there are several kinds of multicell characters:
   - hard tabs (with and without 'list' and/or 'listchars')
   - control characters (^X, ~Y, |Z, see :help 'isprint')
   - CJK wide
   - non-printable Unicode codepoints (at least xx and , see
 :help 'display' and the last sentence under 'isprint').

 It might be hard to highlight just the one cell in the column in
 question, but maybe you could look how Vim displays the CursorColumn
 highlight. (I think this has also been mentioned).



  Thanks
  _Lone

 Best regards,
 Tony.
 --
 Without ice cream life and fame are meaningless.

Sorry for going off and on, the paying job is keeping me extremely
busy. The CursorColumn and MarginColumn behaves in exactly the same
manner. So whatever problems exist for CursorColumn, also exists for
MarginColumn, including multi-cell characters.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 28/05/09 05:10, _Lone wrote:
[...]
 I looked at adding 1px highlighting instead of whole character
 background. But it seems it would be very difficult. The reason is
 that the way highlighting works is by storing the background color for
 character which is how various highlights are done.

When talking aboiut the background, yes; but there are a lot other kinds 
of highlights, especially in the GUI:

gui=NONE
gui=reverse
gui=bold
gui=italic
gui=underline
gui=undercurl

guibg=color
guifg=color
guisp=color

What about extending these categories? (with appropriate ifdefs in the 
source)? For term and cterm (including GUI-enabled Linux Vim in Console 
mode) the choice would be more limited, probably by default term=reverse 
and ctermbg=color, or somesuch. Of course a new highlight group would 
have to be created, perhaps with a new 'highlight' option setting and 
default -- or maybe not, after all I don't see CursorLine and 
CursorColumn listed there.


 I also looked at wide-character problem and that too looks very hard
 to sovle though I would spend some more time this week if I can fix
 that.

As I think had been noted, there are several kinds of multicell characters:
  - hard tabs (with and without 'list' and/or 'listchars')
  - control characters (^X, ~Y, |Z, see :help 'isprint')
  - CJK wide
  - non-printable Unicode codepoints (at least xx and , see 
:help 'display' and the last sentence under 'isprint').

It might be hard to highlight just the one cell in the column in 
question, but maybe you could look how Vim displays the CursorColumn 
highlight. (I think this has also been mentioned).



 Thanks
 _Lone


Best regards,
Tony.
-- 
Without ice cream life and fame are meaningless.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On May 5, 11:14 am, Bram Moolenaar b...@moolenaar.net wrote:
 Pankaj Garg wrote:
  On May 4, 10:50 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
   _Lone wrote:
On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
_Lone wrote:
 I have modified the patch. The name is nowmargincolumn. The 
 behavior is:
 'mc' = 0 - off
 'mc'  0 - highlightes the column.
 'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

 I also updated the related documentation is option.txt.

 Thanks
 _Lone

I've tested your updated patch with Vim-7.2.166 on Linux x86.
So far it works as it should. No problem to report.

I also think that the idea mentioned earlier in this thread to
support multiple margincolumns is a good one.

For example:set mc=40,80

It can be handy when editing files with multiple columns.

Thanks
-- Dominique

Hi Dominique,

Could you please try cursor column without the patch and see what that
does? I implemented themargincolumnto behave similar to cursorcolumn
so I think they both would behave the same. But still it would be good
to check withoutmargincolumnpatch to make sure there is no
regression.

I am not sure how to handle multi-byte characters. My experience is
limited with that. Anyone has any suggestions?

Thanks
_Lone

   Confirmed: Pristine Vim-7.2.166 has the same odd behavior
   when doing :set cuc with characters using 2 display cells
   (utf-8 on Linux with xterm as well as with gvim (GTK2).

   So this behavior is not introduced by themargincolumnpatch.

   See this screenshot with gvim-7.2.166 GTK2:

  http://dominique.pelle.free.fr/pic/gvim-cuc.png

   cursorcolumn is supposed to be highlighted in grey.
   The cuc is not highlighted in some lines.  The red square
   at the top is the location of the cursor.

   -- Dominique- Hide quoted text -

   - Show quoted text -

  Thanks for the confirmation that this is not a regression. I feel that
  multi-column character bug needs to be fixed separately and it would
  be a little tricky to fix this because of the way 'cursorcolumn'
  highlighting works.

  Bram - Does the 'margincolumn' patch fits the need? If there is any
  other feedback please let me know?

  The following are the two things that probably needs to be considered
  in future:
  1. Highlighting of multi-column characters for both CUC and MC.
  2. Support for margin-column to contain multiple values to highlight
  various columns.

 I don't have time to look into this soon, thus use comments from others.
 This is a new feature and needs a bit of trying out anyway.

 The wide character problem is a separate one.  But if you can solve it
 for 'cuc' as well that would be nice.

 --
 ROBIN:  The what?
 ARTHUR: The Holy Hand Grenade of Antioch.  'Tis one of the sacred relics
         Brother Maynard always carries with him.
 ALL:    Yes. Of course.
 ARTHUR: (shouting) Bring up the Holy Hand Grenade!
                  Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- b...@moolenaar.net --http://www.Moolenaar.net  \\\
 ///        sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\
 \\\        download, build and distribute --http://www.A-A-P.org       ///
  \\\            help me help AIDS victims --http://ICCF-Holland.org   ///- 
 Hide quoted text -

 - Show quoted text -

I got a little busy with my day-job so couldn't look at it but I have
some time this week.

I looked at adding 1px highlighting instead of whole character
background. But it seems it would be very difficult. The reason is
that the way highlighting works is by storing the background color for
character which is how various highlights are done.

I also looked at wide-character problem and that too looks very hard
to sovle though I would spend some more time this week if I can fix
that.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Ricky]

Maybe it's more comfortable if only high-light 1 or 2 pixies for margin 
column(at last I think so) ,
like Ultra Edit, and can avoid the multi-byte problem.

The option set mc take effect only first tab, for example, set nu can 
display line numbers for all tabs,
but mc is different with others, I think it make confuse. Every time I 
need set mc again manually in new tab.

--
From: Tony Mechelynck antoine.mechely...@gmail.com
Sent: Friday, May 08, 2009 8:47 AM
To: vim_dev@googlegroups.com
Subject: Re: Add support for guidecolumn in VIM

 Yes, as I noted earlier, the character will be fully highlighted if the
 first of its two display cells is on the highlighted column, it won't be
 highlighted at all if it's the second.

 But it's not a problem, nobody use double-byte write programs.
 [...]

 Hm. People might use wide characters:
 - in program comments
 - in program strings, e.g. in headings to be printed above columns of
 results
 - in literals used by programs such as Vim, which manipulate text and
 have to worry about wide vs. narrow characters.
 In this third case it would probably be possible to use Unicode
 constants (coded by means of ASCII text) but I believe that raw text
 (including CJK text) would be better in the first two cases.

 Also, people certainly do sometimes use wide characters to write _text_
 files, and may want their text lines to stay within some bounds, using
 this column highlight the way we used to listen to the bell when
 computers hadn't yet replaced typewriters.


 Best regards,
 Tony. 


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 04/05/09 15:28, Ricky wrote:
 Hi again
 I found out the reason now.
 The margin column high-light become confuse when double-byte characters.
 See attach.

Yes, as I noted earlier, the character will be fully highlighted if the 
first of its two display cells is on the highlighted column, it won't be 
highlighted at all if it's the second.

 But it's not a problem, nobody use double-byte write programs.
[...]

Hm. People might use wide characters:
- in program comments
- in program strings, e.g. in headings to be printed above columns of 
results
- in literals used by programs such as Vim, which manipulate text and 
have to worry about wide vs. narrow characters.
In this third case it would probably be possible to use Unicode 
constants (coded by means of ASCII text) but I believe that raw text 
(including CJK text) would be better in the first two cases.

Also, people certainly do sometimes use wide characters to write _text_ 
files, and may want their text lines to stay within some bounds, using 
this column highlight the way we used to listen to the bell when 
computers hadn't yet replaced typewriters.


Best regards,
Tony.
-- 
WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 04/05/09 20:20, Dominique Pellé wrote:

 Ricky wrote:

 Hi again

I found out the reason now.

The margin column high-light become confuse when double-byte characters.
 See attach.
But it's not a problem, nobody use double-byte write programs.

If i set mc=??, margin column will disappear when crate a new tab.


 I observe the same odd highlighting behavior when using :set cuc
 with characters that occupy 2 display cells.

 See http://dominique.pelle.free.fr/pic/set-cuc.png

 (the margincolumn is highlighted in red, the cuc is highlighted in grey)

 Now how should margincolumn or cursorcolumn be highlighted
 anyway with characters that occupy 2 display cells?

 I'm using Vim-7.2.166 (Linux x86) with margincolumn patch.

 -- Dominique

I haven't applied the patch (yet) but my vimrc includes :set cuc cul. 
I see the following:
- exactly one character cell of a hard tab is highlighted when the 
highlighted column goes through its span.
- in other cases, i.e.,
   - wide CJK characters
   - ^X symbols for non-'isprint' ASCII (usually hex 00-08, 0B-1F, and 7F)
   - xx hex symbols for non-'isprint' characters on the range 80 to FF 
(often 80-9F) when 'encoding' is utf-8 or equivalent
   -  hex symbols for zero-width or undisplayable Unicode above U+00FF
the whole character or symbol is highlighted if its first character cell 
is in the cursor column, otherwise the highlight skips that line.

This doesn't bother me much since most of my text is made of printable 
narrow characters, and the few files of mine which contain wide 
characters tend to have them vertically aligned. The 'cursorcolumn' 
highlight extends the whole height of the current split-window, and if 
it happens to miss a line because of hitting the second or further 
character cell of a character or character symbol on that line, it's 
still obvious where the column happens to be.. But I can imagine that it 
might be more of a problem for text using mixed wide and narrow 
characters (such as CJK text interspersed with numbers in Western 
digits or with URLs in ASCII) where odd and even parts of wide 
characters might alternate more or less at random in a single screen column.


Best regards,
Tony.
-- 
Those who do not do politics will be done in by politics.
-- French Proverb

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 05/05/09 07:50, Dominique Pellé wrote:
 _Lone wrote:
[...]
 Hi Dominique,

 Could you please try cursor column without the patch and see what that
 does? I implemented the margincolumn to behave similar to cursorcolumn
 so I think they both would behave the same. But still it would be good
 to check without margincolumn patch to make sure there is no
 regression.

 I am not sure how to handle multi-byte characters. My experience is
 limited with that. Anyone has any suggestions?

 Thanks
 _Lone


 Confirmed: Pristine Vim-7.2.166 has the same odd behavior
 when doing :set cuc with characters using 2 display cells
 (utf-8 on Linux with xterm as well as with gvim (GTK2).

 So this behavior is not introduced by the margincolumn patch.

 See this screenshot with gvim-7.2.166 GTK2:

 http://dominique.pelle.free.fr/pic/gvim-cuc.png

 cursorcolumn is supposed to be highlighted in grey.
 The cuc is not highlighted in some lines.  The red square
 at the top is the location of the cursor.

 -- Dominique

Looking at the screen shot makes it obvious that wide characters are 
only highlighted by 'cuc' if their starting (left) character cell is in 
the cursor column.

A simple test shows that ^X symbols for control characters and  
placeholders for non-displayable Unicode codepoints behave the same. 
OTOH only one cell of the space occupied by hard tabs is highlighted, 
regardless of whether 'list' is on (with a tab: part present in 
'listchars') or off, and of where in the tab the cursor column happens 
to pass.

All this for 'cursorcolumn' since I haven't installed this patch (yet?)


Best regards,
Tony.
-- 
You can tune a piano, but you can't tuna fish.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On May 4, 10:50 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
 _Lone wrote:
  On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
  _Lone wrote:
   I have modified the patch. The name is now margincolumn. The behavior 
   is:
   'mc' = 0 - off
   'mc'  0 - highlightes the column.
   'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

   I also updated the related documentation is option.txt.

   Thanks
   _Lone

  I've tested your updated patch with Vim-7.2.166 on Linux x86.
  So far it works as it should. No problem to report.

  I also think that the idea mentioned earlier in this thread to
  support multiple margincolumns is a good one.

  For example:set mc=40,80

  It can be handy when editing files with multiple columns.

  Thanks
  -- Dominique

  Hi Dominique,

  Could you please try cursor column without the patch and see what that
  does? I implemented the margincolumn to behave similar to cursorcolumn
  so I think they both would behave the same. But still it would be good
  to check without margincolumn patch to make sure there is no
  regression.

  I am not sure how to handle multi-byte characters. My experience is
  limited with that. Anyone has any suggestions?

  Thanks
  _Lone

 Confirmed: Pristine Vim-7.2.166 has the same odd behavior
 when doing :set cuc with characters using 2 display cells
 (utf-8 on Linux with xterm as well as with gvim (GTK2).

 So this behavior is not introduced by the margincolumn patch.

 See this screenshot with gvim-7.2.166 GTK2:

 http://dominique.pelle.free.fr/pic/gvim-cuc.png

 cursorcolumn is supposed to be highlighted in grey.
 The cuc is not highlighted in some lines.  The red square
 at the top is the location of the cursor.

 -- Dominique- Hide quoted text -

 - Show quoted text -

Thanks for the confirmation that this is not a regression. I feel that
multi-column character bug needs to be fixed separately and it would
be a little tricky to fix this because of the way 'cursorcolumn'
highlighting works.

Bram - Does the 'margincolumn' patch fits the need? If there is any
other feedback please let me know?

The following are the two things that probably needs to be considered
in future:
1. Highlighting of multi-column characters for both CUC and MC.
2. Support for margin-column to contain multiple values to highlight
various columns.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Bram Moolenaar]

Dennis Benzinger wrote:

 Am 01.05.2009 21:23, Matt Wozniski schrieb:
  [...]
  I agree.  I think that 'guidecolumn' is a much better name.
  [...]
 
 Me too.
 
  Also, I agree with Gary - it's not
  inconceivable that someone might want two guides at different spots
  representing different things, which would mean that the margincolumn
  name is much more misleading.
  [...]
 
 Because of the possibility to support multiple guides I suggest using a
 string option with comma separated values. For example:
 
 :set guidecolumn=10,15,20,tw,wm
 
 tw and wm would set a guide at textwidth resp. wrapmargin. This makes it
 easy to add and remove guides with -= and +=.

And then of course also make it possible to set the color for each
column separately.  And how about setting the column two characters
before 'textwidth'?

There are always more features to ask for.  Let's stick to one column.

-- 
A hamburger walks into a bar, and the bartender says: I'm sorry,
but we don't serve food here.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Bram Moolenaar]

Pankaj Garg wrote:

 On May 4, 10:50 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
  _Lone wrote:
   On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
   _Lone wrote:
I have modified the patch. The name is now margincolumn. The behavior 
is:
'mc' = 0 - off
'mc'  0 - highlightes the column.
'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.
 
I also updated the related documentation is option.txt.
 
Thanks
_Lone
 
   I've tested your updated patch with Vim-7.2.166 on Linux x86.
   So far it works as it should. No problem to report.
 
   I also think that the idea mentioned earlier in this thread to
   support multiple margincolumns is a good one.
 
   For example:set mc=40,80
 
   It can be handy when editing files with multiple columns.
 
   Thanks
   -- Dominique
 
   Hi Dominique,
 
   Could you please try cursor column without the patch and see what that
   does? I implemented the margincolumn to behave similar to cursorcolumn
   so I think they both would behave the same. But still it would be good
   to check without margincolumn patch to make sure there is no
   regression.
 
   I am not sure how to handle multi-byte characters. My experience is
   limited with that. Anyone has any suggestions?
 
   Thanks
   _Lone
 
  Confirmed: Pristine Vim-7.2.166 has the same odd behavior
  when doing :set cuc with characters using 2 display cells
  (utf-8 on Linux with xterm as well as with gvim (GTK2).
 
  So this behavior is not introduced by the margincolumn patch.
 
  See this screenshot with gvim-7.2.166 GTK2:
 
  http://dominique.pelle.free.fr/pic/gvim-cuc.png
 
  cursorcolumn is supposed to be highlighted in grey.
  The cuc is not highlighted in some lines.  The red square
  at the top is the location of the cursor.
 
  -- Dominique- Hide quoted text -
 
  - Show quoted text -
 
 Thanks for the confirmation that this is not a regression. I feel that
 multi-column character bug needs to be fixed separately and it would
 be a little tricky to fix this because of the way 'cursorcolumn'
 highlighting works.
 
 Bram - Does the 'margincolumn' patch fits the need? If there is any
 other feedback please let me know?
 
 The following are the two things that probably needs to be considered
 in future:
 1. Highlighting of multi-column characters for both CUC and MC.
 2. Support for margin-column to contain multiple values to highlight
 various columns.

I don't have time to look into this soon, thus use comments from others.
This is a new feature and needs a bit of trying out anyway.

The wide character problem is a separate one.  But if you can solve it
for 'cuc' as well that would be nice.

-- 
ROBIN:  The what?
ARTHUR: The Holy Hand Grenade of Antioch.  'Tis one of the sacred relics
Brother Maynard always carries with him.
ALL:Yes. Of course.
ARTHUR: (shouting) Bring up the Holy Hand Grenade!
 Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Ricky]

Hi again

  I found out the reason now.

  The margin column high-light become confuse when double-byte characters. See 
attach.
  But it's not a problem, nobody use double-byte write programs.

  If i set mc=??, margin column will disappear when crate a new tab.

Regards


From: Ricky 
Sent: Sunday, May 03, 2009 4:35 PM
To: vim_dev@googlegroups.com 
Subject: Re: Add support for guidecolumn in VIM


Hi,

  I compile with BIG and OLE features then copy the gvim.exe to override my old 
version, but it not work.
  I use : 
  set mc=80 or
  set mc=72
  both not highlight a column on the screen.

 Is there anything wrong?


From: _Lone 
Sent: Sunday, May 03, 2009 9:34 AM
To: vim_dev@googlegroups.com 
Subject: Re: Add support for guidecolumn in VIM





On Fri, May 1, 2009 at 6:55 AM, Bram Moolenaar b...@moolenaar.net wrote:



  Pankaj Garg wrote:

   On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote:

On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote:
   
 The name 'guidecolumn' starts with gui, which is confusing, since it

 also works in a terminal. =A0'margincolumn' perhaps?

   
I agree. If a user uses :help guiC-D for example, they would NOT be
expecting 'guidecolumn' to show up!
   
 I think the value 0 should be used to have a column at 'textwidth'.
 That way you can see where a line will be broken when it's formatted,

 without having to set two options. =A0A negative value can be used to

 disable the column.
   
I think we should try to make this option consistent with other
options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
disable it, and making this one use negative numbers may get
confusing.
   
Is it possible to use string or character values, or can only numbers
be entered? I can't think of any options that do this, but things like
line() can take several strings with special meaning. Perhaps the
guidecolumn could be disabled when set to 0, set to the textwidth when
set to tw, and set to the wrap margin when set to wm? I think
something like this would be more consistent with other options and
therefore more intuitive for users.
   
 I didn't have time to check for any problems with this patch, I hope
 others have tried it out and report any problems noticed.
   
I haven't tried the patch, but I'm certainly interested in the
feature. I'd probably use this instead of the autocmds I have set up
to use a matchadd() on long lines.
   
What is this option local to? If it's just global at the moment, I
think it should be local either to the buffer (because that's what
textwidth is local to) or the window. I could see a use case where a
user might want a guidecolumn for the file in one window, but turn it
off for a window in diff mode in another tab or something.
  
   The option is local to window. I agree margincolumn is a better name.
   I am also fine with a value of 0 meaning textwidth, however as Ben
   mentioned, that seems a little unintuitive. Should we convert it to
   string?
   Are there other example where numeric options are taking string?
  
   Please let me know what you prefer and I can do whatever option
   everyone agrees to.


  It's possible to use a string, but more difficult to handle.  And easier
  to set a wrong value, thus more error checking is needed.
  If we want to use zero for off, we could use -1 for using the
  'textwidth' value.

  --
  Time flies like an arrow.
  Fruit flies like a banana.


   /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
  ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
  \\\download, build and distribute -- http://www.A-A-P.org///
   \\\help me help AIDS victims -- http://ICCF-Holland.org///



  I have modified the patch. The name is now margincolumn. The behavior is:
  'mc' = 0 - off
  'mc'  0 - highlightes the column.
  'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

  I also updated the related documentation is option.txt.

  Thanks
  _Lone

  

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

inline: mc.png

Re: Add support for guidecolumn in VIM

[James Vega]

On Mon, May 04, 2009 at 09:28:57PM +0800, Ricky wrote:
 Hi again
 
   I found out the reason now.
 
   The margin column high-light become confuse when double-byte characters. 
 See attach.
   But it's not a problem, nobody use double-byte write programs.

This is a bad assumption to make.  There will definitely be multi-byte
characters displayed by Vim when a guidecolumn is in use.  Nearly every
programming language (if not every single one) I've used supports the
use of multi-byte characters in its source file.  Some, like vimscript,
even have directives to specify what encoding is used in the file.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com


signature.asc
Description: Digital signature

Re: Add support for guidecolumn in VIM

[Dominique Pellé]

Ricky wrote:

 Hi again

   I found out the reason now.

   The margin column high-light become confuse when double-byte characters.
 See attach.
   But it's not a problem, nobody use double-byte write programs.

   If i set mc=??, margin column will disappear when crate a new tab.


I observe the same odd highlighting behavior when using :set cuc
with characters that occupy 2 display cells.

See http://dominique.pelle.free.fr/pic/set-cuc.png

(the margincolumn is highlighted in red, the cuc is highlighted in grey)

Now how should margincolumn or cursorcolumn be highlighted
anyway with characters that occupy 2 display cells?

I'm using Vim-7.2.166 (Linux x86) with margincolumn patch.

-- Dominique

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Lech Lorens]

On 03-May-2009 Ricky richi...@live.com wrote:
 Hi,
 
   I compile with BIG and OLE features then copy the gvim.exe to override my 
 old version, but it not work.
   I use : 
   set mc=80 or
   set mc=72
   both not highlight a column on the screen.
 
  Is there anything wrong?

Have you applied the patch?
Are you sure you have applied the version of the patch that uses
margincolumn instead of guidecolumn for the feature's name?

-- 
Cheers,
Lech

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
 _Lone wrote:
  I have modified the patch. The name is now margincolumn. The behavior is:
  'mc' = 0 - off
  'mc'  0 - highlightes the column.
  'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

  I also updated the related documentation is option.txt.

  Thanks
  _Lone

 I've tested your updated patch with Vim-7.2.166 on Linux x86.
 So far it works as it should. No problem to report.

 I also think that the idea mentioned earlier in this thread to
 support multiple margincolumns is a good one.

 For example:set mc=40,80

 It can be handy when editing files with multiple columns.

 Thanks
 -- Dominique

Hi Dominique,

Could you please try cursor column without the patch and see what that
does? I implemented the margincolumn to behave similar to cursorcolumn
so I think they both would behave the same. But still it would be good
to check without margincolumn patch to make sure there is no
regression.

I am not sure how to handle multi-byte characters. My experience is
limited with that. Anyone has any suggestions?

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Dominique Pellé]

_Lone wrote:

 On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote:
 _Lone wrote:
  I have modified the patch. The name is now margincolumn. The behavior is:
  'mc' = 0 - off
  'mc'  0 - highlightes the column.
  'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

  I also updated the related documentation is option.txt.

  Thanks
  _Lone

 I've tested your updated patch with Vim-7.2.166 on Linux x86.
 So far it works as it should. No problem to report.

 I also think that the idea mentioned earlier in this thread to
 support multiple margincolumns is a good one.

 For example:set mc=40,80

 It can be handy when editing files with multiple columns.

 Thanks
 -- Dominique

 Hi Dominique,

 Could you please try cursor column without the patch and see what that
 does? I implemented the margincolumn to behave similar to cursorcolumn
 so I think they both would behave the same. But still it would be good
 to check without margincolumn patch to make sure there is no
 regression.

 I am not sure how to handle multi-byte characters. My experience is
 limited with that. Anyone has any suggestions?

 Thanks
 _Lone


Confirmed: Pristine Vim-7.2.166 has the same odd behavior
when doing :set cuc with characters using 2 display cells
(utf-8 on Linux with xterm as well as with gvim (GTK2).

So this behavior is not introduced by the margincolumn patch.

See this screenshot with gvim-7.2.166 GTK2:

http://dominique.pelle.free.fr/pic/gvim-cuc.png

cursorcolumn is supposed to be highlighted in grey.
The cuc is not highlighted in some lines.  The red square
at the top is the location of the cursor.

-- Dominique

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Dominique Pellé]

_Lone wrote:

 I have modified the patch. The name is now margincolumn. The behavior is:
 'mc' = 0 - off
 'mc'  0 - highlightes the column.
 'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

 I also updated the related documentation is option.txt.

 Thanks
 _Lone

I've tested your updated patch with Vim-7.2.166 on Linux x86.
So far it works as it should. No problem to report.

I also think that the idea mentioned earlier in this thread to
support multiple margincolumns is a good one.

For example:set mc=40,80

It can be handy when editing files with multiple columns.

Thanks
-- Dominique

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Ricky]

Hi,

  I compile with BIG and OLE features then copy the gvim.exe to override my old 
version, but it not work.
  I use : 
  set mc=80 or
  set mc=72
  both not highlight a column on the screen.

 Is there anything wrong?


From: _Lone 
Sent: Sunday, May 03, 2009 9:34 AM
To: vim_dev@googlegroups.com 
Subject: Re: Add support for guidecolumn in VIM





On Fri, May 1, 2009 at 6:55 AM, Bram Moolenaar b...@moolenaar.net wrote:



  Pankaj Garg wrote:

   On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote:

On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote:
   
 The name 'guidecolumn' starts with gui, which is confusing, since it

 also works in a terminal. =A0'margincolumn' perhaps?

   
I agree. If a user uses :help guiC-D for example, they would NOT be
expecting 'guidecolumn' to show up!
   
 I think the value 0 should be used to have a column at 'textwidth'.
 That way you can see where a line will be broken when it's formatted,

 without having to set two options. =A0A negative value can be used to

 disable the column.
   
I think we should try to make this option consistent with other
options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
disable it, and making this one use negative numbers may get
confusing.
   
Is it possible to use string or character values, or can only numbers
be entered? I can't think of any options that do this, but things like
line() can take several strings with special meaning. Perhaps the
guidecolumn could be disabled when set to 0, set to the textwidth when
set to tw, and set to the wrap margin when set to wm? I think
something like this would be more consistent with other options and
therefore more intuitive for users.
   
 I didn't have time to check for any problems with this patch, I hope
 others have tried it out and report any problems noticed.
   
I haven't tried the patch, but I'm certainly interested in the
feature. I'd probably use this instead of the autocmds I have set up
to use a matchadd() on long lines.
   
What is this option local to? If it's just global at the moment, I
think it should be local either to the buffer (because that's what
textwidth is local to) or the window. I could see a use case where a
user might want a guidecolumn for the file in one window, but turn it
off for a window in diff mode in another tab or something.
  
   The option is local to window. I agree margincolumn is a better name.
   I am also fine with a value of 0 meaning textwidth, however as Ben
   mentioned, that seems a little unintuitive. Should we convert it to
   string?
   Are there other example where numeric options are taking string?
  
   Please let me know what you prefer and I can do whatever option
   everyone agrees to.


  It's possible to use a string, but more difficult to handle.  And easier
  to set a wrong value, thus more error checking is needed.
  If we want to use zero for off, we could use -1 for using the
  'textwidth' value.

  --
  Time flies like an arrow.
  Fruit flies like a banana.


   /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
  ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
  \\\download, build and distribute -- http://www.A-A-P.org///
   \\\help me help AIDS victims -- http://ICCF-Holland.org///



  I have modified the patch. The name is now margincolumn. The behavior is:
  'mc' = 0 - off
  'mc'  0 - highlightes the column.
  'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

  I also updated the related documentation is option.txt.

  Thanks
  _Lone

  

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 30/04/09 18:30, Ben Fritz wrote:



 On Apr 29, 11:42 am, Bram Moolenaarb...@moolenaar.net  wrote:

 The name 'guidecolumn' starts with gui, which is confusing, since it
 also works in a terminal.  'margincolumn' perhaps?


 I agree. If a user uses :help guiC-D  for example, they would NOT be
 expecting 'guidecolumn' to show up!

 I think the value 0 should be used to have a column at 'textwidth'.
 That way you can see where a line will be broken when it's formatted,
 without having to set two options.  A negative value can be used to
 disable the column.


 I think we should try to make this option consistent with other
 options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
 disable it, and making this one use negative numbers may get
 confusing.

 Is it possible to use string or character values, or can only numbers
 be entered? I can't think of any options that do this, but things like
 line() can take several strings with special meaning. Perhaps the
 guidecolumn could be disabled when set to 0, set to the textwidth when
 set to tw, and set to the wrap margin when set to wm? I think
 something like this would be more consistent with other options and
 therefore more intuitive for users.
[...]

The problem with that approach is that the option would then be a String 
option, with the consequence that set+= and set-= etc. would work in a 
way which is unexpected for a numeric value. Examples, each of them with 
a starting value of 60:

:set margincolumn+=5

makes it become 605, not 65

:set margincolumn-=6

makes it become 0, not 54

:set margincolumn^=2

makes it become 260, not 120

OTOH, you could use an algebraic number, always relative to the 
textwidth/wrapmargin. Then use a very large negative value to disable 
it, i.e.

:set margincolumn=0

use 'textwidth' if set, otherwise use (window width - 'wrapmargin') if 
set, otherwise use column zero (disabled).

:set margincolumn=-10

use 'textwidth' - 10 if set, otherwise use (window width - wrapmargin - 
10) if set, otherwise disabled

:set margincolumn=-

always disabled (assuming you won't have  columns of window width).

Just a thought: Maybe use the opposite sign convention, and subtract 
from 'tw' when this option is positive -- since we'll more often want to 
be warned when we approach the margin, as with a typewriter bell, rather 
than when we exceed it by a given amount?


Best regards,
Tony.
-- 
I am the mother of all things, and all things should wear a sweater.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 01/05/09 20:42, Gary Johnson wrote:
[...]
 As for the name, I don't see 'guidecolumn' as being a problem.  I
 doubt that anyone would confuse it with a GUI command.  There are
 lots of English words having the same initial letters but unrelated
 meanings.  :help comm^D shows some examples of this.
[...]

:help comm^D gives me a number of matches for comment, a large 
number of matches for command, and just two which are neither, namely 
spell-COMMON and ft-gitcommit-plugin.


Best regards,
Tony.
-- 
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

I'm getting segmentation faults when setting the guidecolumn to any number

The gdb backtrace output is:

---
Program received signal SIGSEGV, Segmentation fault.
0x005374fa in showruler (always=0) at screen.c:9482
9482 leif ((*p_stl != NUL || *curwin-w_p_stl != NUL) 
 curwin-w_status_height)
(gdb) bt
#0  0x005374fa in showruler (always=0) at screen.c:9482
#1  0x004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
#2  0x004a6d1f in main (argc=2, argv=0x7fff53767528) at main.c:939
---

The compile vim version

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled May  2 2009 19:57:33)
Included patches: 1-166
Compiled by ka...@sophie
Normal version with GTK2 GUI.  Features included (+) or not (-):
-arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv -cscope +cursorshape
+dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval
+ex_extra +extra_search -farsi +file_in_path +find_in_path +float
+folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand +jumplist -keymap -langmap +libcall +linebreak
+lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse
+mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm
-mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang
-mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript
+printer -profile -python +quickfix +reltime
-rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline
-sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl
+terminfo +termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
+viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11
-xfontset +xim +xsmp_interact +xterm_clipboard
-xterm_save
   system vimrc file: /etc/vimrc
 user vimrc file: $HOME/.vimrc
  user exrc file: $HOME/.exrc
  system gvimrc file: /etc/gvimrc
user gvimrc file: $HOME/.gvimrc
system menu file: $VIMRUNTIME/menu.vim
  fall-back for $VIM: /usr/local/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -g -D_FORTIFY_SOURCE=1
Linking: gcc   -L/usr/local/lib -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lglib-2.0   -lXt -lm -lncurses -lacl -lgpm

-- 
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto kaz@gmail.com wrote:
 I'm getting segmentation faults when setting the guidecolumn to any number

 The gdb backtrace output is:

 ---
 Program received signal SIGSEGV, Segmentation fault.
 0x005374fa in showruler (always=0) at screen.c:9482
 9482 le    if ((*p_stl != NUL || *curwin-w_p_stl != NUL) 
     curwin-w_status_height)
 (gdb) bt
 #0  0x005374fa in showruler (always=0) at screen.c:9482
 #1  0x004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
 #2  0x004a6d1f in main (argc=2, argv=0x7fff53767528) at main.c:939
 ---

If I change *curwin-w_p_stl to curwin-w_p_stl its works but this is
not a part of patch, is this a vim bug?

-- 
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

On Sat, May 2, 2009 at 8:25 PM, Kazuo Teramoto kaz@gmail.com wrote:
 On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto kaz@gmail.com wrote:
 I'm getting segmentation faults when setting the guidecolumn to any number

 The gdb backtrace output is:

 ---
 Program received signal SIGSEGV, Segmentation fault.
 0x005374fa in showruler (always=0) at screen.c:9482
 9482 le    if ((*p_stl != NUL || *curwin-w_p_stl != NUL) 
     curwin-w_status_height)
 (gdb) bt
 #0  0x005374fa in showruler (always=0) at screen.c:9482
 #1  0x004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
 #2  0x004a6d1f in main (argc=2, argv=0x7fff53767528) at main.c:939
 ---

 If I change *curwin-w_p_stl to curwin-w_p_stl its works but this is
 not a part of patch, is this a vim bug?
And now think that this dont do anything because curwin dont have a w_p_stl

-
(gdb) print showruler::curwin-w_p_stl
There is no member named w_p_stl.
-

Sorry for the triple email...

-- 
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On Fri, May 1, 2009 at 6:55 AM, Bram Moolenaar b...@moolenaar.net wrote:



 Pankaj Garg wrote:

  On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote:
   On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote:
  
The name 'guidecolumn' starts with gui, which is confusing, since
 it
also works in a terminal. =A0'margincolumn' perhaps?
  
   I agree. If a user uses :help guiC-D for example, they would NOT be
   expecting 'guidecolumn' to show up!
  
I think the value 0 should be used to have a column at 'textwidth'.
That way you can see where a line will be broken when it's formatted,
without having to set two options. =A0A negative value can be used to
 disable the column.
  
   I think we should try to make this option consistent with other
   options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
   disable it, and making this one use negative numbers may get
   confusing.
  
   Is it possible to use string or character values, or can only numbers
   be entered? I can't think of any options that do this, but things like
   line() can take several strings with special meaning. Perhaps the
   guidecolumn could be disabled when set to 0, set to the textwidth when
   set to tw, and set to the wrap margin when set to wm? I think
   something like this would be more consistent with other options and
   therefore more intuitive for users.
  
I didn't have time to check for any problems with this patch, I hope
others have tried it out and report any problems noticed.
  
   I haven't tried the patch, but I'm certainly interested in the
   feature. I'd probably use this instead of the autocmds I have set up
   to use a matchadd() on long lines.
  
   What is this option local to? If it's just global at the moment, I
   think it should be local either to the buffer (because that's what
   textwidth is local to) or the window. I could see a use case where a
   user might want a guidecolumn for the file in one window, but turn it
   off for a window in diff mode in another tab or something.
 
  The option is local to window. I agree margincolumn is a better name.
  I am also fine with a value of 0 meaning textwidth, however as Ben
  mentioned, that seems a little unintuitive. Should we convert it to
  string?
  Are there other example where numeric options are taking string?
 
  Please let me know what you prefer and I can do whatever option
  everyone agrees to.

 It's possible to use a string, but more difficult to handle.  And easier
 to set a wrong value, thus more error checking is needed.
 If we want to use zero for off, we could use -1 for using the
 'textwidth' value.

 --
 Time flies like an arrow.
 Fruit flies like a banana.

  /// Bram Moolenaar -- b...@moolenaar.net -- 
 http://www.Moolenaar.nethttp://www.moolenaar.net/  \\\
 ///sponsor Vim, vote for features -- 
 http://www.Vim.org/sponsor/http://www.vim.org/sponsor/\\\
 \\\download, build and distribute -- 
 http://www.A-A-P.orghttp://www.a-a-p.org/   ///
  \\\help me help AIDS victims -- 
 http://ICCF-Holland.orghttp://iccf-holland.org/   ///

  

I have modified the patch. The name is now margincolumn. The behavior is:
'mc' = 0 - off
'mc'  0 - highlightes the column.
'mc'  0 - makes 'mc' = 'tw + 1' and highlightes that column.

I also updated the related documentation is option.txt.

Thanks
_Lone

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



margincolumn.patch
Description: Binary data

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto kaz@gmail.com wrote:
 I'm getting segmentation faults when setting the guidecolumn to any number

 The gdb backtrace output is:

 ---
 Program received signal SIGSEGV, Segmentation fault.
 0x005374fa in showruler (always=0) at screen.c:9482
 9482 le    if ((*p_stl != NUL || *curwin-w_p_stl != NUL) 
     curwin-w_status_height)
 (gdb) bt
 #0  0x005374fa in showruler (always=0) at screen.c:9482
 #1  0x004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
 #2  0x004a6d1f in main (argc=2, argv=0x7fff53767528) at main.c:939
 ---

More info. The relevant variables:
--
(gdb) print p_stl
$11 = (char_u *) 0x126ebc0 
(gdb) print *p_stl
$12 = 0 '\0'
(gdb) print curwin-w_onebuf_opt-wo_stl   (curwin-w_p_stl)
$13 = (char_u *) 0x0
(gdb) print curwin-w_status_height
$14 = 0
-

My C knowledge is limited and my gdb experience too so let me know if
I can give some more info.

-- 
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On May 2, 7:32 pm, Kazuo Teramoto kaz@gmail.com wrote:
 On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto kaz@gmail.com wrote:
  I'm getting segmentation faults when setting the guidecolumn to any number

  The gdb backtrace output is:

  ---
  Program received signal SIGSEGV, Segmentation fault.
  0x005374fa in showruler (always=0) at screen.c:9482
  9482 le    if ((*p_stl != NUL || *curwin-w_p_stl != NUL) 
      curwin-w_status_height)
  (gdb) bt
  #0  0x005374fa in showruler (always=0) at screen.c:9482
  #1  0x004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
  #2  0x004a6d1f in main (argc=2, argv=0x7fff53767528) at main.c:939
  ---

 More info. The relevant variables:
 --
 (gdb) print p_stl
 $11 = (char_u *) 0x126ebc0 
 (gdb) print *p_stl
 $12 = 0 '\0'
 (gdb) print curwin-w_onebuf_opt-wo_stl   (curwin-w_p_stl)
 $13 = (char_u *) 0x0
 (gdb) print curwin-w_status_height
 $14 = 0
 -

 My C knowledge is limited and my gdb experience too so let me know if
 I can give some more info.

 --
 «Dans la vie, rien n'est à craindre, tout est à comprendre»
 Marie Sklodowska Curie.

Are you running on Linux/Unix? I don't have Linux/Unix and I have only
tested with Windows. Can someone else who has access to *nix please
take a look? The crash seems to be in an area outside of the patch
changes but can very well be related to the patch.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

On Sun, May 3, 2009 at 12:11 AM, _Lone lost.stran...@gmail.com wrote:
 Are you running on Linux/Unix? I don't have Linux/Unix and I have only
 tested with Windows. Can someone else who has access to *nix please
 take a look? The crash seems to be in an area outside of the patch
 changes but can very well be related to the patch.
Yes I use Linux (I need to change the paths from \ to /) more
precisely Arch Linux (64 bits)

-- 
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Bram Moolenaar]

Pankaj Garg wrote:

 On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote:
  On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote:
 
   The name 'guidecolumn' starts with gui, which is confusing, since it
   also works in a terminal. =A0'margincolumn' perhaps?
 
  I agree. If a user uses :help guiC-D for example, they would NOT be
  expecting 'guidecolumn' to show up!
 
   I think the value 0 should be used to have a column at 'textwidth'.
   That way you can see where a line will be broken when it's formatted,
   without having to set two options. =A0A negative value can be used to
   disable the column.
 
  I think we should try to make this option consistent with other
  options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
  disable it, and making this one use negative numbers may get
  confusing.
 
  Is it possible to use string or character values, or can only numbers
  be entered? I can't think of any options that do this, but things like
  line() can take several strings with special meaning. Perhaps the
  guidecolumn could be disabled when set to 0, set to the textwidth when
  set to tw, and set to the wrap margin when set to wm? I think
  something like this would be more consistent with other options and
  therefore more intuitive for users.
 
   I didn't have time to check for any problems with this patch, I hope
   others have tried it out and report any problems noticed.
 
  I haven't tried the patch, but I'm certainly interested in the
  feature. I'd probably use this instead of the autocmds I have set up
  to use a matchadd() on long lines.
 
  What is this option local to? If it's just global at the moment, I
  think it should be local either to the buffer (because that's what
  textwidth is local to) or the window. I could see a use case where a
  user might want a guidecolumn for the file in one window, but turn it
  off for a window in diff mode in another tab or something.
 
 The option is local to window. I agree margincolumn is a better name.
 I am also fine with a value of 0 meaning textwidth, however as Ben
 mentioned, that seems a little unintuitive. Should we convert it to
 string?
 Are there other example where numeric options are taking string?
 
 Please let me know what you prefer and I can do whatever option
 everyone agrees to.

It's possible to use a string, but more difficult to handle.  And easier
to set a wrong value, thus more error checking is needed.
If we want to use zero for off, we could use -1 for using the
'textwidth' value.

-- 
Time flies like an arrow.
Fruit flies like a banana.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Gary Johnson]

On 2009-05-01, Bram Moolenaar wrote:
 Pankaj Garg wrote:
 
  On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote:
   On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote:
  
The name 'guidecolumn' starts with gui, which is confusing, since it
also works in a terminal.  'margincolumn' perhaps?
  
   I agree. If a user uses :help guiC-D for example, they would NOT be
   expecting 'guidecolumn' to show up!
  
I think the value 0 should be used to have a column at 'textwidth'.
That way you can see where a line will be broken when it's formatted,
without having to set two options. =A0A negative value can be used to
disable the column.
  
   I think we should try to make this option consistent with other
   options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
   disable it, and making this one use negative numbers may get
   confusing.
  
   Is it possible to use string or character values, or can only numbers
   be entered? I can't think of any options that do this, but things like
   line() can take several strings with special meaning. Perhaps the
   guidecolumn could be disabled when set to 0, set to the textwidth when
   set to tw, and set to the wrap margin when set to wm? I think
   something like this would be more consistent with other options and
   therefore more intuitive for users.
  
I didn't have time to check for any problems with this patch, I hope
others have tried it out and report any problems noticed.
  
   I haven't tried the patch, but I'm certainly interested in the
   feature. I'd probably use this instead of the autocmds I have set up
   to use a matchadd() on long lines.
  
   What is this option local to? If it's just global at the moment, I
   think it should be local either to the buffer (because that's what
   textwidth is local to) or the window. I could see a use case where a
   user might want a guidecolumn for the file in one window, but turn it
   off for a window in diff mode in another tab or something.
  
  The option is local to window. I agree margincolumn is a better name.
  I am also fine with a value of 0 meaning textwidth, however as Ben
  mentioned, that seems a little unintuitive. Should we convert it to
  string?
  Are there other example where numeric options are taking string?
  
  Please let me know what you prefer and I can do whatever option
  everyone agrees to.
 
 It's possible to use a string, but more difficult to handle.  And easier
 to set a wrong value, thus more error checking is needed.
 If we want to use zero for off, we could use -1 for using the
 'textwidth' value.

If we use any special value, whether character or numeric, to set
guidecolumn/margincolumn to the right margin, I suggest that the
column be 'textwidth + 1 rather than 'textwidth'.  I've been using
this patch for a few weeks now and it looks better to me to have the
highlighting at the first out-of-bounds column rather than at the
last in-bounds column.

As for the name, I don't see 'guidecolumn' as being a problem.  I
doubt that anyone would confuse it with a GUI command.  There are
lots of English words having the same initial letters but unrelated
meanings.  :help comm^D shows some examples of this.

I see two problems with 'margincolumn'.  The first is that
highlighting the right margin is but one application for this
feature.  The second is that 'margincolumn' implies to me that its
location automatically tracks the right margin (i.e., 'textwidth' or
'wrapmargin') which it currently doesn't.  While that tracking
feature may be added following the discussions in this thread, the
highlighting will be of the right margin only for a particular value
of 'margincolumn'.

Regards,
Gary



--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Matt Wozniski]

On Fri, May 1, 2009 at 2:42 PM, Gary Johnson wrote:

 On 2009-05-01, Bram Moolenaar wrote:
 Pankaj Garg wrote:

  On Apr 30, 9:30 am, Ben Fritz wrote:
   On Apr 29, 11:42 am, Bram Moolenaar wrote:
  
The name 'guidecolumn' starts with gui, which is confusing, since it
also works in a terminal.  'margincolumn' perhaps?
  
   I agree. If a user uses :help guiC-D for example, they would NOT be
   expecting 'guidecolumn' to show up!

 As for the name, I don't see 'guidecolumn' as being a problem.  I
 doubt that anyone would confuse it with a GUI command.  There are
 lots of English words having the same initial letters but unrelated
 meanings.  :help comm^D shows some examples of this.

 I see two problems with 'margincolumn'.  The first is that
 highlighting the right margin is but one application for this
 feature.  The second is that 'margincolumn' implies to me that its
 location automatically tracks the right margin (i.e., 'textwidth' or
 'wrapmargin') which it currently doesn't.  While that tracking
 feature may be added following the discussions in this thread, the
 highlighting will be of the right margin only for a particular value
 of 'margincolumn'.

I agree.  I think that 'guidecolumn' is a much better name.  Whenever
people show up in freenode's #vim asking about this feature, the first
phrase they use for it is guide column or guide line, presumably
this is because that's what other editors call it.  Differing because
of the aesthetics of having an option whose first 3 letters make it
appear with gui options when completing from the help is just going to
make things much harder for people looking for a guide column option,
not significantly easier for those trying to figure out which of the
gui* options they want.  Also, I agree with Gary - it's not
inconceivable that someone might want two guides at different spots
representing different things, which would mean that the margincolumn
name is much more misleading.

~Matt

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_sc_]

On Friday 01 May 2009 2:23 pm, Matt Wozniski wrote:
 
 I agree.  I think that 'guidecolumn' is a much better name.  Whenever
 people show up in freenode's #vim asking about this feature, the first
 phrase they use for it is guide column or guide line, presumably
 this is because that's what other editors call it.  Differing because
 of the aesthetics of having an option whose first 3 letters make it
 appear with gui options when completing from the help is just going to
 make things much harder for people looking for a guide column option,
 not significantly easier for those trying to figure out which of the
 gui* options they want.  Also, I agree with Gary - it's not
 inconceivable that someone might want two guides at different spots
 representing different things, which would mean that the margincolumn
 name is much more misleading.

looking in my crystal ball, i foresee people tying multiple guide
columns to the columns of those variable width tabs that are
currently struggling for acceptance, writing scripts to set them
both at the same time, and moving them around to suit the width of
the data in their tables

sc



--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Ben Fritz]

On Apr 29, 11:42 am, Bram Moolenaar b...@moolenaar.net wrote:

 The name 'guidecolumn' starts with gui, which is confusing, since it
 also works in a terminal.  'margincolumn' perhaps?


I agree. If a user uses :help guiC-D for example, they would NOT be
expecting 'guidecolumn' to show up!

 I think the value 0 should be used to have a column at 'textwidth'.
 That way you can see where a line will be broken when it's formatted,
 without having to set two options.  A negative value can be used to
 disable the column.


I think we should try to make this option consistent with other
options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
disable it, and making this one use negative numbers may get
confusing.

Is it possible to use string or character values, or can only numbers
be entered? I can't think of any options that do this, but things like
line() can take several strings with special meaning. Perhaps the
guidecolumn could be disabled when set to 0, set to the textwidth when
set to tw, and set to the wrap margin when set to wm? I think
something like this would be more consistent with other options and
therefore more intuitive for users.

 I didn't have time to check for any problems with this patch, I hope
 others have tried it out and report any problems noticed.


I haven't tried the patch, but I'm certainly interested in the
feature. I'd probably use this instead of the autocmds I have set up
to use a matchadd() on long lines.

What is this option local to? If it's just global at the moment, I
think it should be local either to the buffer (because that's what
textwidth is local to) or the window. I could see a use case where a
user might want a guidecolumn for the file in one window, but turn it
off for a window in diff mode in another tab or something.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On Apr 30, 9:30 am, Ben Fritz fritzophre...@gmail.com wrote:
 On Apr 29, 11:42 am, Bram Moolenaar b...@moolenaar.net wrote:



  The name 'guidecolumn' starts with gui, which is confusing, since it
  also works in a terminal.  'margincolumn' perhaps?

 I agree. If a user uses :help guiC-D for example, they would NOT be
 expecting 'guidecolumn' to show up!

  I think the value 0 should be used to have a column at 'textwidth'.
  That way you can see where a line will be broken when it's formatted,
  without having to set two options.  A negative value can be used to
  disable the column.

 I think we should try to make this option consistent with other
 options. 'textwidth' and 'wrapmargin' and others use a value of 0 to
 disable it, and making this one use negative numbers may get
 confusing.

 Is it possible to use string or character values, or can only numbers
 be entered? I can't think of any options that do this, but things like
 line() can take several strings with special meaning. Perhaps the
 guidecolumn could be disabled when set to 0, set to the textwidth when
 set to tw, and set to the wrap margin when set to wm? I think
 something like this would be more consistent with other options and
 therefore more intuitive for users.

  I didn't have time to check for any problems with this patch, I hope
  others have tried it out and report any problems noticed.

 I haven't tried the patch, but I'm certainly interested in the
 feature. I'd probably use this instead of the autocmds I have set up
 to use a matchadd() on long lines.

 What is this option local to? If it's just global at the moment, I
 think it should be local either to the buffer (because that's what
 textwidth is local to) or the window. I could see a use case where a
 user might want a guidecolumn for the file in one window, but turn it
 off for a window in diff mode in another tab or something.

The option is local to window. I agree margincolumn is a better name.
I am also fine with a value of 0 meaning textwidth, however as Ben
mentioned, that seems a little unintuitive. Should we convert it to
string?
Are there other example where numeric options are taking string?

Please let me know what you prefer and I can do whatever option
everyone agrees to.

Thanks
_Lone_Stranger
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Bram Moolenaar]

Pankaj Garg wrote:

 On Apr 14, 10:29 pm, Matt Wozniski m...@drexel.edu wrote:
  On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger
 
  dennis.benzin...@gmx.net wrote:
 
   Hi!
 
   Am 14.04.2009 23:18, _Lone schrieb:
   To set 'guidecolumn' you can do
   :set guidecolumn=N
   where N is the column. If N is 0 then guidecolumn is turned off. It is
   highly unlikely that a user would want the guidecolumn at column 0 but
   the syntax seems odd so let me know if you think there can be a better
   way to do this.
   [...]
 
   Why don't you use -1 (or every negative number) to turn off the guide
   column?
 
  Or use = 0 for off and 1 for the first column...  which is more
  consistent with how commands like gC-g and such show things...
 
  ~Matt

 I changed the behavior to make guidecolumn 1-based instead of 0-based,
 added checks to make sure it is set to 0+ value and 0 turns it off.
 Also added help text in options.txt. Google groups does not allow me
 to attach files so I would do a separate reply from gmail with the
 patch file.

 Please let me know if this looks good and can be incorporated in VIM.

The name 'guidecolumn' starts with gui, which is confusing, since it
also works in a terminal.  'margincolumn' perhaps?

I think the value 0 should be used to have a column at 'textwidth'.
That way you can see where a line will be broken when it's formatted,
without having to set two options.  A negative value can be used to
disable the column.

I didn't have time to check for any problems with this patch, I hope
others have tried it out and report any problems noticed.

-- 
Mental Floss prevents moral decay!

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 16/04/09 22:33, Thomas Ibbotson wrote:
[...]
 This would be very good used in conjuction with the 'textwidth' option.
 When I first used vim to write git commit messages I was taken by
 surprise by the automatic line wrapping as I hadn't come across it
 before. A line showing where this was going to happen would make it
 clearer what was going on. Would it make sense to be able to set both
 the textwidth and the guidecolumn together with one command?

 Tom
[...]

You can set any number of options with one :set command:

:set tw=75 guidecolumn=76


Best regards,
Tony.
-- 
Famous last words:
(1) Don't worry, I can handle it.
(2) You and what army?
(3) If you were as smart as you think you are, you wouldn't be
 a cop.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Tony Mechelynck]

On 16/04/09 03:55, _Lone wrote:
[...]
 Can one of the maintainer of the VIM please review this patch and let
 me know the feedback and whether this can be accepted or not? Once
 this is accepted, I would work on changing it for the GUI but I want
 that to be a different patch (as that is sort of like enhancements).

 Thanks
 _Lone

In this context, one of the maintainer (sic) if the VIM means Bram, 
and Bram alone. He will probably answer someday, but he has a lot of work.

Also, don't put your hopes too high. Instead of once this is accepted, 
you should think of if this is accepted.


Best regards,
Tony.
-- 
Passionate hatred can give meaning and purpose to an empty life.
-- Eric Hoffer

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Hari Krishna Dara]

On Thu, Apr 16, 2009 at 1:51 AM, Tony Mechelynck
antoine.mechely...@gmail.com wrote:

 On 15/04/09 21:57, Ingo Karkat wrote:

 On 15-Apr-09 21:41, _Lone wrote:
 On Apr 15, 11:36 am, Gary Johnsongaryj...@spocom.com  wrote:
 On 2009-04-15, _Lone wrote:
 On Apr 14, 8:50 pm, Nico Webernicolaswe...@gmx.de  wrote:
 To set 'guidecolumn' you can do
 :set guidecolumn=N
 where N is the column. If N is 0 then guidecolumn is turned off. It is
 highly unlikely that a user would want the guidecolumn at column 0 but
 the syntax seems odd so let me know if you think there can be a better
 way to do this.
 The patch still needs to be tested thorougly and tweaked but I wanted
 to get a general idea, if you guys think it has chances of getting
 accepted.
 Could you add that in gui mode a 1px line is drawn to the right of
 guidecolumn instead of highlighting the column's background? That'd be
 awesome (I believe there is a line drawing function already that is
 used to draw the squiggly lines below misspelled words in gui mode).
 Nico
 If the patch gets accepted then I can try to add what you suggested,
 if other people agree on varying behavior between console and gui
 builds.
 I haven't tried the patch yet, but if I understand correctly, it
 would normally be used to highlight the column to the right of the
 'textwidth' column, so that text would be within the guidecolumn
 only if the line was too long.  If guidecolumn is used that way,
 then I think the 1px line should be drawn on the left side of the
 guidecolumn, not on the right side.

 Regards,
 Gary- Hide quoted text -

 - Show quoted text -

 I agree, if it is decided that in GUI build, drawing a 1px line is
 better than highlighting the column background then the line should be
 on the left edge of the specified column. However I feel that the
 behavior should be same for CUI and GUI builds i.e. highlight the
 column background but I am flexible to what others agree upon.

 +1 for the 1px line in the GUI. If 'guifg' is used for the line, and 'guibg' 
 for
 the column, one can have one or the other (or even both).

 Of course, feature parity between GUI and console is very desirable, but why
 ignore the superior capabilities of the GUI? The squiggly line undercurl
 highlighting (used for spell checking) is only available in the GUI, too, 
 but it
 is very helpful, and similar to what other editors do. IMO, the same applies 
 to
 the guidecolumn.

 -- regards, ingo

 Hm, I haven't read the patch, but maybe define a new gui=column (or
 something) for highlighting, which would add a one- or two-pixel
 highlighting at the left edge of the current character cell in guisp
 highlighting? So the colour of the guidecolumn could be set by something
 like

     hi GuideColumn term=reverse ctermbg=yellow gui=column guisp=red

 ?


+1 for adding it as a highlighting option, that way it can be used for
other purposes (e.g., table columns), not just for guidecolumn.
-- 
Hari


 Best regards,
 Tony.
 --
 hundred-and-one symptoms of being an internet addict:
 5. You find yourself brainstorming for new subjects to search.

 


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Bram Moolenaar]

Pankaj Garg wrote:

 On Apr 15, 10:17 am, _Lone lost.stran...@gmail.com wrote:
  On Wed, Apr 15, 2009 at 10:16 AM, _Lone lost.stran...@gmail.com wrote:
 
   On Apr 14, 10:29 pm, Matt Wozniski m...@drexel.edu wrote:
On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger
 
dennis.benzin...@gmx.net wrote:
 
 Hi!
 
 Am 14.04.2009 23:18, _Lone schrieb:
 To set 'guidecolumn' you can do
 :set guidecolumn=N
 where N is the column. If N is 0 then guidecolumn is turned off. It 
 is
 highly unlikely that a user would want the guidecolumn at column 0 
 but
 the syntax seems odd so let me know if you think there can be a 
 better
 way to do this.
 [...]
 
 Why don't you use -1 (or every negative number) to turn off the guide
 column?
 
Or use = 0 for off and 1 for the first column...  which is more
consistent with how commands like gC-g and such show things...
 
~Matt
 
   I changed the behavior to make guidecolumn 1-based instead of 0-based,
   added checks to make sure it is set to 0+ value and 0 turns it off.
   Also added help text in options.txt. Google groups does not allow me
   to attach files so I would do a separate reply from gmail with the
   patch file.
 
   Please let me know if this looks good and can be incorporated in VIM.
 
   Thanks
   _Lone.
 
  Attached is the patch file.
 
   guidecolumn.patch
  15KViewDownload- Hide quoted text -
 
  - Show quoted text -
 
 Can one of the maintainer of the VIM please review this patch and let
 me know the feedback and whether this can be accepted or not? Once
 this is accepted, I would work on changing it for the GUI but I want
 that to be a different patch (as that is sort of like enhancements).

It's in my todo list.  That list is very long though...

-- 
DEAD PERSON:  I'm getting better!
CUSTOMER: No, you're not -- you'll be stone dead in a moment.
MORTICIAN:Oh, I can't take him like that -- it's against regulations.
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Gary Johnson]

On 2009-04-16, Thomas Ibbotson wrote:

 This would be very good used in conjuction with the 'textwidth' option.
 When I first used vim to write git commit messages I was taken by
 surprise by the automatic line wrapping as I hadn't come across it
 before. A line showing where this was going to happen would make it
 clearer what was going on. Would it make sense to be able to set both
 the textwidth and the guidecolumn together with one command?

As part of vim, no, but as your own command, sure.

command -nargs=1 Textwidth silent! let textwidth=args | let 
guidecolumn=args+1

Regards,
Gary



--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On Apr 14, 10:29 pm, Matt Wozniski m...@drexel.edu wrote:
 On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger

 dennis.benzin...@gmx.net wrote:

  Hi!

  Am 14.04.2009 23:18, _Lone schrieb:
  To set 'guidecolumn' you can do
  :set guidecolumn=N
  where N is the column. If N is 0 then guidecolumn is turned off. It is
  highly unlikely that a user would want the guidecolumn at column 0 but
  the syntax seems odd so let me know if you think there can be a better
  way to do this.
  [...]

  Why don't you use -1 (or every negative number) to turn off the guide
  column?

 Or use = 0 for off and 1 for the first column...  which is more
 consistent with how commands like gC-g and such show things...

 ~Matt

I changed the behavior to make guidecolumn 1-based instead of 0-based,
added checks to make sure it is set to 0+ value and 0 turns it off.
Also added help text in options.txt. Google groups does not allow me
to attach files so I would do a separate reply from gmail with the
patch file.

Please let me know if this looks good and can be incorporated in VIM.

Thanks
_Lone.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On Apr 14, 8:50 pm, Nico Weber nicolaswe...@gmx.de wrote:
  To set 'guidecolumn' you can do
  :set guidecolumn=N
  where N is the column. If N is 0 then guidecolumn is turned off. It is
  highly unlikely that a user would want the guidecolumn at column 0 but
  the syntax seems odd so let me know if you think there can be a better
  way to do this.

  The patch still needs to be tested thorougly and tweaked but I wanted
  to get a general idea, if you guys think it has chances of getting
  accepted.

 Could you add that in gui mode a 1px line is drawn to the right of  
 guidecolumn instead of highlighting the column's background? That'd be  
 awesome (I believe there is a line drawing function already that is  
 used to draw the squiggly lines below misspelled words in gui mode).

 Nico

If the patch gets accepted then I can try to add what you suggested,
if other people agree on varying behavior between console and gui
builds.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Gary Johnson]

On 2009-04-15, _Lone wrote:
 On Apr 14, 8:50 pm, Nico Weber nicolaswe...@gmx.de wrote:
   To set 'guidecolumn' you can do
   :set guidecolumn=N
   where N is the column. If N is 0 then guidecolumn is turned off. It is
   highly unlikely that a user would want the guidecolumn at column 0 but
   the syntax seems odd so let me know if you think there can be a better
   way to do this.
 
   The patch still needs to be tested thorougly and tweaked but I wanted
   to get a general idea, if you guys think it has chances of getting
   accepted.
 
  Could you add that in gui mode a 1px line is drawn to the right of  
  guidecolumn instead of highlighting the column's background? That'd be  
  awesome (I believe there is a line drawing function already that is  
  used to draw the squiggly lines below misspelled words in gui mode).
 
  Nico
 
 If the patch gets accepted then I can try to add what you suggested,
 if other people agree on varying behavior between console and gui
 builds.

I haven't tried the patch yet, but if I understand correctly, it
would normally be used to highlight the column to the right of the
'textwidth' column, so that text would be within the guidecolumn
only if the line was too long.  If guidecolumn is used that way,
then I think the 1px line should be drawn on the left side of the
guidecolumn, not on the right side.

Regards,
Gary



--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[_Lone]

On Apr 15, 11:36 am, Gary Johnson garyj...@spocom.com wrote:
 On 2009-04-15, _Lone wrote:
  On Apr 14, 8:50 pm, Nico Weber nicolaswe...@gmx.de wrote:
To set 'guidecolumn' you can do
:set guidecolumn=N
where N is the column. If N is 0 then guidecolumn is turned off. It is
highly unlikely that a user would want the guidecolumn at column 0 but
the syntax seems odd so let me know if you think there can be a better
way to do this.

The patch still needs to be tested thorougly and tweaked but I wanted
to get a general idea, if you guys think it has chances of getting
accepted.

   Could you add that in gui mode a 1px line is drawn to the right of  
   guidecolumn instead of highlighting the column's background? That'd be  
   awesome (I believe there is a line drawing function already that is  
   used to draw the squiggly lines below misspelled words in gui mode).

   Nico

  If the patch gets accepted then I can try to add what you suggested,
  if other people agree on varying behavior between console and gui
  builds.

 I haven't tried the patch yet, but if I understand correctly, it
 would normally be used to highlight the column to the right of the
 'textwidth' column, so that text would be within the guidecolumn
 only if the line was too long.  If guidecolumn is used that way,
 then I think the 1px line should be drawn on the left side of the
 guidecolumn, not on the right side.

 Regards,
 Gary- Hide quoted text -

 - Show quoted text -

I agree, if it is decided that in GUI build, drawing a 1px line is
better than highlighting the column background then the line should be
on the left edge of the specified column. However I feel that the
behavior should be same for CUI and GUI builds i.e. highlight the
column background but I am flexible to what others agree upon.

Thanks
_Lone
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Ingo Karkat]

On 15-Apr-09 21:41, _Lone wrote:
 On Apr 15, 11:36 am, Gary Johnson garyj...@spocom.com wrote:
 On 2009-04-15, _Lone wrote:
 On Apr 14, 8:50 pm, Nico Weber nicolaswe...@gmx.de wrote:
 To set 'guidecolumn' you can do
 :set guidecolumn=N
 where N is the column. If N is 0 then guidecolumn is turned off. It is
 highly unlikely that a user would want the guidecolumn at column 0 but
 the syntax seems odd so let me know if you think there can be a better
 way to do this.
 The patch still needs to be tested thorougly and tweaked but I wanted
 to get a general idea, if you guys think it has chances of getting
 accepted.
 Could you add that in gui mode a 1px line is drawn to the right of  
 guidecolumn instead of highlighting the column's background? That'd be  
 awesome (I believe there is a line drawing function already that is  
 used to draw the squiggly lines below misspelled words in gui mode).
 Nico
 If the patch gets accepted then I can try to add what you suggested,
 if other people agree on varying behavior between console and gui
 builds.
 I haven't tried the patch yet, but if I understand correctly, it
 would normally be used to highlight the column to the right of the
 'textwidth' column, so that text would be within the guidecolumn
 only if the line was too long.  If guidecolumn is used that way,
 then I think the 1px line should be drawn on the left side of the
 guidecolumn, not on the right side.

 Regards,
 Gary- Hide quoted text -

 - Show quoted text -
 
 I agree, if it is decided that in GUI build, drawing a 1px line is
 better than highlighting the column background then the line should be
 on the left edge of the specified column. However I feel that the
 behavior should be same for CUI and GUI builds i.e. highlight the
 column background but I am flexible to what others agree upon.

+1 for the 1px line in the GUI. If 'guifg' is used for the line, and 'guibg' 
for 
the column, one can have one or the other (or even both).

Of course, feature parity between GUI and console is very desirable, but why 
ignore the superior capabilities of the GUI? The squiggly line undercurl 
highlighting (used for spell checking) is only available in the GUI, too, but 
it 
is very helpful, and similar to what other editors do. IMO, the same applies to 
the guidecolumn.

-- regards, ingo


--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

[Patch] Add support for guidecolumn in VIM

[Pankaj Garg]

Hi Everyone,

This is my first patch for VIM so pardon me if I did not follow any
instructions properly.

This patch would allow you to create a vertical highlighted line at a
specified column such as column 80. Very useful if you don't want your code
to exceed 80 columns as followed by many projects (I think including VIM).

The thread below is where I initially mentioned this and asked if it would
be a good idea.

http://groups.google.com/group/vim_use/browse_thread/thread/3ee72b0e73dee6c7/f91c21a6b00787b8?lnk=gstq=a+border+at+fixed+width#f91c21a6b00787b8

Please let me know if there are any issues with the patch. I have tested it
and it seems to work fine (with cursorcolumn as well). But as this is my
first patch, please let me know if I missed something.

The attached guidecolumn.patch.txt contains the patch in the format
specified at the VIM WIKI and guidecolumn.patch is created using CVS patch
feature in TortoiseCVS.

Thanks
_Lone

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

*** src\option.cTue Apr 14 01:38:04 2009
--- mod\option.cTue Apr 14 00:10:12 2009
***
*** 227,232 
--- 227,233 
  #ifdef FEAT_SYN_HL
  # define PV_CUC   OPT_WIN(WV_CUC)
  # define PV_CUL   OPT_WIN(WV_CUL)
+ # define PV_GUC   OPT_WIN(WV_GUC)
  #endif
  #ifdef FEAT_STL_OPT
  # define PV_STL   OPT_BOTH(OPT_WIN(WV_STL))
***
*** 446,452 
  #if defined(FEAT_DIFF) || defined(FEAT_FOLDING) || defined(FEAT_SPELL) \
|| defined(FEAT_VERTSPLIT) || defined(FEAT_CLIPBOARD) \
|| defined(FEAT_INS_EXPAND) || defined(FEAT_SYN_HL)
! # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,c:VertSplit,t:Title,v:Visual,V:VisualNOS,w:WarningMsg,W:WildMenu,f:Folded,F:FoldColumn,A:DiffAdd,C:DiffChange,D:DiffDelete,T:DiffText,:SignColumn,B:SpellBad,P:SpellCap,R:SpellRare,L:SpellLocal,+:Pmenu,=:PmenuSel,x:PmenuSbar,X:PmenuThumb,*:TabLine,#:TabLineSel,_:TabLineFill,!:CursorColumn,.:CursorLine
  #else
  # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,t:Title,v:Visual,w:WarningMsg,W:WildMenu,:SignColumn,*:TabLine,#:TabLineSel,_:TabLineFill
  #endif
--- 447,453 
  #if defined(FEAT_DIFF) || defined(FEAT_FOLDING) || defined(FEAT_SPELL) \
|| defined(FEAT_VERTSPLIT) || defined(FEAT_CLIPBOARD) \
|| defined(FEAT_INS_EXPAND) || defined(FEAT_SYN_HL)
! # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,c:VertSplit,t:Title,v:Visual,V:VisualNOS,w:WarningMsg,W:WildMenu,f:Folded,F:FoldColumn,A:DiffAdd,C:DiffChange,D:DiffDelete,T:DiffText,:SignColumn,B:SpellBad,P:SpellCap,R:SpellRare,L:SpellLocal,+:Pmenu,=:PmenuSel,x:PmenuSbar,X:PmenuThumb,*:TabLine,#:TabLineSel,_:TabLineFill,!:CursorColumn,.:CursorLine,G:GuideColumn
  #else
  # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,t:Title,v:Visual,w:WarningMsg,W:WildMenu,:SignColumn,*:TabLine,#:TabLineSel,_:TabLineFill
  #endif
***
*** 1209,1214 
--- 1210,1222 
{(char_u *)NULL, (char_u *)0L}
  #endif
},
+ {guidecolumn, guc,  P_NUM|P_VI_DEF|P_RWIN,
+ #ifdef FEAT_SYN_HL
+   (char_u *)VAR_WIN, PV_GUC,
+ #else
+   (char_u *)NULL, PV_NONE,
+ #endif
+   {(char_u *)0L, (char_u *)0L}},
  {guifont,   gfn,  P_STRING|P_VI_DEF|P_RCLR|P_COMMA|P_NODUP,
  #ifdef FEAT_GUI
(char_u *)p_guifont, PV_NONE,
***
*** 9095,9100 
--- 9103,9109 
  #ifdef FEAT_SYN_HL
case PV_CUC:return (char_u *)(curwin-w_p_cuc);
case PV_CUL:return (char_u *)(curwin-w_p_cul);
+   case PV_GUC:return (char_u *)(curwin-w_p_guc);
  #endif
  #ifdef FEAT_DIFF
case PV_DIFF:   return (char_u *)(curwin-w_p_diff);
*** src\option.hTue Apr 14 01:38:05 2009
--- mod\option.hSun Apr 12 10:19:21 2009
***
*** 1059,1064 
--- 1059,1065 
  #ifdef FEAT_SYN_HL
  , WV_CUC
  , WV_CUL
+ , WV_GUC
  #endif
  #ifdef FEAT_STL_OPT
  , WV_STL
*** src\screen.cTue Apr 14 01:38:06 2009
--- mod\screen.cTue Apr 14 01:30:58 2009
***
*** 2614,2619 
--- 2614,2620 
  int   has_syntax = FALSE; /* this buffer has syntax 
highl. */
  int   save_did_emsg;
  int   eol_hl_off = 0; 

[Patch] Add support for guidecolumn in VIM

[_Lone]

Hi Everyone,

This is my first patch for VIM so pardon me if I did not follow any
instructions properly.

This patch would allow you to create a vertical highlighted line at a
specified column such as column 80. Very useful if you don't want your code
to exceed 80 columns as followed by many projects (I think including VIM).

The thread below is where I initially mentioned this and asked if it would
be a good idea.

http://groups.google.com/group/vim_use/browse_thread/thread/3ee72b0e73dee6c7/f91c21a6b00787b8?lnk=gstq=a+border+at+fixed+width#f91c21a6b00787b8

Please let me know if there are any issues with the patch. I have tested it
and it seems to work fine (with cursorcolumn as well). But as this is my
first patch, please let me know if I missed something.

The attached guidecolumn.patch.txt contains the patch in the format
specified at the VIM WIKI and guidecolumn.patch is created using CVS patch
feature in TortoiseCVS.

Thanks
_Lone

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

*** src\option.cTue Apr 14 01:38:04 2009
--- mod\option.cTue Apr 14 00:10:12 2009
***
*** 227,232 
--- 227,233 
  #ifdef FEAT_SYN_HL
  # define PV_CUC   OPT_WIN(WV_CUC)
  # define PV_CUL   OPT_WIN(WV_CUL)
+ # define PV_GUC   OPT_WIN(WV_GUC)
  #endif
  #ifdef FEAT_STL_OPT
  # define PV_STL   OPT_BOTH(OPT_WIN(WV_STL))
***
*** 446,452 
  #if defined(FEAT_DIFF) || defined(FEAT_FOLDING) || defined(FEAT_SPELL) \
|| defined(FEAT_VERTSPLIT) || defined(FEAT_CLIPBOARD) \
|| defined(FEAT_INS_EXPAND) || defined(FEAT_SYN_HL)
! # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,c:VertSplit,t:Title,v:Visual,V:VisualNOS,w:WarningMsg,W:WildMenu,f:Folded,F:FoldColumn,A:DiffAdd,C:DiffChange,D:DiffDelete,T:DiffText,:SignColumn,B:SpellBad,P:SpellCap,R:SpellRare,L:SpellLocal,+:Pmenu,=:PmenuSel,x:PmenuSbar,X:PmenuThumb,*:TabLine,#:TabLineSel,_:TabLineFill,!:CursorColumn,.:CursorLine
  #else
  # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,t:Title,v:Visual,w:WarningMsg,W:WildMenu,:SignColumn,*:TabLine,#:TabLineSel,_:TabLineFill
  #endif
--- 447,453 
  #if defined(FEAT_DIFF) || defined(FEAT_FOLDING) || defined(FEAT_SPELL) \
|| defined(FEAT_VERTSPLIT) || defined(FEAT_CLIPBOARD) \
|| defined(FEAT_INS_EXPAND) || defined(FEAT_SYN_HL)
! # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,c:VertSplit,t:Title,v:Visual,V:VisualNOS,w:WarningMsg,W:WildMenu,f:Folded,F:FoldColumn,A:DiffAdd,C:DiffChange,D:DiffDelete,T:DiffText,:SignColumn,B:SpellBad,P:SpellCap,R:SpellRare,L:SpellLocal,+:Pmenu,=:PmenuSel,x:PmenuSbar,X:PmenuThumb,*:TabLine,#:TabLineSel,_:TabLineFill,!:CursorColumn,.:CursorLine,G:GuideColumn
  #else
  # define HIGHLIGHT_INIT 
8:SpecialKey,@:NonText,d:Directory,e:ErrorMsg,i:IncSearch,l:Search,m:MoreMsg,M:ModeMsg,n:LineNr,r:Question,s:StatusLine,S:StatusLineNC,t:Title,v:Visual,w:WarningMsg,W:WildMenu,:SignColumn,*:TabLine,#:TabLineSel,_:TabLineFill
  #endif
***
*** 1209,1214 
--- 1210,1222 
{(char_u *)NULL, (char_u *)0L}
  #endif
},
+ {guidecolumn, guc,  P_NUM|P_VI_DEF|P_RWIN,
+ #ifdef FEAT_SYN_HL
+   (char_u *)VAR_WIN, PV_GUC,
+ #else
+   (char_u *)NULL, PV_NONE,
+ #endif
+   {(char_u *)0L, (char_u *)0L}},
  {guifont,   gfn,  P_STRING|P_VI_DEF|P_RCLR|P_COMMA|P_NODUP,
  #ifdef FEAT_GUI
(char_u *)p_guifont, PV_NONE,
***
*** 9095,9100 
--- 9103,9109 
  #ifdef FEAT_SYN_HL
case PV_CUC:return (char_u *)(curwin-w_p_cuc);
case PV_CUL:return (char_u *)(curwin-w_p_cul);
+   case PV_GUC:return (char_u *)(curwin-w_p_guc);
  #endif
  #ifdef FEAT_DIFF
case PV_DIFF:   return (char_u *)(curwin-w_p_diff);
*** src\option.hTue Apr 14 01:38:05 2009
--- mod\option.hSun Apr 12 10:19:21 2009
***
*** 1059,1064 
--- 1059,1065 
  #ifdef FEAT_SYN_HL
  , WV_CUC
  , WV_CUL
+ , WV_GUC
  #endif
  #ifdef FEAT_STL_OPT
  , WV_STL
*** src\screen.cTue Apr 14 01:38:06 2009
--- mod\screen.cTue Apr 14 01:30:58 2009
***
*** 2614,2619 
--- 2614,2620 
  int   has_syntax = FALSE; /* this buffer has syntax 
highl. */
  int   save_did_emsg;
  int   eol_hl_off = 0; 

Re: Add support for guidecolumn in VIM

[Dennis Benzinger]

Hi!

Am 14.04.2009 23:18, _Lone schrieb:
 To set 'guidecolumn' you can do
 :set guidecolumn=N
 where N is the column. If N is 0 then guidecolumn is turned off. It is
 highly unlikely that a user would want the guidecolumn at column 0 but
 the syntax seems odd so let me know if you think there can be a better
 way to do this.
 [...]

Why don't you use -1 (or every negative number) to turn off the guide
column?


Dennis Benzinger

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Add support for guidecolumn in VIM

[Matt Wozniski]

On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger
dennis.benzin...@gmx.net wrote:

 Hi!

 Am 14.04.2009 23:18, _Lone schrieb:
 To set 'guidecolumn' you can do
 :set guidecolumn=N
 where N is the column. If N is 0 then guidecolumn is turned off. It is
 highly unlikely that a user would want the guidecolumn at column 0 but
 the syntax seems odd so let me know if you think there can be a better
 way to do this.
 [...]

 Why don't you use -1 (or every negative number) to turn off the guide
 column?

Or use = 0 for off and 1 for the first column...  which is more
consistent with how commands like gC-g and such show things...

~Matt

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---