> 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

Tim Brown

Sergey, Thanks for your help so far. ... Unfortunately, this is just a test case, and the + :mz #f on the command line isn t actually what I want to do. I m

Message 2 of 29
, Oct 4, 2011

0 Attachment

Sergey,

Thanks for your help so far.

On 3 October 2011 17:39, Sergey Khorev <sergey.khorev@...> wrote:
>> 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.

Unfortunately, this is just a test case, and the +":mz #f" on the
command line isn't actually what I want to do. I'm trying to put
together a "syntax" which adds all of the racket keywords (which IMO,
only racket would know) as :syntax... keywords.

Unfortunately, it is not the case that "Vim has initialised
everything" as I am loading my first racket file which then tries to
:source/:runtime the vim script via an :autocmd

In fact, I have to wait until the file is loaded and displayed to me.
*Then* (and this is the bit I deeply resent) I have to souce the file
myself! (OK, so it's mapped to a key, but there's a principle here).

So I have two questions for you:
* What is wrong with the way vim starts up that it is not ready to
invoke :mzscheme on a command line, vim -u, syntax load or :autocmd?
* When, technically has "Vim ... initialised everything"?

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

Bram Moolenaar

... The way mzscheme_main() is called, which then invokes main_loop(), is indeed odd. I suppose this would require moving most of main() into a separate

Message 3 of 29
, Oct 4, 2011

0 Attachment

Sergey Khorev wrote:

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

The way mzscheme_main() is called, which then invokes main_loop(), is
indeed odd. I suppose this would require moving most of main() into a
separate function.

--
Despite the cost of living, have you noticed how it remains so popular?

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

I see your point. Basically, if you application embeds MzScheme v.4+ you need to use trampolined startup: all the Scheme activity should run inside a function

Message 4 of 29
, Oct 4, 2011

0 Attachment

I see your point.

Basically, if you application embeds MzScheme v.4+ you need to use trampolined startup: all the Scheme activity should run inside a function called from scheme_main_setup. Speaking of Vim it looks like:
1) At the end of VimMain in main.c we do mzscheme_main()
2) mzscheme_main in if_mzsch.c invokes scheme_main_setup(TRUE, mzscheme_env_main, 0, NULL)
3) mzscheme_env_main does some basic initialisations and passes control back to Vim calling its main_loop().

I think we can call mzscheme_main earlier, before Vim starts processing command line or scripts. We can wrap the remaining part of VimMain into a function and call it from mzscheme_env_main (reminds me continuation-passing style :)I cannot recall why I did not implement it like that.

On Oct 4, 2011 12:44 PM, "Tim Brown" <tim.brown@...> wrote:
>
> Sergey,
>
> Thanks for your help so far.
>
> On 3 October 2011 17:39, Sergey Khorev <sergey.khorev@...> wrote:
> >> 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.
>
> Unfortunately, this is just a test case, and the +":mz #f" on the
> command line isn't actually what I want to do. I'm trying to put
> together a "syntax" which adds all of the racket keywords (which IMO,
> only racket would know) as :syntax... keywords.
>
> (In fact: http://www.vim.org/scripts/script.php?script_id=3757)
>
> Unfortunately, it is not the case that "Vim has initialised
> everything" as I am loading my first racket file which then tries to
> :source/:runtime the vim script via an :autocmd
>
> In fact, I have to wait until the file is loaded and displayed to me.
> *Then* (and this is the bit I deeply resent) I have to souce the file
> myself! (OK, so it's mapped to a key, but there's a principle here).
>
> So I have two questions for you:
> * What is wrong with the way vim starts up that it is not ready to
> invoke :mzscheme on a command line, vim -u, syntax load or :autocmd?
> * When, technically has "Vim ... initialised everything"?
>
> > In principle someone adventurous might refactor Vim startup code to fix this...
>
> How adventurous?
> How much of this is at the vim end?
> How much of this is at the if_mzscheme/racket end?
>
> 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

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

I ve had a quick hack (and not sure how to get a proper patch set up... but), the trampoline should be able to happen as the first thing vim does. It seems to

Message 5 of 29
, Oct 4, 2011

0 Attachment

I've had a quick hack (and not sure how to get a proper patch set
up... but), the trampoline should be able to happen as the first thing
vim does.

It seems to work (although I've not tried any "windowing" commands yet)

/* Call the main command loop. This never returns.
* For embedded MzScheme the main_loop will be called by Scheme
* for proper stack tracking
*/
main_loop(FALSE, FALSE);

(removing references to FEAT_SCHEME)

Tim

On 4 October 2011 14:56, Sergey Khorev <sergey.khorev@...> wrote:
> I see your point.
>
> Basically, if you application embeds MzScheme v.4+ you need to use
> trampolined startup: all the Scheme activity should run inside a function
> called from scheme_main_setup. Speaking of Vim it looks like:
> 1) At the end of VimMain in main.c we do mzscheme_main()
> 2) mzscheme_main in if_mzsch.c invokes scheme_main_setup(TRUE,
> mzscheme_env_main, 0, NULL)
> 3) mzscheme_env_main does some basic initialisations and passes control back
> to Vim calling its main_loop().
>
> I think we can call mzscheme_main earlier, before Vim starts processing
> command line or scripts. We can wrap the remaining part of VimMain into a
> function and call it from mzscheme_env_main (reminds me continuation-passing
> style :)
> I cannot recall why I did not implement it like that.
>
> On Oct 4, 2011 12:44 PM, "Tim Brown" <tim.brown@...> wrote:
>>
>> Sergey,
>>
>> Thanks for your help so far.
>>
>> On 3 October 2011 17:39, Sergey Khorev <sergey.khorev@...> wrote:
>> >> 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.
>>
>> Unfortunately, this is just a test case, and the +":mz #f" on the
>> command line isn't actually what I want to do. I'm trying to put
>> together a "syntax" which adds all of the racket keywords (which IMO,
>> only racket would know) as :syntax... keywords.
>>
>> (In fact: http://www.vim.org/scripts/script.php?script_id=3757)
>>
>> Unfortunately, it is not the case that "Vim has initialised
>> everything" as I am loading my first racket file which then tries to
>> :source/:runtime the vim script via an :autocmd
>>
>> In fact, I have to wait until the file is loaded and displayed to me.
>> *Then* (and this is the bit I deeply resent) I have to souce the file
>> myself! (OK, so it's mapped to a key, but there's a principle here).
>>
>> So I have two questions for you:
>> * What is wrong with the way vim starts up that it is not ready to
>> invoke :mzscheme on a command line, vim -u, syntax load or :autocmd?
>> * When, technically has "Vim ... initialised everything"?
>>
>> > In principle someone adventurous might refactor Vim startup code to fix
>> > this...
>>
>> How adventurous?
>> How much of this is at the vim end?
>> How much of this is at the if_mzscheme/racket end?
>>
>> 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
>
> --
> 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 4 October 2011 15:04, Tim Brown <tim.brown@...> wrote:
> I've had a quick hack (and not sure how to get a proper patch set
> up... but), the trampoline should be able to happen as the first thing
> vim does.

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

... Sorry, I cannot see why fname should be static, maybe because the patch is incomplete? Can you do diff -cr to compare all the files, also it will make it

Message 9 of 29
, Oct 4, 2011

0 Attachment

> Improving stability -- the trampoline has to be split so that a
> certain degree of initialisation can occur.
>
> This has necessitated (in this iteration) that:
> static char_u *fname = NULL;
> static mparm_T params;
> static int i;
>
> Are all statics (is this OK -- or is there a better way of doing this?).

Sorry, I cannot see why fname should be static, maybe because the
patch is incomplete? Can you do "diff -cr" to compare all the files,
also it will make it simpler to apply the patch. If you use Mercurial
"hg diff" should do it as well.
Anyway this looks quite promising.

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

I ve been testing my cobbled together patch for an afternoon now. Seems to work. I am working on a proper patch via Mercurial. Is main() in main.c the only

Message 10 of 29
, Oct 5, 2011

0 Attachment

I've been testing my cobbled together patch for an afternoon now. Seems to work.

I am working on a proper patch via Mercurial.

Is main() in main.c the only place where vim "starts"?
Better put: no matter how vim is started, no matter what OS/Framework,
will it go through main.c:main()?

Tim

On 4 October 2011 18:34, Sergey Khorev <sergey.khorev@...> wrote:
>> Improving stability -- the trampoline has to be split so that a
>> certain degree of initialisation can occur.
>>
>> This has necessitated (in this iteration) that:
>> static char_u *fname = NULL;
>> static mparm_T params;
>> static int i;
>>
>> Are all statics (is this OK -- or is there a better way of doing this?).
>
> Sorry, I cannot see why fname should be static, maybe because the
> patch is incomplete? Can you do "diff -cr" to compare all the files,
> also it will make it simpler to apply the patch. If you use Mercurial
> "hg diff" should do it as well.
> Anyway this looks quite promising.

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

... initialised, e.g. in startup scripts and on the command line. Therefore the following would SEGV: vim + :mz 1 ... works when editing a file. mzscheme

Message 11 of 29
, Oct 5, 2011

0 Attachment

Please find attached a patch for the following issue:

:mzscheme could be invoked before the mzscheme/racket libraries were
initialised, e.g. in startup scripts and on the command line.

Therefore the following would SEGV:
vim +':mz 1'

Even though:
:mz 1
works when editing a file.

mzscheme expects to be invoked by a "trampoline" that wraps around the
main() of the embedding environment -- and this trampoline is around
main_loop().

exe_pre_commands() and source_startup_scripts() are outside the scope
of the trampoline.

This patch causes main() to be called in two parts. The first part
sets up vim's environment and globals, but does not execute any vim
commands (as far as I can tell). It then calls to mzscheme_init, which
eventually recurs into main(); which skips the initialisation, and
proceeds with anything that may perform commands.

Notes:
* I pass fname and params between invocations of main() through the
static variables save_mz_fname and save_mz_params. There is
justification at the top of main() for doing so. I'm not so keen on
statics, myself -- so I've not re-declared fname and params
themselves.
* The other option would be to split main into two parts -- an
"initialisation" and a "commands" part. Then start up vim with:
main(argc, argv)
calls mzscheme_init(argc, argv, fname, params)
calls ... main_part2(argc, argv, fname, params)

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

Bram Moolenaar

... Thanks for the patch, I ll put it on the todo list. Is the configure change that was previously send also needed? -- Don t read everything you believe. ///

Message 13 of 29
, Oct 5, 2011

0 Attachment

Tim Brown wrote:

> Please find attached a patch for the following issue:
>
> :mzscheme could be invoked before the mzscheme/racket libraries were
> initialised, e.g. in startup scripts and on the command line.
>
> Therefore the following would SEGV:
> vim +':mz 1'
>
> Even though:
> :mz 1
> works when editing a file.
>
> mzscheme expects to be invoked by a "trampoline" that wraps around the
> main() of the embedding environment -- and this trampoline is around
> main_loop().
>
> exe_pre_commands() and source_startup_scripts() are outside the scope
> of the trampoline.
>
> This patch causes main() to be called in two parts. The first part
> sets up vim's environment and globals, but does not execute any vim
> commands (as far as I can tell). It then calls to mzscheme_init, which
> eventually recurs into main(); which skips the initialisation, and
> proceeds with anything that may perform commands.
>
> Notes:
> * I pass fname and params between invocations of main() through the
> static variables save_mz_fname and save_mz_params. There is
> justification at the top of main() for doing so. I'm not so keen on
> statics, myself -- so I've not re-declared fname and params
> themselves.
> * The other option would be to split main into two parts -- an
> "initialisation" and a "commands" part. Then start up vim with:
> main(argc, argv)
> calls mzscheme_init(argc, argv, fname, params)
> calls ... main_part2(argc, argv, fname, params)
>
> [or, in the case of !FEAT_MZSCHEME: main(argc,argv) calls
> main_part2(argc, argv, fname, params)]
>
> I think I've done enough in main already! And, unless there is more
> general merit in such a refactoring, this is as much disruption as I
> need to cause :-)
>
> Thanks Sergey and Bram for your help!

> Please find attached a patch for the following issue:
>
> :mzscheme could be invoked before the mzscheme/racket libraries were
> initialised, e.g. in startup scripts and on the command line.
>
> Therefore the following would SEGV:
> vim +':mz 1'
>
> Even though:
> :mz 1
> works when editing a file.
>
> mzscheme expects to be invoked by a "trampoline" that wraps around the
> main() of the embedding environment -- and this trampoline is around
> main_loop().
>
> exe_pre_commands() and source_startup_scripts() are outside the scope
> of the trampoline.
>
> This patch causes main() to be called in two parts. The first part
> sets up vim's environment and globals, but does not execute any vim
> commands (as far as I can tell). It then calls to mzscheme_init, which
> eventually recurs into main(); which skips the initialisation, and
> proceeds with anything that may perform commands.
>
> Notes:
> * I pass fname and params between invocations of main() through the
> static variables save_mz_fname and save_mz_params. There is
> justification at the top of main() for doing so. I'm not so keen on
> statics, myself -- so I've not re-declared fname and params
> themselves.
> * The other option would be to split main into two parts -- an
> "initialisation" and a "commands" part. Then start up vim with:
> main(argc, argv)
> calls mzscheme_init(argc, argv, fname, params)
> calls ... main_part2(argc, argv, fname, params)
>
> [or, in the case of !FEAT_MZSCHEME: main(argc,argv) calls
> main_part2(argc, argv, fname, params)]
>
> I think I've done enough in main already! And, unless there is more
> general merit in such a refactoring, this is as much disruption as I
> need to cause :-)
>
> Thanks Sergey and Bram for your help!

Is this still on your todo list?
Is there a problem with the patch,
or are you waiting on some input from Sergey or me?

Tim

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

Bram Moolenaar

... I think it s this note: Other way to start Mzscheme. Tim Brown, 2011 Oct 5: change main call. Later patch by Sergey Khorev, 2011 Oct 9. I haven t looked at

Message 19 of 29
, Dec 10, 2011

0 Attachment

Tim Brown wrote:

> I've not seen this patch go into vim yet.
> Did I miss it?
>
> On Oct 5, 6:31 pm, Bram Moolenaar <B...@...> wrote:
> > Thanks for the patch, I'll put it on the todo list.
>
> Is this still on your todo list?
> Is there a problem with the patch,
> or are you waiting on some input from Sergey or me?

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

... It s in Vim Mercurial repository already :) -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you

Message 21 of 29
, Mar 28, 2012

0 Attachment

>> I haven't looked at it yet, are you OK with Sergey's patch that he sent
>> Oct 9?
>
>
> Sorry - took my eye off the ball here.
>
> I've been working fine with this patch applied since October. I'd be happy
> for it to be merged.

It's in Vim Mercurial repository already :)

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

Bram Moolenaar

... If I m not mistaken this was included with patch 7.3.441. So, unless there is something wrong, there nothing more to do. -- Edison s greatest achievement

Message 22 of 29
, Mar 28, 2012

0 Attachment

Tim Brown wrote:

> On 10 December 2011 20:20, Bram Moolenaar <Bram@...> wrote:
>
> > I think it's this note:
> >
> > Other way to start Mzscheme. Tim Brown, 2011 Oct 5: change main call.
> > Later patch by Sergey Khorev, 2011 Oct 9.
> >
> > I haven't looked at it yet, are you OK with Sergey's patch that he sent
> > Oct 9?
> >
>
> Sorry - took my eye off the ball here.
>
> I've been working fine with this patch applied since October. I'd be happy
> for it to be merged.

If I'm not mistaken this was included with patch 7.3.441. So, unless
there is something wrong, there nothing more to do.

--
Edison's greatest achievement came in 1879, when he invented the
electric company. Edison's design was a brilliant adaptation of the
simple electrical circuit: the electric company sends electricity
through a wire to a customer, then immediately gets the electricity
back through another wire