tests: use v:progpath instead of GetVimProg #4806

blueyed · 2019-08-12T13:57:27Z

TODO:

do not write it to vimcmd in the first place

Ref: da65058#r34658132

TODO: - [ ] do not write it to vimcmd in the first place Ref: vim@da65058#r34658132

codecov-io · 2019-08-12T14:19:56Z

Codecov Report

Merging #4806 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4806      +/-   ##
==========================================
+ Coverage   81.55%   81.55%   +<.01%     
==========================================
  Files         118      118              
  Lines      145681   145681              
==========================================
+ Hits       118804   118807       +3     
+ Misses      26877    26874       -3

Impacted Files	Coverage Δ
src/gui_beval.c	`62.5% <0%> (-0.87%)`	⬇️
src/if_xcmdsrv.c	`85.63% <0%> (-0.54%)`	⬇️
src/gui.c	`63.65% <0%> (-0.06%)`	⬇️
src/os_unix.c	`63.29% <0%> (-0.05%)`	⬇️
src/window.c	`87.76% <0%> (-0.04%)`	⬇️
src/terminal.c	`81.34% <0%> (+0.03%)`	⬆️
src/viminfo.c	`75.64% <0%> (+0.52%)`	⬆️
src/profiler.c	`93.25% <0%> (+0.56%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d5e3cc1...e3431b9. Read the comment docs.

blueyed · 2019-08-12T14:24:53Z

v:progpath was mentioned to not work in #2186, but then crossed out.

/cc @ichizok

Problem: Test_popup_and_window_resize() does not always pass. Solution: Do not use $VIMPROG, pass the Vim executable in the vimcmd file. (Ozaki Kiichi, closes vim/vim#2186) vim/vim@6318205 NOTE: Does not add `GetVimProg()`, but keeps/syncs existing usages of it in tests (which obviously are all skipped, mostly because of `!has('terminal')`). Likely to be replaced with `v:progpath` in Vim [1], or at least that would/should be used with Neovim then probably. 1: vim/vim#4806

brammool · 2019-08-12T22:51:36Z

This is not going to work, because on some systems v:progpath is just "vim". I tried on Mac OS.

brammool · 2019-08-12T23:16:45Z

Daniel Hahler wrote:

`v:progpath` was mentioned to not work in #2186, but then crossed out.

No idea why it was crossed out, it can reproduce it with the current version of Vim (on MacOS).

…

-- The real trick is this: to keep the lines as short as possible and keep the size the same yet free from the need for hyphena- Dammit!! (Matthew Winn) /// Bram Moolenaar -- [email protected] -- 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 ///

blueyed · 2019-08-13T14:01:04Z

v:progpath

According to #2186 (comment) it is relative / just "vim" when not starting it with an absolute path?
According to the help this sounds like a bug, since it should be absolute always.

From da65058#r34664494:

$VIMPROG may be different from v:progpath, depending on what test you are running and how. I sometimes source a test*.vim file and expect the vim command executed in the terminal be the one that was most recently build, not the one I'm currently running.

So in the case of sourcing a test it would fall back to '../vim' then (because there is no vimcmd), no? (and the Makefile would also write '../vim' there).

How do you "source a test*.vim file" exactly?
(It is required to be in src/testdir then already (for the relative "imports"), and tests are not run automatically when sourcing. Do you run the test function then manually?)

(Also it appears to make a difference only for a few tests, i.e. other tests would use the current Vim instance anyway - resulting in a mix of current/build Vim being used)

The vimcmd file has two lines, the stuff in the second line is not in v:progpath, thus we can't drop writing "vimcmd".

Yes, I've not meant to remove the file completely.

Problem: Test_popup_and_window_resize() does not always pass. Solution: Do not use $VIMPROG, pass the Vim executable in the vimcmd file. (Ozaki Kiichi, closes vim/vim#2186) vim/vim@6318205 vim-patch:8.0.1526: no test using a screen dump yet Problem: No test using a screen dump yet. Solution: Add a test for C syntax highlighting. Add helper functions. vim/vim@da65058 NOTE: uses modified `GetVimProg()` (which is used with skipped tests only (mostly because of `!has('terminal')`)). Vim uses a 'vimcmd' file, while Nvim uses `$NVIM_TEST_ARGX` environment variables. Ref: vim/vim#4806

blueyed · 2019-08-13T14:40:18Z

For reference: v:progpath is used already in other tests. According to the argument above it should use GetVimProg() then probably?

Problem: Test_popup_and_window_resize() does not always pass. Solution: Do not use $VIMPROG, pass the Vim executable in the vimcmd file. (Ozaki Kiichi, closes vim/vim#2186) vim/vim@6318205 vim-patch:8.0.1526: no test using a screen dump yet Problem: No test using a screen dump yet. Solution: Add a test for C syntax highlighting. Add helper functions. vim/vim@da65058 NOTE: uses modified `GetVimProg()` (which is used with skipped tests only (mostly because of `!has('terminal')`)). Vim uses a 'vimcmd' file, while Nvim uses `$NVIM_TEST_ARGX` environment variables. Ref: vim/vim#4806

brammool · 2019-08-13T21:37:35Z

Daniel Hahler wrote:

> v:progpath According to #2186 (comment) it is relative / just "vim" when not starting it with an absolute path? According to the help this sounds like a bug, since it should be absolute always.

The docs may be a bit confusing. It mentions "including the path", but that means it includes the path if it was given. The help also says to use "exepath()" to get the full path, but on Linux a special trick is used to get the actual path of the executable, which ends up to always be a full path. While on Mac you only get the full path if Vim was started with a path, not when just typing "vim". I'll add some more explanation to the help.

…

-- Q: What is a patch 22? A: A patch you need to include to make it possible to include patches. /// Bram Moolenaar -- [email protected] -- 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 ///

brammool · 2019-08-13T21:37:36Z

For reference: `v:progpath` is a used already in other tests. According to the argument above it should use `GetVimProg()` then probably?

There are actually quite a lot of them. We defenitely want to avoid the inconsistency. Since changing it either way will change the executable used in corner cases, perhaps we should go for the simpler one and use v:progpath?

…

-- "I can't complain, but sometimes I still do." (Joe Walsh) /// Bram Moolenaar -- [email protected] -- 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 ///

blueyed · 2019-08-14T05:18:03Z

For reference: v:progpath is a used already in other tests. According to
the argument above it should use GetVimProg() then probably?

There are actually quite a lot of them. We defenitely want to avoid the
inconsistency. Since changing it either way will change the executable used
in corner cases, perhaps we should go for the simpler one and use v:progpath?

I think having a method (GetVimProg) allows for more flexibility, e.g. when
you want to prepend something always (e.g. "covimerage run --append" to get
coverage).
For this however it would need to return a list then, and would not really
reflect what the name implies then.

So for this it would be better to not use v:progpath/GetVimProg in tests,
but the already existing GetVimCommand() and GetVimCommandClean() functions
(which currently return a string - but could be changed to use a list (not
necessary, but cleaner)).

brammool · 2019-08-14T19:10:08Z

Daniel Hahler wrote:

>> For reference: `v:progpath` is a used already in other tests. According to >> the argument above it should use `GetVimProg()` then probably? > There are actually quite a lot of them. We defenitely want to avoid the > inconsistency. Since changing it either way will change the executable used > in corner cases, perhaps we should go for the simpler one and use v:progpath? I think having a method (`GetVimProg`) allows for more flexibility, e.g. when you want to prepend something always (e.g. "covimerage run --append" to get coverage). For this however it would need to return a list then, and would not really reflect what the name implies then. So for this it would be better to not use `v:progpath`/`GetVimProg` in tests, but the already existing `GetVimCommand()` and `GetVimCommandClean()` functions (which currently return a string - but could be changed to use a list (not necessary, but cleaner)).

OK, let me do that and see what we end up with. We can at least drop some "-u NONE" and "--clean" arguments.

…

-- "I simultaneously try to keep my head in the clouds and my feet on the ground. Sometimes it's a stretch, though." -- Larry Wall /// Bram Moolenaar -- [email protected] -- 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 ///

Problem: Inconsistently using GetVimCommand() and v:progpath. (Daniel Hahler) Solution: Use GetVimCommand(). (closes #4806)

Problem: Inconsistently using GetVimCommand() and v:progpath. (Daniel Hahler) Solution: Use GetVimCommand(). (closes vim#4806)

Problem: Inconsistently using GetVimCommand() and v:progpath. (Daniel Hahler) Solution: Use GetVimCommand(). (closes vim/vim#4806) vim/vim@93344c2 Cherry-pick a change to test_profile.vim from patch 8.1.1544. Cherry-pick a change to test_vimscript.vim from patch 8.1.1826. Some of the args are no-op in Nvim, and `-i NONE` and `--headless` are already added by `GetVimCommand()`. I'll try to match the order of args in upstream, substituting `--not-a-term` with `--headless`.

tests: use v:progpath instead of GetVimProg

e3431b9

TODO: - [ ] do not write it to vimcmd in the first place Ref: vim@da65058#r34658132

blueyed mentioned this pull request Aug 12, 2019

vim-patch:8.0.1179: Test_popup_and_window_resize() does not always pass neovim/neovim#10752

Merged

brammool closed this Aug 12, 2019

brammool added a commit that referenced this pull request Aug 14, 2019

patch 8.1.1846: inconsistently using GetVimCommand() and v:progpath

93344c2

Problem: Inconsistently using GetVimCommand() and v:progpath. (Daniel Hahler) Solution: Use GetVimCommand(). (closes #4806)

zeertzjq mentioned this pull request Feb 14, 2022

vim-patch:8.1.{1846,1955},8.2.0156 neovim/neovim#17403

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Uh oh!

tests: use v:progpath instead of GetVimProg #4806

tests: use v:progpath instead of GetVimProg #4806

Uh oh!

blueyed commented Aug 12, 2019

Uh oh!

codecov-io commented Aug 12, 2019

Uh oh!

blueyed commented Aug 12, 2019

Uh oh!

brammool commented Aug 12, 2019

Uh oh!

brammool commented Aug 12, 2019 via email

Uh oh!

blueyed commented Aug 13, 2019

Uh oh!

blueyed commented Aug 13, 2019 •

edited

Loading

Uh oh!

brammool commented Aug 13, 2019 via email

Uh oh!

brammool commented Aug 13, 2019 via email

Uh oh!

blueyed commented Aug 14, 2019

Uh oh!

brammool commented Aug 14, 2019 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

tests: use v:progpath instead of GetVimProg #4806

tests: use v:progpath instead of GetVimProg #4806

Uh oh!

Conversation

blueyed commented Aug 12, 2019

Uh oh!

codecov-io commented Aug 12, 2019

Codecov Report

Uh oh!

blueyed commented Aug 12, 2019

Uh oh!

brammool commented Aug 12, 2019

Uh oh!

brammool commented Aug 12, 2019 via email

Uh oh!

blueyed commented Aug 13, 2019

Uh oh!

blueyed commented Aug 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brammool commented Aug 13, 2019 via email

Uh oh!

brammool commented Aug 13, 2019 via email

Uh oh!

blueyed commented Aug 14, 2019

Uh oh!

brammool commented Aug 14, 2019 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

blueyed commented Aug 13, 2019 •

edited

Loading