[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.
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
_Lone
: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.
Thanks
_Lone
On Apr 14, 2:32 am, _Lone <lost.stran...@gmail.com> wrote:
> 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.
>
> 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
>
> 13KViewDownload
>
> guidecolumn.patch
> 11KViewDownload
Nico Weber
> :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
Dennis Benzinger
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
Matt Wozniski
Or use <= 0 for off and 1 for the first column... which is more
consistent with how commands like g<C-g> and such show things...
~Matt
_Lone
On Apr 14, 10:29 pm, Matt Wozniski <m...@drexel.edu> wrote:
> On Wed, Apr 15, 2009 at 1:18 AM, Dennis Benzinger
>
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.
_Lone
if other people agree on varying behavior between console and gui
builds.
Thanks
_Lone
Gary Johnson
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
_Lone
>
> - 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
Ingo Karkat
+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
_Lone
On Apr 15, 10:17 am, _Lone <lost.stran...@gmail.com> wrote:
> 15KViewDownload- Hide quoted text -
> - Show quoted text -
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
Tony Mechelynck
[...]
> 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
Tony Mechelynck
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
?
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
5. You find yourself brainstorming for new subjects to search.
Hari Krishna Dara
other purposes (e.g., table columns), not just for guidecolumn.
--
Hari
Bram Moolenaar
Pankaj Garg wrote:
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 -- Br...@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 ///
Thomas Ibbotson
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknnlhEACgkQFRlp6kAWdptdqwCfeU3NAUk0u9RUc8uIXbKfLgGy
72EAoIQCM5e0vYYSdRYcR2qMq0kcw3hF
=e7eo
-----END PGP SIGNATURE-----
Gary Johnson
> 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
Tony Mechelynck
[...]
> 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."
Bram Moolenaar
Pankaj Garg wrote:
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!
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?
>
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.
>
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.
>
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.
_Lone
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
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 gui<C-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
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.
Gary Johnson
> 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
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
Matt Wozniski
>
> On 2009-05-01, Bram Moolenaar wrote:
>> Pankaj Garg 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 gui<C-D> for example, they would NOT be
>> > > expecting 'guidecolumn' to show up!
>
> 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
_sc_
>
> 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
Tony Mechelynck
>
>
>
> 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 gui<C-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=-9999
always disabled (assuming you won't have 9999 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."
Tony Mechelynck
[...]
> 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.
Dennis Benzinger
> [...]
> 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 +=.
Regards,
Dennis Benzinger
Kazuo Teramoto
The gdb backtrace output is:
-------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x00000000005374fa 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 0x00000000005374fa in showruler (always=0) at screen.c:9482
#1 0x00000000004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
#2 0x00000000004a6d1f 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 kazuo@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.
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.
> 0x00000000005374fa 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 0x00000000005374fa in showruler (always=0) at screen.c:9482
> #1 0x00000000004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
> #2 0x00000000004a6d1f 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?
Kazuo Teramoto
-------------------------------------
(gdb) print showruler::curwin->w_p_stl
There is no member named w_p_stl.
-------------------------------------
Sorry for the triple email...
_Lone
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
Kazuo Teramoto
>
> The gdb backtrace output is:
>
> -------------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005374fa 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 0x00000000005374fa in showruler (always=0) at screen.c:9482
> #1 0x00000000004a7154 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
> #2 0x00000000004a6d1f 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.
_Lone
On May 2, 7:32 pm, Kazuo Teramoto <kaz....@gmail.com> wrote:
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
Kazuo Teramoto
> 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.
precisely Arch Linux (64 bits)
Dominique Pellé
>> 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
Ricky
Ricky
James Vega
> 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 <jame...@jamessan.com>
Dominique Pellé
> 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
Lech Lorens
> 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
_Lone
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
Dominique Pellé
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
_Lone
>
> - 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
Bram Moolenaar
Dennis Benzinger wrote:
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
Pankaj Garg wrote:
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
Tony Mechelynck
> _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 <xxxx>
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.
Tony Mechelynck
> 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.
Tony Mechelynck
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
- <xxxx> 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
Ricky
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.m...@gmail.com>
Sent: Friday, May 08, 2009 8:47 AM
To: <vim...@googlegroups.com>
Subject: 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:
> > > >> >> '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
> /// 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 -
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
Tony Mechelynck
[...]
> 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 <xxxx>, 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.
_Lone
On Jun 1, 6:28 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
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