Patch 8.2.2160

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2160
Problem:Various typos.
Solution:   Fix spelling mistakes. (closes #7494)
Files:  src/bufwrite.c, src/cindent.c, src/cmdexpand.c, src/eval.c,
src/ex_cmds.c, src/feature.h, src/getchar.c, src/gui_haiku.cc,
src/gui_xmdlg.c, src/help.c, src/if_ole.cpp, src/insexpand.c,
src/list.c, src/map.c, src/memline.c, src/normal.c,
src/os_win32.c, src/search.c, src/term.c,
src/testdir/test_arglist.vim, src/testdir/test_autocmd.vim,
src/testdir/test_debugger.vim, src/testdir/test_increment.vim,
src/testdir/test_menu.vim, src/testdir/test_netbeans.vim,
src/testdir/test_popupwin.vim, src/testdir/test_python2.vim,
src/testdir/test_python3.vim, src/testdir/test_sort.vim,
src/testdir/test_terminal2.vim, src/testdir/test_terminal3.vim,
src/testdir/test_vartabs.vim, src/testdir/test_vimscript.vim,
src/textprop.c, src/userfunc.c, src/vim9.h, src/vim9compile.c,
src/vim9execute.c


*** ../vim-8.2.2159/src/bufwrite.c  2020-11-23 22:01:22.642662389 +0100
--- src/bufwrite.c  2020-12-18 19:41:21.623585499 +0100
***
*** 2138,2144 
  if (!checking_conversion)
  {
  #if defined(UNIX) && defined(HAVE_FSYNC)
!   // On many journalling file systems there is a bug that causes both the
// original and the backup file to be lost when halting the system
// right after writing the file.  That's because only the meta-data is
// journalled.  Syncing the file slows down the system, but assures it
--- 2138,2144 
  if (!checking_conversion)
  {
  #if defined(UNIX) && defined(HAVE_FSYNC)
!   // On many journaling file systems there is a bug that causes both the
// original and the backup file to be lost when halting the system
// right after writing the file.  That's because only the meta-data is
// journalled.  Syncing the file slows down the system, but assures it
*** ../vim-8.2.2159/src/cindent.c   2020-05-31 17:49:21.776435849 +0200
--- src/cindent.c   2020-12-18 19:41:21.623585499 +0100
***
*** 2121,2127 
  }
  
  // #defines and so on go at the left when included in 'cinkeys',
! // exluding pragmas when customized in 'cinoptions'
  if (*theline == '#' && (*linecopy == '#' || in_cinkeys('#', ' ', TRUE)))
  {
char_u *directive = skipwhite(theline + 1);
--- 2121,2127 
  }
  
  // #defines and so on go at the left when included in 'cinkeys',
! // excluding pragmas when customized in 'cinoptions'
  if (*theline == '#' && (*linecopy == '#' || in_cinkeys('#', ' ', TRUE)))
  {
char_u *directive = skipwhite(theline + 1);
*** ../vim-8.2.2159/src/cmdexpand.c 2020-09-26 15:08:52.881779910 +0200
--- src/cmdexpand.c 2020-12-18 19:41:21.623585499 +0100
***
*** 1049,1055 
++p;
  }
  
! // If the cursor is touching the command, and it ends in an alpha-numeric
  // character, complete the command name.
  if (*p == NUL && ASCII_ISALNUM(p[-1]))
return NULL;
--- 1049,1055 
++p;
  }
  
! // If the cursor is touching the command, and it ends in an alphanumeric
  // character, complete the command name.
  if (*p == NUL && ASCII_ISALNUM(p[-1]))
return NULL;
*** ../vim-8.2.2159/src/eval.c  2020-12-13 20:26:25.928035621 +0100
--- src/eval.c  2020-12-18 19:41:21.623585499 +0100
***
*** 4631,4637 
   * "numbuf" is used for a number.
   * When "copyID" is not NULL replace recursive lists and dicts with "...".
   * When both "echo_style" and "composite_val" are FALSE, put quotes around
!  * stings as "string()", otherwise does not put quotes around strings, as
   * ":echo" displays values.
   * When "restore_copyID" is FALSE, repeated items in dictionaries and lists
   * are replaced with "...".
--- 4631,4637 
   * "numbuf" is used for a number.
   * When "copyID" is not NULL replace recursive lists and dicts with "...".
   * When both "echo_style" and "composite_val" are FALSE, put quotes around
!  * strings as "string()", otherwise does not put quotes around strings, as
   * ":echo" displays values.
   * When "restore_copyID" is FALSE, repeated items in dictionaries and lists
   * are replaced with "...".
*** ../vim-8.2.2159/src/ex_cmds.c   2020-11-25 20:09:05.513445582 +0100
--- src/ex_cmds.c   2020-12-18 19:41:21.623585499 +0100
***
*** 2660,2666 
if (tlnum <= 0)
tlnum = 1L;
}
!   // Add BLN_NOCURWIN to avoid a new wininfo items are assocated
// with the current window.
newbuf = buflist_new(ffname, sfname, tlnum,
BLN_LISTED | BLN_NOCURWIN);
--- 2660,2666 
if (tlnum <= 0)

Re: [vim/vim] netrw is slow over ssh (#7259)

2020-12-18 Fir de Conversatie Charles Campbell 

Christian Brabandt wrote:

On Fr, 18 Dez 2020, Charles Campbell wrote:


Christian Brabandt (Vim Github Repository) wrote:

 As far as the clipboard goes: it copies the clipboard into a local
 variable, and only if the clipboard value has changed during the
 course of netrw's operation will netrw restore the clipboard value
 (thus avoiding having netrw always be the last one to modify the
 clipboard).

How about adding a configuration option to leave the clipboard alone if
set. This would solve two problems:

   * the clipboard won't be accessed at all if configured. That means,
 Neovim guys wouldn't have any problems, since the external
 clipboard provider may be slow.
   * It won't corrupt the clipboard in case of any non-text items in it.

People complaining could then set this variable and be fine.



The only problem -- something netrw does inadvertently modifies the
clipboard. That ends up with it being unexpectedly changed, which means
"clipboard won't be accessed at all" is not going to happen. Its like
history -- I don't want to change the history, but there's a lot of
operations that netrw does which change the history -- so there's a lot of
code to keep the history unchanged. I could have netrw optionally not
restore the clipboard, but I'm sure (because of earlier complaints) that
there will be a raft of new complaints. Well, I guess I'll put in
yet-another-option to prevent netrw from doing a save&restore of the
clipboard (g:netrw_clipboard).

When would that happen, that netrw modifies the clipboard
unintentionally. Wouldn't that only be the case when the clipboard
option is set or the guioption includes a/A/p?
In looking over guioption a/A, I think that they would prevent the 
issue. As I recall, the problem occurrs with wide listings, because 
netrw does use visual selection to construct the columns internally. 
However, I wouldn't be certain that there's nothing else involved. I 
suppose that I could have netrw save&restore guioption and safe-option a 
and A out.

(safe-option: what netrw uses while its constructing its display).



I suppose if the user explicitly uses "+y to paste to the clipboard in
netrw, that should be okay.


It'd be a help if vim itself had an option to leave something alone (ie.
setl leavealone="history:clipboard:jumps"); then netrw and other plugins
could set that, do their job, then unset it.

Wouldn't setting guioptions and clipboard option to a value that exclude
clipboard interaction be good enough?

There are NetrwKeepj commands all over the netrw code, and I'm not at 
all sure that it does that wherever needed even so, just to leave the 
jump table alone. I'll install the save&restore&safe guioption and see 
if that helps.


Regards,
Chip Campbell

--
--
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 because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/acc1bba4-d6cc-8332-fda7-3d2e91fc1258%40drchip.org.

Re: [vim/vim] netrw is slow over ssh (#7259)

2020-12-18 Fir de Conversatie Christian Brabandt 


On Fr, 18 Dez 2020, Charles Campbell wrote:

> Christian Brabandt (Vim Github Repository) wrote:
> > 
> > As far as the clipboard goes: it copies the clipboard into a local
> > variable, and only if the clipboard value has changed during the
> > course of netrw's operation will netrw restore the clipboard value
> > (thus avoiding having netrw always be the last one to modify the
> > clipboard).
> > 
> > How about adding a configuration option to leave the clipboard alone if
> > set. This would solve two problems:
> > 
> >   * the clipboard won't be accessed at all if configured. That means,
> > Neovim guys wouldn't have any problems, since the external
> > clipboard provider may be slow.
> >   * It won't corrupt the clipboard in case of any non-text items in it.
> > 
> > People complaining could then set this variable and be fine.
> > 
> > 
> The only problem -- something netrw does inadvertently modifies the
> clipboard. That ends up with it being unexpectedly changed, which means
> "clipboard won't be accessed at all" is not going to happen. Its like
> history -- I don't want to change the history, but there's a lot of
> operations that netrw does which change the history -- so there's a lot of
> code to keep the history unchanged. I could have netrw optionally not
> restore the clipboard, but I'm sure (because of earlier complaints) that
> there will be a raft of new complaints. Well, I guess I'll put in
> yet-another-option to prevent netrw from doing a save&restore of the
> clipboard (g:netrw_clipboard).

When would that happen, that netrw modifies the clipboard 
unintentionally. Wouldn't that only be the case when the clipboard 
option is set or the guioption includes a/A/p?

I suppose if the user explicitly uses "+y to paste to the clipboard in 
netrw, that should be okay.

> It'd be a help if vim itself had an option to leave something alone (ie.
> setl leavealone="history:clipboard:jumps"); then netrw and other plugins
> could set that, do their job, then unset it.

Wouldn't setting guioptions and clipboard option to a value that exclude 
clipboard interaction be good enough?

Thanks,
Christian
-- 
Brüllt ein Mann, ist er dynamisch.
Brüllt eine Frau, ist sie hysterisch.
-- Hildegard Knef

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20201218162405.GR22416%40256bit.org.

Patch 8.2.2159

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2159
Problem:Vim9: when declaring a list it is not allocated yet, causing a
following extend() to fail.
Solution:   When fetching a variable value for a list or dict that is null
allocate the list or dict, so it can be used. (closes #7491)
Files:  src/vim9execute.c, src/testdir/test_vim9_assign.vim


*** ../vim-8.2.2158/src/vim9execute.c   2020-12-12 20:42:16.123207537 +0100
--- src/vim9execute.c   2020-12-18 17:22:39.654455314 +0100
***
*** 791,796 
--- 791,816 
  restore_funccal();
  }
  
+ /*
+  * When the value of "sv" is a null list of dict, allocate it.
+  */
+ static void
+ allocate_if_null(typval_T *tv)
+ {
+ switch (tv->v_type)
+ {
+   case VAR_LIST:
+   if (tv->vval.v_list == NULL)
+   rettv_list_alloc(tv);
+   break;
+   case VAR_DICT:
+   if (tv->vval.v_dict == NULL)
+   rettv_dict_alloc(tv);
+   break;
+   default:
+   break;
+ }
+ }
  
  /*
   * Execute a function by "name".
***
*** 1289,1294 
--- 1309,1315 
  
sv = ((svar_T *)si->sn_var_vals.ga_data)
 + iptr->isn_arg.script.script_idx;
+   allocate_if_null(sv->sv_tv);
if (GA_GROW(&ectx.ec_stack, 1) == FAIL)
goto failed;
copy_tv(sv->sv_tv, STACK_TV_BOT(0));
*** ../vim-8.2.2158/src/testdir/test_vim9_assign.vim2020-12-18 
15:37:57.248171925 +0100
--- src/testdir/test_vim9_assign.vim2020-12-18 17:17:04.923439023 +0100
***
*** 391,396 
--- 391,406 
assert_equal(['a', 'b'], list)
END
CheckScriptSuccess(lines)
+   lines =<< trim END
+   vim9script
+   var list: list
+   def Func()
+ extend(list, ['x', 'b'])
+   enddef
+   Func()
+   assert_equal(['x', 'b'], list)
+   END
+   CheckScriptSuccess(lines)
  
lines =<< trim END
vim9script
***
*** 584,591 
return test
  enddef
  FillDict()
END
!   CheckScriptFailure(lines, 'E1103:')
  
# assignment to global dict
lines =<< trim END
--- 594,602 
return test
  enddef
  FillDict()
+ assert_equal({a: 43}, test)
END
!   CheckScriptSuccess(lines)
  
# assignment to global dict
lines =<< trim END
*** ../vim-8.2.2158/src/version.c   2020-12-18 16:29:21.716008176 +0100
--- src/version.c   2020-12-18 17:05:52.817555014 +0100
***
*** 752,753 
--- 752,755 
  {   /* Add new patch number below this line */
+ /**/
+ 2159,
  /**/

-- 
BLACK KNIGHT: The Black Knight always triumphs. Have at you!
   ARTHUR takes his last leg off.  The BLACK KNIGHT's body lands upright.
BLACK KNIGHT: All right, we'll call it a draw.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202012181623.0BIGNgSv1305092%40masaka.moolenaar.net.

Re: [vim/vim] netrw is slow over ssh (#7259)

2020-12-18 Fir de Conversatie Charles Campbell 

Christian Brabandt (Vim Github Repository) wrote:


As far as the clipboard goes: it copies the clipboard into a local
variable, and only if the clipboard value has changed during the
course of netrw's operation will netrw restore the clipboard value
(thus avoiding having netrw always be the last one to modify the
clipboard).

How about adding a configuration option to leave the clipboard alone 
if set. This would solve two problems:


  * the clipboard won't be accessed at all if configured. That means,
Neovim guys wouldn't have any problems, since the external
clipboard provider may be slow.
  * It won't corrupt the clipboard in case of any non-text items in it.

People complaining could then set this variable and be fine.


The only problem -- something netrw does inadvertently modifies the 
clipboard. That ends up with it being unexpectedly changed, which means 
"clipboard won't be accessed at all" is not going to happen. Its like 
history -- I don't want to change the history, but there's a lot of 
operations that netrw does which change the history -- so there's a lot 
of code to keep the history unchanged. I could have netrw optionally not 
restore the clipboard, but I'm sure (because of earlier complaints) that 
there will be a raft of new complaints. Well, I guess I'll put in 
yet-another-option to prevent netrw from doing a save&restore of the 
clipboard (g:netrw_clipboard).


It'd be a help if vim itself had an option to leave something alone (ie. 
setl leavealone="history:clipboard:jumps"); then netrw and other plugins 
could set that, do their job, then unset it.


Regards,
Chip Campbell

--
--
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 because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2e6b1e0b-26ec-fe6d-2ed7-cd02bb8f078d%40drchip.org.

Patch 8.2.2158

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2158
Problem:CI on cirrus times out, coveralls doesn't always run.
Solution:   Set timeout to 20 minutes. Adjust condition. (closes #7493)
Files:  .cirrus.yml, .github/workflows/ci.yml


*** ../vim-8.2.2157/.cirrus.yml 2020-08-01 16:08:14.805278012 +0200
--- .cirrus.yml 2020-12-18 16:28:44.088152699 +0100
***
*** 3,8 
--- 3,10 
FEATURES: huge
  
  freebsd_12_task:
+   only_if: $CIRRUS_TAG == ''
+   timeout_in: 20m
freebsd_instance:
  image: freebsd-12-1-release-amd64
install_script:
*** ../vim-8.2.2157/.github/workflows/ci.yml2020-12-18 13:31:28.340166522 
+0100
--- .github/workflows/ci.yml2020-12-18 16:28:44.088152699 +0100
***
*** 231,237 
  runs-on: ubuntu-latest
  
  needs: linux
! if: github.event_name != 'pull_request'
  
  steps:
- name: Parallel finished
--- 231,237 
  runs-on: ubuntu-latest
  
  needs: linux
! if: always() && github.event_name != 'pull_request'
  
  steps:
- name: Parallel finished
*** ../vim-8.2.2157/src/version.c   2020-12-18 15:37:57.248171925 +0100
--- src/version.c   2020-12-18 16:27:40.484397385 +0100
***
*** 752,753 
--- 752,755 
  {   /* Add new patch number below this line */
+ /**/
+ 2158,
  /**/

-- 
Eye have a spelling checker, it came with my PC;
It plainly marks four my revue mistakes I cannot sea.
I've run this poem threw it, I'm sure your please to no,
It's letter perfect in it's weigh, my checker tolled me sew!

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202012181529.0BIFTpJI1287930%40masaka.moolenaar.net.

Patch 8.2.2157

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2157
Problem:Vim9: can delete a Vim9 script variable from a function.
Solution:   Check the variable is defined in Vim9 script. (closes #7483)
Files:  src/evalvars.c, src/testdir/test_vim9_assign.vim


*** ../vim-8.2.2156/src/evalvars.c  2020-12-12 14:33:37.096920916 +0100
--- src/evalvars.c  2020-12-18 15:36:50.432453442 +0100
***
*** 1663,1672 
--- 1663,1682 
  dict_T*d;
  dictitem_T*di;
  
+ // can't :unlet a script variable in Vim9 script
  if (in_vim9script() && check_vim9_unlet(name) == FAIL)
return FAIL;
  
  ht = find_var_ht(name, &varname);
+ 
+ // can't :unlet a script variable in Vim9 script from a function
+ if (ht == get_script_local_ht()
+   && SCRIPT_ID_VALID(current_sctx.sc_sid)
+   && SCRIPT_ITEM(current_sctx.sc_sid)->sn_version
+== SCRIPT_VERSION_VIM9
+   && check_vim9_unlet(name) == FAIL)
+   return FAIL;
+ 
  if (ht != NULL && *varname != NUL)
  {
d = get_current_funccal_dict(ht);
*** ../vim-8.2.2156/src/testdir/test_vim9_assign.vim2020-12-13 
18:44:39.741837064 +0100
--- src/testdir/test_vim9_assign.vim2020-12-18 15:36:02.912656559 +0100
***
*** 1211,1216 
--- 1211,1224 
CheckScriptFailure([
 'vim9script',
 'var svar = 123',
+'func Func()',
+'  unlet s:svar',
+'endfunc',
+'Func()',
+], 'E1081:')
+   CheckScriptFailure([
+'vim9script',
+'var svar = 123',
 'def Func()',
 '  unlet s:svar',
 'enddef',
*** ../vim-8.2.2156/src/version.c   2020-12-18 13:31:28.340166522 +0100
--- src/version.c   2020-12-18 15:34:21.825097971 +0100
***
*** 752,753 
--- 752,755 
  {   /* Add new patch number below this line */
+ /**/
+ 2157,
  /**/

-- 
"Beware of bugs in the above code; I have only proved
it correct, not tried it." -- Donald Knuth

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202012181438.0BIEcSdA1273489%40masaka.moolenaar.net.

Patch 8.2.2156

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2156
Problem:Github actions run on pusing a tag.
Solution:   Don't run CI on tag push. Omit coveralls on pull-request.
(Ozaki Kiichi, closes #7489)
Files:  .github/workflows/ci.yml, .github/workflows/codeql-analysis.yml


*** ../vim-8.2.2155/.github/workflows/ci.yml2020-12-17 20:26:54.801869450 
+0100
--- .github/workflows/ci.yml2020-12-18 13:29:50.684517132 +0100
***
*** 1,6 
  name: GitHub CI
  
! on: [push, pull_request]
  
  jobs:
linux:
--- 1,9 
  name: GitHub CI
  
! on:
!   push:
! branches: ['**']
!   pull_request:
  
  jobs:
linux:
***
*** 197,203 
do_test make ${SHADOWOPT} ${TEST}
  
- name: Coveralls
! if: matrix.coverage && success()
  env:
COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
COVERALLS_PARALLEL: true
--- 200,206 
do_test make ${SHADOWOPT} ${TEST}
  
- name: Coveralls
! if: matrix.coverage && success() && github.event_name != 
'pull_request'
  env:
COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
COVERALLS_PARALLEL: true
***
*** 210,217 
  
- name: Codecov
  if: matrix.coverage && success()
! run: |
!   cd "${SRCDIR}" && bash <(curl -s https://codecov.io/bash)
  
- name: ASan logs
  if: contains(matrix.extra, 'asan') && !cancelled()
--- 213,223 
  
- name: Codecov
  if: matrix.coverage && success()
! uses: codecov/codecov-action@v1
! with:
!   flags: ${{ matrix.features }}-${{ matrix.compiler }}-${{ 
matrix.extra }}
!   fail_ci_if_error: true
!   working-directory: ${{ env.SRCDIR }}
  
- name: ASan logs
  if: contains(matrix.extra, 'asan') && !cancelled()
***
*** 225,231 
  runs-on: ubuntu-latest
  
  needs: linux
! if: always()
  
  steps:
- name: Parallel finished
--- 231,237 
  runs-on: ubuntu-latest
  
  needs: linux
! if: github.event_name != 'pull_request'
  
  steps:
- name: Parallel finished
*** ../vim-8.2.2155/.github/workflows/codeql-analysis.yml   2020-12-18 
13:15:16.568424388 +0100
--- .github/workflows/codeql-analysis.yml   2020-12-18 13:30:42.144331277 
+0100
***
*** 31,40 
  steps:
  - name: Checkout repository
uses: actions/checkout@v2
-   with:
- # We must fetch at least the immediate parents so that if this is
- # a pull request then we can checkout the head.
- fetch-depth: 2
  
  # Initializes the CodeQL tools for scanning.
  - name: Initialize CodeQL
--- 31,36 
*** ../vim-8.2.2155/src/version.c   2020-12-18 13:15:16.568424388 +0100
--- src/version.c   2020-12-18 13:30:19.288413502 +0100
***
*** 752,753 
--- 752,755 
  {   /* Add new patch number below this line */
+ /**/
+ 2156,
  /**/

-- 
Any resemblance between the above views and those of my employer, my terminal,
or the view out my window are purely coincidental.  Any resemblance between
the above and my own views is non-deterministic.  The question of the
existence of views in the absence of anyone to hold them is left as an
exercise for the reader.  The question of the existence of the reader is left
as an exercise for the second god coefficient.  (A discussion of
non-orthogonal, non-integral polytheism is beyond the scope of this article.)
(Ralph Jennings)

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202012181232.0BICW1kr1244386%40masaka.moolenaar.net.

Patch 8.2.2155

2020-12-18 Fir de Conversatie Bram Moolenaar 


Patch 8.2.2155
Problem:Warning from Github actions for code analysis.
Solution:   Remove the "git checkout HEAD^2" block.
Files:  .github/workflows/codeql-analysis.yml


*** ../vim-8.2.2154/.github/workflows/codeql-analysis.yml   2020-10-02 
10:29:28.520196600 +0200
--- .github/workflows/codeql-analysis.yml   2020-12-18 13:13:33.184850388 
+0100
***
*** 36,46 
  # a pull request then we can checkout the head.
  fetch-depth: 2
  
- # If this run was triggered by a pull request event, then checkout
- # the head of the pull request instead of the merge commit.
- - run: git checkout HEAD^2
-   if: ${{ github.event_name == 'pull_request' }}
- 
  # Initializes the CodeQL tools for scanning.
  - name: Initialize CodeQL
uses: github/codeql-action/init@v1
--- 36,41 
*** ../vim-8.2.2154/src/version.c   2020-12-17 22:27:34.633086324 +0100
--- src/version.c   2020-12-18 13:15:04.448496648 +0100
***
*** 752,753 
--- 752,755 
  {   /* Add new patch number below this line */
+ /**/
+ 2155,
  /**/

-- 
ARTHUR:   You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR:   You stupid bastard.  You havn't got any arms left.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202012181215.0BICFwbf1240078%40masaka.moolenaar.net.