Re: HOME variable in cmd.exe for vim compiled in an UNIX-like environment

Am 31.05.2011 11:16, schrieb Gary Johnson:
> Under what conditions does yours crash?

Plain vim.exe from MSYS executed in a cmd.exe shell.

I have seen something similar to your observations: If I unset HOME in 
cmd.exe (via "set HOME=") and then run vim.exe from MSYS, it crashes. 
If I first run bash and then start vim.exe from bash, it works, even 
if bash also has its HOME variable unset. Strange...

However, currently the init_homedir function in misc1.c does not 
consider the case when both UNIX is defined at build time (#ifdef 
UNIX) but (var == NULL) at run time, which is perfectly possible when 
vim is compiled in an MSYS environment (which has __unix defined) but 
executed from a cmd.exe shell without a HOME variable.

The attached short patch is very pragmatic but at least provides a 
fallback solution when the aforementioned case occures, else the 
init_homedir function may return and the homedir variable is still NULL.

Cheers,
  - Fabian

  --

--- misc1.c.orig
+++ misc1.c
 <at>  <at>  -3540,6 +3540,8  <at>  <at> 
  	}
  #endif

Re: vim 7.3: A few problems with patches

On 01/06/11 19:40, sc wrote:
> On Monday, May 30, 2011 03:35:34 you wrote:
>
>> On 30/05/11 02:16, sc wrote:
>>> On Saturday, May 28, 2011 22:03:43 Birger J. Nordølum wrote:
>>>> Ontopic: I were unable to apply the patches from the FTP
>>>> server. It stopped  at 202.
>>>
>>> the the :version after you build with what you got, or maybe
>>> peek in src/version.c
>>>
>>> patch 202 was the last one to get tagged in hg, but 206 was
>>> the last actual one in there
>>>
>>> sc
>
>> changeset 46544d3ae7ec dated Wed May 25 21:18:06 2011 +0200 by
>> Bram Moolenaar<bram <at> vim.org>  has the tag v7-3-206, added by
>> the next changeset (e9538cfd0d9c).
>
> i have neither of those changeset ids in any of my logs, and
> no such tag in hg -- yet my hg insists there are "no changes
> found" -- and what i build reports a version of 7.3.206
>
> curious
>
> sc
>

What do you see if you try making a new clone (besides your existing 

Re: added TextDeleted and TextYanked events

So, Bram is that ok? Do you want the patch on another medium? Are
there issues I didn't address?

Thanks,
Philippe

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: vim 7.3: A few problems with patches

Re: added TextDeleted and TextYanked events

Philippe Vaucher wrote:

> So, Bram is that ok? Do you want the patch on another medium? Are
> there issues I didn't address?

I need to have a closer look.  Bugs usually have a higher priority than
new features.

-- 
hundred-and-one symptoms of being an internet addict:
131. You challenge authority and society by portnuking people

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: HOME variable in cmd.exe for vim compiled in an UNIX-like environment

Fabian Greffrath wrote:

> Am 31.05.2011 11:16, schrieb Gary Johnson:
> > Under what conditions does yours crash?
> 
> Plain vim.exe from MSYS executed in a cmd.exe shell.
> 
> I have seen something similar to your observations: If I unset HOME in 
> cmd.exe (via "set HOME=") and then run vim.exe from MSYS, it crashes. 
> If I first run bash and then start vim.exe from bash, it works, even 
> if bash also has its HOME variable unset. Strange...
> 
> However, currently the init_homedir function in misc1.c does not 
> consider the case when both UNIX is defined at build time (#ifdef 
> UNIX) but (var == NULL) at run time, which is perfectly possible when 
> vim is compiled in an MSYS environment (which has __unix defined) but 
> executed from a cmd.exe shell without a HOME variable.
> 
> The attached short patch is very pragmatic but at least provides a 
> fallback solution when the aforementioned case occures, else the 
> init_homedir function may return and the homedir variable is still NULL.

It's perfectly OK for homedir to be NULL.  Setting it to any random
directory is not a good idea.

Where does Vim crash when homedir is NULL?  That should be fixed.

-- 
All true wisdom is found on T-shirts.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

matchit does not wrap the search for ifndef in Verilog/systemverilog mode

Hi
I have following code in verilog/system verilog

when i use "%"  key for ifndef else endif keyword it doesn't wrap
after reaching endif,
where as for all other keywords it wraps back to start.

module my_mod
`ifdef foo
`else
`endif

`ifndef bar
`else
`endif

    class
    endclass

    begin
    end

    case
    endcase

    casex
    endcase

    casez
    endcase

    module
    endmodule

    if
    else

    fork
    join

    function
    endfunction

    task
    endtask

    specify
    endspecify

endmodule

Please suggest the solution.

Regards

Amol N

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

[?] echoe acts like an exception inside :catch and :finally blocks

Is this expected:
    try
        throw 'Throw'
    catch
        echoe 'Echoe'
        echom 'Echom'
    endtry
will show only 'Echoe', but not 'Echom'? I though that «When used inside a try 
conditional» refers only to the first section of `:try...' block, not to 
`:catch' or `:finally' sections.

Re: vim 7.3: A few problems with patches

On Wednesday, June 01, 2011 13:07:02 Tony Mechelynck wrote:

> Or, are your logs up-to-date? If (after cd to your Vim
> repository) you do

>        hg -v log -l 10

> these changesets (if you have them) should appear near the top
> of the list.

indeed they do -- i see many updates that way that don't
appear in my update log

i guess my update (pull) needs a verbosity option

thanx

sc

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: [?] echoe acts like an exception inside :catch and :finally blocks

ZyX wrote:

> Is this expected:
>     try
>         throw 'Throw'
>     catch
>         echoe 'Echoe'
>         echom 'Echom'
>     endtry
> will show only 'Echoe', but not 'Echom'? I though that «When used
> inside a try conditional» refers only to the first section of
> `:try...' block, not to `:catch' or `:finally' sections.

This indeed looks wrong.

-- 
Don't drink and drive.  You might hit a bump and spill your beer.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php