VAM cannot be normally tested in wine using gvim due to hit-enter prompts

[ZyX-I]

Unlike *nix where having : in typeahead is enough to force vim to skip hit-enter, in windows hit-enter appears in a separate window (because of vimrun.exe) and cannot be skipped.

Possible solutions are using :silent ! (or :silent! !) instead of :! and using system(). First will force you to put redraw somewhere in order not to mess up the view in terminal vim. Second will completely hide program output and has problems with newlines in arguments.

I am going to use :silent !+:redraw. Is this acceptable? In any case, hit-enter prompts are disturbing me on any system, but on windows they are also disturbing automated tests which cannot be stood.

[MarcWeber]

Why do we need wine to be supported? If you have wine you have linux. If you have linux everything works. Wine will never replace testing on real Windows. If you're bothering about tests - can't we make all command lines pipe output into a special file logfile instead? Then you can have a look at the test log to find out what went wrong. At least its an alternative to think about.

[ZyX-I]

Wine will never replace testing on real Windows.

It gives good enough approximation. I am not going to give up wine tests unless you have concrete examples of wine misbehavior that are preventing me from getting reliable results. Without it the discussion about using wine for testing is over.

By the way, do you really think that not testing at all is better then testing on wine?

Why do we need wine to be supported?

Run it on windows. I am sure you will have exactly the same behavior (unless you purge out vimrun.exe).

If you're bothering about tests - can't we make all command lines pipe output into a special file logfile instead?

I don't want to have a log. If I am going to look what went wrong I launch test in foreground. This solution will just produce lots of files that are not needed most of time. It also won't do anything with annoying hit-enter prompts on linux.

[ZyX-I]

I don't want to have a log. If I am going to look what went wrong I launch test in foreground. This solution will just produce lots of files that are not needed most of time. It also won't do anything with annoying hit-enter prompts on linux.

It may appear that I will want to have a log if I completely silence command output. system() may be better in this case as its output can be passed to :echo (where I can benefit from reenabling hit-enter) or logged internally to a variable (so that no unneeded files appear) . Though :silent is showing an output, it will gone once window is closed or :redraw will be reached. I can also imagine using :read ! and temporary buffer (it will handle newlines properly).

[MarcWeber]

I want Windows users to join and help out.

Helping out can be as minimal as writing bug reports. Unless that's happening I'm not going to spend much time on it.

Let me shut up. If you have the time I should say thanks. The philosophy behind VAM is KISS. Thus if there are no known bugs there is nothing to do.

Keep in mind that the best user experience could be reached by creating a linux proxy. Then VAM could ask the proxy to checkout git (on linux) and zip the result. Then one dependency on 7z or unzip would be enough on Windows. But Windows users have to ask me to work on this. This didn't happen yet. (See doc/*.txt line 728). That's why I asked whether this work is worth the effort.

I just don't want you to waste time on this. I'd appreciate having JIT for VimL much more :)

Anyway: do what you want - you know what and why you're doing something.

[ZyX-I]

The philosophy behind VAM is KISS.

It does not forbid testing.

Thus if there are no known bugs there is nothing to do.

That is what testing is for, isn't it? If there are no bugs, create some tests and you'll see them.

Other approaches are «I don't care about reputation and thus don't have to write tests» and «I have a mathematically correct proof of the fact that my software does not contain bugs».

.Keep in mind that the best user experience could be reached by creating a linux proxy. Then VAM could ask the proxy to checkout git (on linux) and zip the result. Then one dependency on 7z or unzip would be enough on Windows. But Windows users have to ask me to work on this. This didn't happen yet. (See doc/*.txt line 728). That's why I asked whether this work is worth the effort.

I don't think most users want to have unstable VCS versions. So it does not worth the affort: it won't remove 7z and curl dependencies.

// By the way, VAM-0.4.3 was posted at 24.08.2010 as stated on vim.org. I don't think you will get much reports from windows users.

[MarcWeber]

I don't think most users want to have unstable VCS versions. We agree to disagree :)

In my projects the latest version on "default branch" should always be the most stable.

If I do unstable changes I always create a new branch first always.

And you know that I'm working with garbas creating a new page which will display updates automatically.

So this issue will be fixed soon :)

[ZyX-I]

In my projects the latest version on "default branch" should always be the most stable.

Your projects are not the only ones. By the way, should not github zipball of «master» ref be added to s:plugin_sources in VAM-kr then? Or, better, set up the cron job that will remove last posted archive and then post github zipball to vim.org. Posting may be borrowed from pkgdo.pl, but I did not implement removing there.

So this issue will be fixed soon :)

It won't ever be fixed. You can't tell everybody that their development version must be stable even if you require to have it stable only in default branch.