Hi,

I ran into a problem yesterday when an annotation in a doc comment was
not picked up by a comment handler. Long story short: It turned out
that I had typed  /* where I should have typed /** to open the
comment.

For Vim, this is all comment, so it wasn't immediately noticeable.

I would like to add a request for the php.syntax (and perhaps others
as well?) to:

*) Include a 'DocComment' type (opened with /** or perhaps /*!) so
that it could be colored differently, and/or

*) check for annotations in comments (annotations usually start with
an @, after a space, so ' @' would start an annotation) and highlight
them as warnings

I can provide examples if they are wanted/needed.

Thanks in advance for any insights or help!

Christ van Willegen
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

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

Hi

I see a minor bug in Vim-7.3.329 on Linux.
Command ":language fr_FR.UTF-8"  does not update the language
of the title in the terminal or title of gvim. Doing ":redraw!" does not
help either.  The language of the title gets updated after resizing the
terminal or gvim.

Steps to reproduce:

1) Start gvim with:
     $ (export LANG=en_US.UTF-8; gvim -u NONE -U NONE)

2) Observe that the window title is in English "[No Name] - GVIM1".

3) Enter Ex command    :language fr_FR.UTF-8

4) Observe that window title is still in English (bug!, I'd
    expect it to become in French).
    Doing ":redraw!"  does not work around.
    Observe that after resizing the window, title then
    becomes in French:  "[Aucun nom] - GVIM1"

Attached patch fixes it.

Regards
-- Dominique

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

Sergey,

On 1 October 2011 05:25, Sergey Khorev <sergey.khorev@...> wrote:
> Looks like the folks changed something in Racket... again. I will take a look.

I'm subscribed to their twitter feed (including changes/patches etc.).
They never stop changing things... ever. Bless 'em.

Can you recommend a working pair of vim/racket versions (from source)
to get me going in the meantime?


Thanks,

Tim

--
| Tim Brown <tim.brown@...> | M:+44(0)7771714159 | H:01372747875 |

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

> I'm subscribed to their twitter feed (including changes/patches etc.).
> They never stop changing things... ever. Bless 'em.

Yep, that's good for Racket but not so good for embedding
applications: API leaps unpredictably and I'm yet to see detailed
changelog for this kind of stuff.

> Can you recommend a working pair of vim/racket versions (from source)
> to get me going in the meantime?

MzScheme 4.x and Racket 5.0.1 should work for Vim 7.3.49+

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

On Fri, Sep 30, 2011 at 4:12 PM, Bram Moolenaar wrote:
> Xavier de Gaye wrote:
>> ...
>> When building an automated test case with netbeans, it is not obvious
>> how to have Vim made to call the idle loop. The attached patch adds a
>> call to netbeans_parse_messages() when the Vim ":sleep" command is
>> run. This allows for a more deterministic way of writing the test
>> cases (instead of inserting ":sleep" commands randomly until it works,
>> on this hardware).
>
> OK, this makes sense.  So you would run a Vim script that calls sleep in
> an endless loop?


Yes, this is right. It is a bit complicated due to the fact that there
are three processes running asynchronously (Vim, pyclewn and gdb), so
it is better to give an example. A typical pyclewn test case checks
that the content of a ${test_out} file contains the expected Vim signs
list:

     * the test starts by running the sequence of Vim and pyclewn
       commands that triggers gdb and sets breakpoint signs in Vim
       buffers
     * the test ends with the following commands:

             :call Wait_eop()
             :redir! > ${test_out}
             :sign place
             :qa

     * the definition of Wait_eop() follows:

# wait for pyclewn to process all previous commands
WAIT_EOP = """
:let g:testrun_key = ${key}
:function Wait_eop()
:   let g:testrun_key += 1
:   exe "Cdumprepr " . ${eop_file} . " " . g:testrun_key
:   let l:start = localtime()
:   while 1
:       " allow vim to process netbeans events and messages
:       sleep 10m
:       if localtime() - l:start > 5
:           break
:       endif
:       if filereadable(${eop_file})
:           let l:lines = readfile(${eop_file})
:           if len(lines) && l:lines[0] == g:testrun_key
:               sleep ${time}m
:               break
:           endif
:       endif
:   endwhile
:endfunction
"""

The call to the pyclewn 'Cdumprepr' command in Wait_eop() causes
pyclewn to create the temporary file named ${eop_file} and to write in
this file the value of ${key}. Thus, Wait_eop() can break out of the
while loop when detecting that the ${eop_file} contains the ${key},
which means that gdb and pyclewn have completed all their tasks. Note
that Wait_eop() still needs to sleep ${time} milliseconds, just before
the 'break' statement, to make sure that netbeans in Vim has processed
all the netbeans messages and has completed its share of the tasks.


> Please add a note in the documentation about this.  And perhaps a hint
> in the netbeans interface about what you are doing, it would be useful
> to others.


See the attached patch updated with documentation. I have also added a
paragraph to the ":nbkey" command to explain that it can be used to
pass any text to the IDE.


--
Xavier

Les Chemins de Lokoti: http://lokoti.alwaysdata.net

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

>> Can you recommend a working pair of vim/racket versions (from source)
>> to get me going in the meantime?
>
> MzScheme 4.x and Racket 5.0.1 should work for Vim 7.3.49+

Actually 5.1.3 has worked for me out of the box (I installed it from
Racket PPA on Ubuntu).
The only change needed is below (looks like PPA creator decided to use
/usr/share to store collects):
diff -r fb6b43d55773 src/auto/configure
--- a/src/auto/configure Fri Sep 30 18:35:57 2011 +0200
+++ b/src/auto/configure Sat Oct 01 17:25:02 2011 +0300
@@ -4935,6 +4935,10 @@
      else
        if test -d $vi_cv_path_mzscheme_pfx/lib/racket/collects; then
 	 SCHEME_COLLECTS=lib/racket/
+      else
+        if test -d $vi_cv_path_mzscheme_pfx/share/racket/collects; then
+   SCHEME_COLLECTS=share/racket/
+        fi
        fi
      fi
      if test -f
"${vi_cv_path_mzscheme_pfx}/${SCHEME_COLLECTS}collects/scheme/base.ss"
; then


--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?

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

Ben Fritz wrote:

> Using this XML snippet:
>
> <?xml version="1.0"?>
> <root_tag>
>   <SomeTag>
>      <SomeTagPlusText>content</SomeTagPlusText>
>   </SomeTag>
>   <another_tag></another_tag>
> </root_tag>
>
> I place my cursor on SomeTag and hit vit. It acts like I placed my
> cursor on root_tag. Same with vat. In other words, vat selects the
> entire <root_tag>...</root_tag> text, whereas I expect it to highlight
> only <SomeTag>...</SomeTag>
>
> If I make a minor change to the XML:
>
> <?xml version="1.0"?>
> <root_tag>
>   <SomeTag>
>      <SomeOtherTag>content</SomeOtherTag>
>   </SomeTag>
>   <another_tag></another_tag>
> </root_tag>
>
> Then everything works as I expect. Pressing vat on SomeTag will
> highlight only from <SomeTag> to </SomeTag>.
>
> It does not seem to depend on the length of the tag. This also does
> not work:
>
> <?xml version="1.0"?>
> <root_tag>
>   <T>
>      <T2>content</T2>
>   </T>
>   <another_tag></another_tag>
> </root_tag>
>
> Visual mode is not needed, it also acts on the wrong area when using
> dat for example (which is what I tried first, got confused, pressed u,
> tried again, got frustrated, used V%d instead).
>
> This is with gvim -N -u NONE -i NONE on 64-bit Windows XP.

Right, it appears there is no proper check for the end of the tag name.

--
hundred-and-one symptoms of being an internet addict:
37. You start looking for hot HTML addresses in public restrooms.

  /// Bram Moolenaar -- Bram@... -- 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

Hello list,

I'm running vim in a tmux session in xterm, I find that, when I quit
Xorg and start it again, then restore tmux session in a xterm, the
running vim will get mess, the keybindings and functions of the plugins
will get lost, I have to restart vim to make it back into normal
condition.

What's wrong?

--
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University(¤¤°êÃĬì¤j¾Ç)
No.24, Tongjia Xiang Street, Nanjing 210009, China

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

2011/10/2 Yue Wu <vanopen@...>:
> Hello list,
>
> I'm running vim in a tmux session in xterm, I find that, when I quit
> Xorg and start it again, then restore tmux session in a xterm, the
> running vim will get mess, the keybindings and functions of the plugins
> will get lost, I have to restart vim to make it back into normal
> condition.
>
> What's wrong?

When X connection lost, Vim uses longjmp() (Jump from
os_unix.c:x_IOerror_handler() to main.c:999).
While processing vgetorpeek(), it may occur.
And when it occur, vgetc_busy global variable is not reset (Normally it
is reset at end of vgetorpeek()).
Then after longjmp(), mappings are never applied because vgetc_busy > 0
is always true.
I think there is other situation that longjmp() breaks something.


main.c:
994 #if defined(FEAT_X11) && defined(FEAT_XCLIPBOARD)
995     /* Setup to catch a terminating error from the X server.  Just ignore
996      * it, restore the state and continue.  This might not always work
997      * properly, but at least we don't exit unexpectedly when the X server
998      * exists while Vim is running in a console. */
999     if (!cmdwin && !noexmode && SETJMP(x_jump_env))
1000     {
1001         State = NORMAL;
1002 # ifdef FEAT_VISUAL
1003         VIsual_active = FALSE;
1004 # endif
1005         got_int = TRUE;
1006         need_wait_return = FALSE;
1007         global_busy = FALSE;


ad-hoc fix.

diff -r 15b934a16641 src/main.c
--- a/src/main.c    Wed Sep 14 19:04:40 2011 +0200
+++ b/src/main.c    Sun Sep 25 18:50:43 2011 +0900
@@ -1009,6 +1009,7 @@
     skip_redraw = FALSE;
     RedrawingDisabled = 0;
     no_wait_return = 0;
+   vgetc_busy = 0;
  # ifdef FEAT_EVAL
     emsg_skip = 0;
  # endif


--
Yukihiro Nakadaira - yukihiro.nakadaira@...

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

My gvim (7.3.329) is compiled with +float.
My environment contains
    $LANG=en_US.UTF-8
    $LANGUAGE=
    $LC_PAPER=en_GB
    $LC_TIME=en_GB
    no other $LC_something
My vimrc sets
    language messages C
    language time en_GB
But contrary to what is said in the help (currently at line 78 of
mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
the output of :lang with no arguments) is not set at C, it remains at
en_US.UTF-8 (implicitly from $LANG I suppose).

In this case it doesn't matter since the decimal point for en_US is the
period. But I wonder what would have happened in a French locale (where
the "decimal-point is comma" convention is /de rigueur/).


Best regards,
Tony.
--
You can take all the impact that science considerations have on funding
decisions at NASA, put them in the navel of a flea, and have room left
over for a caraway seed and Tony Calio's heart.
		 -- F. Allen

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

Thilo Six wrote the following on 30.09.2011 20:34

-- <snip> --

Hello David,

This is a follow up on my last mail.
Attached are updated versions to make them compatible with OpenSSH 5.9.

And i don't know if you are aware of the fact that Leonard is willing to become
the official maintainer of them (cc'ed him) but obviously only if you are fine
with that. What are plans?

Regards,
--
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F

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

Hi list.

Vimscript does not have the easy way to get current script ID.
so :help <SID> recommends that add s:SID() and use it.
but it is a little bit hacky thing.

so I want to add new vimscript function getsid().
Attached patch added the function and its help.
Could you include this patch?

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

Zvezdan,

Thanks for your time to make your elaborate reply. This makes a
valuable set of code for regression testing.

1.During the work this item was bothering me as well. My preference
goes to option
(a), so that's what I'll do.

2. :) I like this one.  A continued statement, type 1, inside what the
indenter
considers a continued statement, type 2. I scanned my remaining awk
code, it
is not much, and I was surprised to see I never do this, while in C++
I break if's
all the time.

3. This is caused by new code to catch if statements that complete in
a single line. Easy fix.

4. Well... what a disappointment. It is supposed to support } else
{ and ignore comments now.

5. My quick judgement is it is (are) another occurence(s) of issue 2.
(so what you say)


Coming week is a busy one for me, so i'll look into it after that.
(but my plan is not to wait 6 years before the next reply like last
time :))

Erik.


On 1 okt, 06:03, Zvezdan Petkovic <zpetko...@...> wrote:
> On Sep 30, 2011, at 8:45 AM, erik wrote:
>
> > I think I have this issue is fixed, as well as every other pending
> > complaint.
>
> Not all issues yet. :-)
>

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

Yasuhiro Matsumoto wrote:

> > I am unable to reproduce the problem.  What settings would be needed?
> > Is this in a terminal or in gvim?
>
> I can reproduce it on vim.exe.

So that is on a Windows console window.  Did you build Vim yourself?
With what compiler?

--
On the other hand, you have different fingers.
                                       -- Steven Wright

  /// Bram Moolenaar -- Bram@... -- 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

Tony Mechelynck wrote:

> My gvim (7.3.329) is compiled with +float.
> My environment contains
>    $LANG=en_US.UTF-8
>    $LANGUAGE=
>    $LC_PAPER=en_GB
>    $LC_TIME=en_GB
>    no other $LC_something
> My vimrc sets
>    language messages C
>    language time en_GB
> But contrary to what is said in the help (currently at line 78 of
> mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
> the output of :lang with no arguments) is not set at C, it remains at
> en_US.UTF-8 (implicitly from $LANG I suppose).
>
> In this case it doesn't matter since the decimal point for en_US is the
> period. But I wonder what would have happened in a French locale (where
> the "decimal-point is comma" convention is /de rigueur/).

Vim does explicitly set LC_NUMERIC to "C".  And that's what happens for
me.  I can't guess why it's different for you.

--
Everyone has a photographic memory. Some don't have film.

  /// Bram Moolenaar -- Bram@... -- 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

Dominique Pelle wrote:

> I see a minor bug in Vim-7.3.329 on Linux.
> Command ":language fr_FR.UTF-8"  does not update the language
> of the title in the terminal or title of gvim. Doing ":redraw!" does not
> help either.  The language of the title gets updated after resizing the
> terminal or gvim.
>
> Steps to reproduce:
>
> 1) Start gvim with:
>     $ (export LANG=en_US.UTF-8; gvim -u NONE -U NONE)
>
> 2) Observe that the window title is in English "[No Name] - GVIM1".
>
> 3) Enter Ex command    :language fr_FR.UTF-8
>
> 4) Observe that window title is still in English (bug!, I'd
>    expect it to become in French).
>    Doing ":redraw!"  does not work around.
>    Observe that after resizing the window, title then
>    becomes in French:  "[Aucun nom] - GVIM1"
>
> Attached patch fixes it.

Thanks.  I'll put it on the todo list.

--
A day without sunshine is like, well, night.

  /// Bram Moolenaar -- Bram@... -- 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

Yukihiro Nakadaira wrote:

> 2011/10/2 Yue Wu <vanopen@...>:
> > Hello list,
> >
> > I'm running vim in a tmux session in xterm, I find that, when I quit
> > Xorg and start it again, then restore tmux session in a xterm, the
> > running vim will get mess, the keybindings and functions of the plugins
> > will get lost, I have to restart vim to make it back into normal
> > condition.
> >
> > What's wrong?
>
> When X connection lost, Vim uses longjmp() (Jump from
> os_unix.c:x_IOerror_handler() to main.c:999).
> While processing vgetorpeek(), it may occur.
> And when it occur, vgetc_busy global variable is not reset (Normally it
> is reset at end of vgetorpeek()).
> Then after longjmp(), mappings are never applied because vgetc_busy > 0
> is always true.
> I think there is other situation that longjmp() breaks something.
>
>
> main.c:
> 994 #if defined(FEAT_X11) && defined(FEAT_XCLIPBOARD)
> 995     /* Setup to catch a terminating error from the X server.  Just ignore
> 996      * it, restore the state and continue.  This might not always work
> 997      * properly, but at least we don't exit unexpectedly when the X server
> 998      * exists while Vim is running in a console. */
> 999     if (!cmdwin && !noexmode && SETJMP(x_jump_env))
> 1000     {
> 1001         State = NORMAL;
> 1002 # ifdef FEAT_VISUAL
> 1003         VIsual_active = FALSE;
> 1004 # endif
> 1005         got_int = TRUE;
> 1006         need_wait_return = FALSE;
> 1007         global_busy = FALSE;
>
>
> ad-hoc fix.

Thanks.  I'll put it on the todo list.


--
Change is inevitable, except from a vending machine.

  /// Bram Moolenaar -- Bram@... -- 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

On 02/10/11 22:25, Bram Moolenaar wrote:
>
> Tony Mechelynck wrote:
>
>> My gvim (7.3.329) is compiled with +float.
>> My environment contains
>>     $LANG=en_US.UTF-8
>>     $LANGUAGE=
>>     $LC_PAPER=en_GB
>>     $LC_TIME=en_GB
>>     no other $LC_something
>> My vimrc sets
>>     language messages C
>>     language time en_GB
>> But contrary to what is said in the help (currently at line 78 of
>> mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
>> the output of :lang with no arguments) is not set at C, it remains at
>> en_US.UTF-8 (implicitly from $LANG I suppose).
>>
>> In this case it doesn't matter since the decimal point for en_US is the
>> period. But I wonder what would have happened in a French locale (where
>> the "decimal-point is comma" convention is /de rigueur/).
>
> Vim does explicitly set LC_NUMERIC to "C".  And that's what happens for
> me.  I can't guess why it's different for you.
>

Neither can I; but adding a few :echomsg commands shows the following:

- $LC_NUMERIC is "C" on entry to the vimrc
- it is still "C" while sourcing the last global after-plugin
- it has become empty (and is listed as "en_US.UTF-8" in the output of
:lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
- it remains set to "C" if I run the same Vim executable in console mode.

I suspect the line marked below with <----- at line 1467 of main.c but I
don't know GTK well enough to be sure. Do you think it would be worth
swapping the two ifdef blocks to see if it changes anything? (Not this
second, I'm going to bed.)

/*
   * Setup to use the current locale (for ctype() and many other things).
   */
      static void
init_locale()
{
      setlocale(LC_ALL, "");

# ifdef FEAT_GUI_GTK
      /* Tell Gtk not to change our locale settings. */
      gtk_disable_setlocale();         <----- this line
# endif
# if defined(FEAT_FLOAT) && defined(LC_NUMERIC)
      /* Make sure strtod() uses a decimal point, not a comma. */
      setlocale(LC_NUMERIC, "C");
# endif


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
192. Your boss asks you to "go fer" coffee and you come up with 235 FTP
sites.

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

Tony Mechelynck wrote the following on 03.10.2011 06:03

-- <snip> --

>>>     $LANGUAGE=

-- <snip> --

> - it has become empty (and is listed as "en_US.UTF-8" in the output of
> :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
> - it remains set to "C" if I run the same Vim executable in console mode.

-- <snip> --

> Best regards,
> Tony.

I suspect without explictly testing it those two are related. If you don´t want
'$LANGUAGE' one has to use 'unset LANGUAGE' (there may differences about the
specific syntax to use depending on the shell you use). But setting it to an
empty value isn´t the same.

Regards,
--
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F


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

Sergey,

could you confirm to me that:

vim +':mz #f'

works with racket-5.1.3

It still cores on me. As does racket-5.0.1



On 1 October 2011 15:29, Sergey Khorev <sergey.khorev@...> wrote:
>>> Can you recommend a working pair of vim/racket versions (from source)
>>> to get me going in the meantime?
>>
>> MzScheme 4.x and Racket 5.0.1 should work for Vim 7.3.49+
>
> Actually 5.1.3 has worked for me out of the box (I installed it from
> Racket PPA on Ubuntu).
> The only change needed is below (looks like PPA creator decided to use
> /usr/share to store collects):
> diff -r fb6b43d55773 src/auto/configure
> --- a/src/auto/configure        Fri Sep 30 18:35:57 2011 +0200
> +++ b/src/auto/configure        Sat Oct 01 17:25:02 2011 +0300
> @@ -4935,6 +4935,10 @@
>     else
>       if test -d $vi_cv_path_mzscheme_pfx/lib/racket/collects; then
>        SCHEME_COLLECTS=lib/racket/
> +      else
> +        if test -d $vi_cv_path_mzscheme_pfx/share/racket/collects; then
> +         SCHEME_COLLECTS=share/racket/
> +        fi
>       fi
>     fi
>     if test -f
> "${vi_cv_path_mzscheme_pfx}/${SCHEME_COLLECTS}collects/scheme/base.ss"
> ; then
>
>
> --
> Sergey Khorev
> http://sites.google.com/site/khorser
> Can anybody think of a good tagline I can steal?
>
> --
> 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
>



--
| Tim Brown <tim.brown@...> | M:+44(0)7771714159 | H:01372747875 |
|----------------------------------------------------------------|
| vim: syntax=mail textwidth=65 ai nocindent

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

On 03/10/11 06:03, Tony Mechelynck wrote:
[...]
> - $LC_NUMERIC is "C" on entry to the vimrc
> - it is still "C" while sourcing the last global after-plugin
> - it has become empty (and is listed as "en_US.UTF-8" in the output of
> :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
> - it remains set to "C" if I run the same Vim executable in console mode.
>
> I suspect the line marked below with <----- at line 1467 of main.c but I
> don't know GTK well enough to be sure. Do you think it would be worth
> swapping the two ifdef blocks to see if it changes anything? (Not this
> second, I'm going to bed.)

After swapping them, $LC_NUMERIC is still reset at GUIEnter

>
> /*
> * Setup to use the current locale (for ctype() and many other things).
> */
> static void
> init_locale()
> {
> setlocale(LC_ALL, "");
>
> # ifdef FEAT_GUI_GTK
> /* Tell Gtk not to change our locale settings. */
> gtk_disable_setlocale(); <----- this line
> # endif
> # if defined(FEAT_FLOAT) && defined(LC_NUMERIC)
> /* Make sure strtod() uses a decimal point, not a comma. */
> setlocale(LC_NUMERIC, "C");
> # endif
>
>
> Best regards,
> Tony.
--
The first myth of management is that it exists.  The second myth of
management is that success equals skill.
		 -- Robert Heller

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

On 03/10/11 10:58, Thilo Six wrote:
> Tony Mechelynck wrote the following on 03.10.2011 06:03
>
> -- <snip>  --
>
>>>>      $LANGUAGE=
>
> -- <snip>  --
>
>> - it has become empty (and is listed as "en_US.UTF-8" in the output of
>> :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
>> - it remains set to "C" if I run the same Vim executable in console mode.
>
> -- <snip>  --
>
>> Best regards,
>> Tony.
>
> I suspect without explictly testing it those two are related. If you don´t
want
> '$LANGUAGE' one has to use 'unset LANGUAGE' (there may differences about the
> specific syntax to use depending on the shell you use). But setting it to an
> empty value isn´t the same.
>
> Regards,

I use bash; but the problem is not how to change my shell startup
scripts, it's how to change Vim to make sure $LC_NUMERIC remains set at
C after GUI startup for the full duration of the gvim process,
regardless of what might have been in the outside environment outside of
Vim.

AFAICT, $LANGUAGE and $LC_ALL being set at the empty string has the same
effect as them not being defined; in particular, after requesting the
environment values of the locale settings, Vim sees them as they are set
(most of them "en_US.UTF-8" from $LANG; $LC_TIME and $LC_PAPER "en_GB"
for DD/MM/YY date and A4 paper), not everything empty. In C,
setlocale(LC_ALL, "") explicitly means "set the locale settings from the
environment, don't keep them all at 'C' which is mandated at program
startup by the C standard", cf. the info page for setlocale.

And BTW the problem happens only in the GUI; as I already mentioned, the
same Vim executable keeps $LC_NUMERIC == 'C' when run in console mode.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
193. You ask your girlfriend to drive home so you can sit back with
       your PDA and download the information to your laptop

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

Tony Mechelynck wrote the following on 03.10.2011 16:33

-- <snip> --

> AFAICT, $LANGUAGE
-- <snip> --
> being set at the empty string has the same
> effect as them not being defined
-- <snip> --

afaict it is not. ymmv. Once on a manual page i read that '$LANGUAGE' takes
precedence over '$LANG' being set. Thats especially true for gui programs.
Sad bad true i can't find that particular manpage again right at hand.
But since you are the one who reported the problem it should be easy for you to
verify that my claims at your case are true or not.

> Best regards,
> Tony.

Regards,

--
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F


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

> could you confirm to me that:
>
> vim +':mz #f'
>
> works with racket-5.1.3
>
> It still cores on me. As does racket-5.0.1

Ah, got you!
:mz from command line does not and will not work with any versions
newer than 3.x. Once Vim has initialised everything should work as
expected.
In principle someone adventurous might refactor Vim startup code to fix this...

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

Am 03.10.2011 18:37, schrieb Thilo Six:
> Tony Mechelynck wrote the following on 03.10.2011 16:33
>
> -- <snip> --
>
>> AFAICT, $LANGUAGE
> -- <snip> --
>> being set at the empty string has the same
>> effect as them not being defined
> -- <snip> --
>
> afaict it is not. ymmv. Once on a manual page i read that '$LANGUAGE' takes
> precedence over '$LANG' being set. Thats especially true for gui programs.
> Sad bad true i can't find that particular manpage again right at hand.
> [...]

It's documented as an info document. Try:

info gettext 'Locale Environment Variables'
info gettext 'The LANGUAGE variable'


HTH,
Dennis Benzinger

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

It prefer to return zero for invalid cases.

let sid getsid()
if sid
   " using sid
endif

On Sun, Oct 2, 2011 at 1:52 PM, tyru <tyru.exe@...> wrote:
> Hi list.
>
> Vimscript does not have the easy way to get current script ID.
> so :help <SID> recommends that add s:SID() and use it.
> but it is a little bit hacky thing.
>
> so I want to add new vimscript function getsid().
> Attached patch added the function and its help.
> Could you include this patch?
>
> --
> 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
>



--
- Yasuhiro Matsumoto

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

Thanks for the review.
I updated the patch.

On Tue, Oct 4, 2011 at 4:19 AM, Yasuhiro MATSUMOTO <mattn.jp@...> wrote:
> It prefer to return zero for invalid cases.
>
> let sid getsid()
> if sid
>  " using sid
> endif
>
> On Sun, Oct 2, 2011 at 1:52 PM, tyru <tyru.exe@...> wrote:
>> Hi list.
>>
>> Vimscript does not have the easy way to get current script ID.
>> so :help <SID> recommends that add s:SID() and use it.
>> but it is a little bit hacky thing.
>>
>> so I want to add new vimscript function getsid().
>> Attached patch added the function and its help.
>> Could you include this patch?
>>
>> --
>> 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
>>
>
>
>
> --
> - Yasuhiro Matsumoto
>
> --
> 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
>

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

Yasuhiro Matsumoto wrote:

> hg pull && hg update.
> But src/xxd/Make_mingw.mak not found.
>
> Probably, you forgot hg add src/xxd/Make_mingw.mak?

Right.  Done that now.

--
Portable Computer:  A device invented to force businessmen
to work at home, on vacation, and on business trips.

  /// Bram Moolenaar -- Bram@... -- 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