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: More request for 2html :)

[Wu, Yue]

On Sun, May 03, 2009 at 02:50:52AM +0200, Tony Mechelynck wrote:
> 
> On 01/05/09 00:11, Wu, Yue wrote:
> >
> > I don't know the web relating technology, but I think 2html can use the tag
> > file of the current document, and then make all |foo| and *foo* in the
> > document as a hypertext? Is it hard to implement?
> >
> 
> Well, in Vim help files, |this| is indeed a link, but so is 'that'. 
> However, where it gets complicated is that not only [range] is a link, 
> but also that you can double click (or hit Ctrl-] on) any word anywhere 
> in the help text, and if there is a tag by that name (or if there isn't, 
> a tag containing that name) you'll be brought to it. But if you 
> linkified any word which appeared as a tag, you'd sometimes get 
> preposterous results. For instance, in the HTML help 
> http://vimdoc.sourceforge.net/htmldoc/ any occurrence of the pronoun 
> "it" is linkified, because there is a text object named "it" (inner HTML 
> tag block) and it has a tag.
> 

We can make things simple: make all *foo* become *foo*,
and all |foo| to |foo|

*foo* => *foo*

|foo| => |foo|

I don't know html, it's my wrongly syntax example :)

Though maybe fully hyperlink support is complicated, but we can support some
simple cases firstly.

-- 
Hi,
Wu, Yue

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

[_Lone]

On May 2, 7:32 pm, Kazuo Teramoto  wrote:
> On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto  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 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: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir

[Tony Mechelynck]

On 30/04/09 21:11, _sc_ wrote:
>
> On Thursday 30 April 2009 11:19 am, Yakov Lerner wrote:
>> When 'acd' is set, mksession uses short pathname in the typical usage which
>> leads to wrong result (the testcase below). This is biting me every time I
>> use mksession (I always have acd on).
>> The interaction of 'curdir' in  sessionoptions and 'set acd' leads to
>> apparently wrong result.
>> This patch adds additional check in ses_fname, the logic is similar to the
>> check for 'did_lcd' which already exists for the same reason.
>
> i have a "thorn-in-my-side" problem with netrw that's triggered
> when 'autochdir' is on
>
> my workaround is to have 'noautochdir' but also
>
>  autocmd BufEnter * lcd %:p:h
>
> in my vimrc -- this acts like autochdir, but does not play havoc
> with netrw -- the places i've seen autochdir create problems so
> far have been places involving "not real" buffers -- your help
> window and charles' file window are both unmodifiable "unreal"
> buffers and i can't help thinking this must be related
>
> i tried it here, replacing the 'set acd' with my autocmd, and the
> session created brought both windows up just fine
>
> 'autochdir' is taking on the character of bad boy in my opinion,
> and i am wondering if it would be appropriate to put the autocmd
> alternative in the docs under
>
>   Note: When this option is on some plugins may not work.
>
> or maybe it's time we examined the question of whether 'autochdir'
> is buggy
>
> sc
>

In my experience, :mksession interaction with local directories is, 
shall we say, less than perfect; and the session file is bulky, 
unwieldy, and largely redundant with the vimrc.

Nowadays I don't use the :mksession command anymore, but I do use 
session files, written by hand, with the minimal number of commands to 
open the windows and load the files, letting the vimrc do the bulk of 
the work. I'm attaching a session script for a rather large session, a 
script which is nowhere as big as the ones :mksession used to produce.


Best regards,
Tony.
-- 
If you didn't get caught, did you really do it?

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



Session.vim
Description: application/octetstream

Re: Add support for guidecolumn in VIM

[Kazuo Teramoto]

On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto  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 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 Fri, May 1, 2009 at 6:55 AM, Bram Moolenaar  wrote:

>
>
> Pankaj Garg wrote:
>
> > On Apr 30, 9:30=A0am, Ben Fritz  wrote:
> > > On Apr 29, 11:42=A0am, Bram Moolenaar  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 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
-~--~~~~--~~--~--~---



margincolumn.patch
Description: Binary data

Re: More request for 2html :)

[Tony Mechelynck]

On 01/05/09 00:11, Wu, Yue wrote:
> On Thu, Apr 30, 2009 at 07:05:53AM -0700, Ben Fritz wrote:
>> On Apr 29, 10:22 pm, "Wu, Yue"  wrote:
[...]
>>> new feature request comes :) If 2html supports translating the tags jumping
>>> to hypertext, it would be much more great.
>>>
>>
>> I think this would be extremely difficult to do right in Vim script,
>> and it is hard to tell exactly how to go about it. I think it would be
>> far beyond the scope of 2html.vim, and additionally (if I understand
>> you correctly) this is a task that is already accomplished by many
>> readily available tools. Just do a google search or poke around on
>> sourceforge. "Tags jumping" is kind of open to interpretation, so I'm
>> not sure exactly what you want, but there are tools to create html
>> with embedded links, tree views, etc. based on all sorts of plaintext
>> documents.
>
> I don't know the web relating technology, but I think 2html can use the tag
> file of the current document, and then make all |foo| and *foo* in the
> document as a hypertext? Is it hard to implement?
>

Well, in Vim help files, |this| is indeed a link, but so is 'that'. 
However, where it gets complicated is that not only [range] is a link, 
but also that you can double click (or hit Ctrl-] on) any word anywhere 
in the help text, and if there is a tag by that name (or if there isn't, 
a tag containing that name) you'll be brought to it. But if you 
linkified any word which appeared as a tag, you'd sometimes get 
preposterous results. For instance, in the HTML help 
http://vimdoc.sourceforge.net/htmldoc/ any occurrence of the pronoun 
"it" is linkified, because there is a text object named "it" (inner HTML 
tag block) and it has a tag.

But tags are not limited to the Vim help. You can use ctags to generate 
tags files for source programs in most languages, and then you can click 
any use of any identifier anywhere in the source, and see where it was 
defined (provided of course, that the source file containing the 
definition was one of those analyzed by ctags to produce this tagfile). 
Now an identifier can be almost any word (and, if it is e.g. a 
variable-name, it doesn't particularly stand out the way function names 
do by virtue of being followed by an open bracket).


Best regards,
Tony.
-- 
There is a theory that states: "If anyone finds out what the universe
is for it will disappear and be replaced by something more bazaarly
inexplicable."

There is another theory that states: "This has already happened "
-- Douglas Adams, "Hitch-Hikers Guide to the Galaxy"

--~--~-~--~~~---~--~~
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  wrote:
> On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto  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 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

[Kazuo Teramoto]

On Sat, May 2, 2009 at 8:09 PM, Kazuo Teramoto  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 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]

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

Fix for crash in eval.c

[Nico Weber]

Hi,

Valgrind memory checker finds several errors in vim-7.2 (patches  
1-148) with the reproduction steps described at 
http://groups.google.com/group/vim_mac/browse_thread/thread/4e0149ff4f84e3d3 
  :

==33469== Conditional jump or move depends on uninitialised value(s)
==33469==at 0x437EA: can_free_funccal (eval.c:21449)
==33469==by 0x2D213: garbage_collect (eval.c:6591)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==by 0xDC89D: normal_cmd (normal.c:653)
==33469==by 0x9F674: main_loop (main.c:1255)
==33469==by 0x9F167: main (main.c:1002)
==33469==
==33469== Conditional jump or move depends on uninitialised value(s)
==33469==at 0x437F8: can_free_funccal (eval.c:21449)
==33469==by 0x2D213: garbage_collect (eval.c:6591)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==by 0xDC89D: normal_cmd (normal.c:653)
==33469==by 0x9F674: main_loop (main.c:1255)
==33469==by 0x9F167: main (main.c:1002)
==33469==
==33469== Invalid read of size 4
==33469==at 0x2D451: dict_unref (eval.c:6709)
==33469==by 0x3E4E7: clear_tv (eval.c:18558)
==33469==by 0x3F09B: vars_clear_ext (eval.c:18994)
==33469==by 0x4382B: free_funccal (eval.c:21466)
==33469==by 0x2D240: garbage_collect (eval.c:6595)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==  Address 0x7c290f0 is 0 bytes inside a block of size 176  
free'd
==33469==at 0x25661B: free (vg_replace_malloc.c:322)
==33469==by 0xCDBDC: vim_free (misc2.c:1638)
==33469==by 0x2D59B: dict_free (eval.c:6753)
==33469==by 0x2D176: garbage_collect (eval.c:6559)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==by 0xDC89D: normal_cmd (normal.c:653)
==33469==
==33469== Invalid write of size 4
==33469==at 0x2D459: dict_unref (eval.c:6709)
==33469==by 0x3E4E7: clear_tv (eval.c:18558)
==33469==by 0x3F09B: vars_clear_ext (eval.c:18994)
==33469==by 0x4382B: free_funccal (eval.c:21466)
==33469==by 0x2D240: garbage_collect (eval.c:6595)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==  Address 0x7c290f0 is 0 bytes inside a block of size 176  
free'd
==33469==at 0x25661B: free (vg_replace_malloc.c:322)
==33469==by 0xCDBDC: vim_free (misc2.c:1638)
==33469==by 0x2D59B: dict_free (eval.c:6753)
==33469==by 0x2D176: garbage_collect (eval.c:6559)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==by 0xDC89D: normal_cmd (normal.c:653)
==33469==
==33469== Invalid read of size 4
==33469==at 0x2D45E: dict_unref (eval.c:6709)
==33469==by 0x3E4E7: clear_tv (eval.c:18558)
==33469==by 0x3F09B: vars_clear_ext (eval.c:18994)
==33469==by 0x4382B: free_funccal (eval.c:21466)
==33469==by 0x2D240: garbage_collect (eval.c:6595)
==33469==by 0x8D92E: before_blocking (getchar.c:1473)
==33469==by 0x10764F: mch_inchar (os_unix.c:385)
==33469==by 0x176A06: ui_inchar (ui.c:193)
==33469==by 0x8FFD1: inchar (getchar.c:2959)
==33469==by 0x8FB64: vgetorpeek (getchar.c:2735)
==33469==by 0x8DAA3: vgetc (getchar.c:1552)
==33469==by 0x8E05D: safe_vgetc (getchar.c:1757)
==33469==  Address

Re: Add support for guidecolumn in VIM

[Dennis Benzinger]

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


Regards,
Dennis Benzinger

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

Re: merge farsi handling into arabic.c

[Ali Gholami Rudi]

Hi Bram,

Bram Moolenaar  wrote:
> Ali Gholami Rudi wrote:
> > Farsi is quite similar to arabic except for a few letters.  This patch
> > merges farsi support into arabic.c.  AFAICS, farsi.c and fkmap option
> > seem to be obsolete (unless someone is still using the pcf fonts).
> > 
> > Also it might make sense to add a new farsi option, just like the arabic
> > option, that when set implies "set rl" and "set keymap=persian".
> 
> I don't use these languages, thus I need to rely on others to tell me
> what works best.

I've CC'ed the authors of arabic.c and farsi.c.

> After including this patch, can we drop farsi.c?

Part of it implements the input method which is now done separately
using the keymap option; those parts *are* obsolete.  Also it uses Farsi
ISIR-3342 encoding (is there anyone who uses that encoding?) while
arabic.c uses utf-8.  If the included farsi fonts are for that specific
encoding, it might make sense to drop farsi.c, fkmap option and the
fonts altogether (but I might be missing something).  Mortaza, what do
you think?

Anyway, AFAICT currently the only option for those how use utf-8 is "set
rl".  But it fails to combine farsi-specific characters and this patch
fixes it.  Note that farsi input method is already available using
"set keymap=persian".

> There should also be an update to the documentation, most users don't
> look at the source code to figure out what to do :-).

Does it make sense to add some sections to arabic.txt?  Most of it
applies to farsi, too.

Regards,
Ali

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

[Tony Mechelynck]

On 30/04/09 18:30, 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 gui  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: merge farsi handling into arabic.c

[Bram Moolenaar]

Ali Gholami Rudi wrote:

> Farsi is quite similar to arabic except for a few letters.  This patch
> merges farsi support into arabic.c.  AFAICS, farsi.c and fkmap option
> seem to be obsolete (unless someone is still using the pcf fonts).
> 
> Also it might make sense to add a new farsi option, just like the arabic
> option, that when set implies "set rl" and "set keymap=persian".

I don't use these languages, thus I need to rely on others to tell me
what works best.  After including this patch, can we drop farsi.c?

There should also be an update to the documentation, most users don't
look at the source code to figure out what to do :-).

- Bram

-- 
TIM: To the north there lies a cave,  the cave of Caerbannog, wherein, carved
 in mystic runes, upon the very living rock, the last words of Olfin
 Bedwere of Rheged make plain the last resting place of the most Holy
 Grail.
 "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: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir

[Bram Moolenaar]

Yakov Lerner wrote:

> When 'acd' is set, mksession uses short pathname in the typical usage which
> leads to wrong result (the testcase below). This is biting me every time I
> use mksession (I always have acd on).
> The interaction of 'curdir' in  sessionoptions and 'set acd' leads to
> apparently wrong result.
> This patch adds additional check in ses_fname, the logic is similar to the
> check for 'did_lcd' which already exists for the same reason.
> 
> Testcase:
> 
> echo abc >/tmp/xxx
> vim -u NONE -U NONE /tmp/xxx
> :set acd
> :he help
> :mksession! ~/xxx
> :qall!
> 
> vim -u NONE -U NONE -S ~/xxx
> ^^^ bug: upper window is empty ^^^

Thanks, I'll look into it later.

-- 
   [Autumn changed into Winter ... Winter changed into Spring ...  Spring
   changed back into Autumn and Autumn gave Winter and Spring a miss and
   went straight on into Summer ...  Until one day ...]
 "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
-~--~~~~--~~--~--~---

merge farsi handling into arabic.c

[Ali Gholami Rudi]

Hi,

Farsi is quite similar to arabic except for a few letters.  This patch
merges farsi support into arabic.c.  AFAICS, farsi.c and fkmap option
seem to be obsolete (unless someone is still using the pcf fonts).

Also it might make sense to add a new farsi option, just like the arabic
option, that when set implies "set rl" and "set keymap=persian".

Regards,
Ali

diff --git a/src/arabic.c b/src/arabic.c
index 8c1f64c..24c0b0f 100644
--- a/src/arabic.c
+++ b/src/arabic.c
@@ -15,6 +15,7 @@
  * --
  *
  * Author: Nadim Shaikli & Isam Bayazidi
+ * Farsi support added by: Ali Gholami Rudi
  *
  */
 
@@ -56,16 +57,19 @@ A_is_a(cur_c)
case a_YEH_HAMZA:
case a_ALEF:
case a_BEH:
+   case a_PEH:
case a_TEH_MARBUTA:
case a_TEH:
case a_THEH:
case a_JEEM:
+   case a_TCHEH:
case a_HAH:
case a_KHAH:
case a_DAL:
case a_THAL:
case a_REH:
case a_ZAIN:
+   case a_JEH:
case a_SEEN:
case a_SHEEN:
case a_SAD:
@@ -78,6 +82,8 @@ A_is_a(cur_c)
case a_FEH:
case a_QAF:
case a_KAF:
+   case a_FKAF:
+   case a_GAF:
case a_LAM:
case a_MEEM:
case a_NOON:
@@ -85,6 +91,7 @@ A_is_a(cur_c)
case a_WAW:
case a_ALEF_MAKSURA:
case a_YEH:
+   case a_FYEH:
return TRUE;
 }
 
@@ -109,16 +116,19 @@ A_is_s(cur_c)
case a_s_YEH_HAMZA:
case a_s_ALEF:
case a_s_BEH:
+   case a_s_PEH:
case a_s_TEH_MARBUTA:
case a_s_TEH:
case a_s_THEH:
case a_s_JEEM:
+   case a_s_TCHEH:
case a_s_HAH:
case a_s_KHAH:
case a_s_DAL:
case a_s_THAL:
case a_s_REH:
case a_s_ZAIN:
+   case a_s_JEH:
case a_s_SEEN:
case a_s_SHEEN:
case a_s_SAD:
@@ -130,6 +140,8 @@ A_is_s(cur_c)
case a_s_FEH:
case a_s_QAF:
case a_s_KAF:
+   case a_s_FKAF:
+   case a_s_GAF:
case a_s_LAM:
case a_s_MEEM:
case a_s_NOON:
@@ -137,6 +149,7 @@ A_is_s(cur_c)
case a_s_WAW:
case a_s_ALEF_MAKSURA:
case a_s_YEH:
+   case a_s_FYEH:
return TRUE;
 }
 
@@ -160,16 +173,19 @@ A_is_f(cur_c)
case a_f_YEH_HAMZA:
case a_f_ALEF:
case a_f_BEH:
+   case a_f_PEH:
case a_f_TEH_MARBUTA:
case a_f_TEH:
case a_f_THEH:
case a_f_JEEM:
+   case a_f_TCHEH:
case a_f_HAH:
case a_f_KHAH:
case a_f_DAL:
case a_f_THAL:
case a_f_REH:
case a_f_ZAIN:
+   case a_f_JEH:
case a_f_SEEN:
case a_f_SHEEN:
case a_f_SAD:
@@ -181,6 +197,8 @@ A_is_f(cur_c)
case a_f_FEH:
case a_f_QAF:
case a_f_KAF:
+   case a_f_FKAF:
+   case a_f_GAF:
case a_f_LAM:
case a_f_MEEM:
case a_f_NOON:
@@ -188,6 +206,7 @@ A_is_f(cur_c)
case a_f_WAW:
case a_f_ALEF_MAKSURA:
case a_f_YEH:
+   case a_f_FYEH:
case a_f_LAM_ALEF_MADDA_ABOVE:
case a_f_LAM_ALEF_HAMZA_ABOVE:
case a_f_LAM_ALEF_HAMZA_BELOW:
@@ -245,6 +264,9 @@ chg_c_a2s(cur_c)
case a_ZAIN:
tempc = a_s_ZAIN;
break;
+   case a_JEH:
+   tempc = a_s_JEH;
+   break;
case a_TATWEEL: /* exceptions */
tempc = cur_c;
break;
@@ -257,6 +279,9 @@ chg_c_a2s(cur_c)
case a_BEH:
tempc = a_s_BEH;
break;
+   case a_PEH:
+   tempc = a_s_PEH;
+   break;
case a_TEH:
tempc = a_s_TEH;
break;
@@ -266,6 +291,9 @@ chg_c_a2s(cur_c)
case a_JEEM:
tempc = a_s_JEEM;
break;
+   case a_TCHEH:
+   tempc = a_s_TCHEH;
+   break;
case a_HAH:
tempc = a_s_HAH;
break;
@@ -305,6 +333,12 @@ chg_c_a2s(cur_c)
case a_KAF:
tempc = a_s_KAF;
break;
+   case a_FKAF:
+   tempc = a_s_FKAF;
+   break;
+   case a_GAF:
+   tempc = a_s_GAF;
+   break;
case a_LAM:
tempc = a_s_LAM;
break;
@@ -320,6 +354,9 @@ chg_c_a2s(cur_c)
case a_YEH:
tempc = a_s_YEH;
break;
+   case a_FYEH:
+   tempc = a_s_FYEH;
+   break;
default:
tempc = 0;
 }
@@ -375,6 +412,9 @@ chg_c_a2i(cur_c)
case a_ZAIN:/* exceptions */
tempc = a_s_ZAIN;
break;
+   case a_JEH: /* exceptions */
+   tempc = a_s_JEH;
+   break;
case a_TATWEEL: /* exceptions */
tempc = cur_c;
break;
@@ -387,6 +427,9 @@ chg_c_a2i(cur_c)
case a_BEH:
tempc = a_i_BEH;
break;
+   case a_PEH:
+   tempc = a_i_PEH;
+