Commit Graph
487 Commits
Author SHA1 Message Date
bfredl 43e8ec92de fix(tui): more work in the TUI 2022-12-31 13:25:26 +01:00
zeertzjqandRob Pilling 3b9bd7bd43 vim-patch:9.0.1092: search error message doesn't show used pattern (#21518)
Problem:    Search error message doesn't show used pattern.
Solution:   Pass the actually used pattern to where the error message is
            given. (Rob Pilling, closes vim/vim#11742)

https://github.com/vim/vim/commit/e86190e7c1297da29d0fc2415fdeca5ecae8d2ba

Co-authored-by: Rob Pilling <robpilling@gmail.com>
2022-12-24 07:55:03 +08:00
zeertzjq b2d984558b test(unit): use file:close() properly (#21505) 2022-12-22 22:17:01 +08:00
luukvbaal 8147d3df28 vim-patch:9.0.0844: handling 'statusline' errors is spread out (#20992)
Problem:    Handling 'statusline' errors is spread out.
Solution:   Pass the option name to the lower levels so the option can be
            reset there when an error is encountered. (Luuk van Baal,
            closes vim/vim#11467)

https://github.com/vim/vim/commit/7b224fdf4a29f115567d4fc8629c1cef92d8444a
2022-11-08 07:21:22 +08:00
zeertzjq f2d9c330fc fix(path): don't remove trailing slash when getting absolute path (#20853)
Before Vim patch 8.2.3468 relative_directory is never used in the
resulting path name, so whether it has a trailing slash didn't matter.
Now path_full_dir_name() appends a non-existing relative directory to
the current directory name, so the trailing slash needs to be kept.
2022-10-30 07:10:04 +08:00
zeertzjqandBram Moolenaar 46a54dd6a0 vim-patch:8.2.1852: map() returing zero for NULL list is unexpected
Problem:    map() returing zero for NULL list is unexpected.
Solution:   Return the empty list. (closes vim/vim#7133)

https://github.com/vim/vim/commit/ffdf8adfa8108d4765fdc68abbd2fe49a4292b25

Co-authored-by: Bram Moolenaar <Bram@vim.org>
2022-10-26 20:53:39 +08:00
Dundar Göc 73207cae61 refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
2022-09-06 16:44:37 +02:00
sigmaSd a4e4609d62 fix(path): path_is_url returns false for "foo:/" #19797
Problem:
path_to_url() returns false for single-slash URIs ("foo:/" vs "foo://").
This is not compliant with the URI spec. https://url.spec.whatwg.org/#url-representation
LSP in particular allows single-slash URIs.

Solution:
Relax path_to_url() to accept single-slash URIs. This is not fully
compliant (only ":" is required by the spec), but it is hopefully good
enough without causing false-positives in typical text files.

ref https://url.spec.whatwg.org/#windows-drive-letter
ref https://github.com/neovim/neovim/pull/19773
ref https://github.com/neovim/neovim/pull/19773#issuecomment-1214763769
2022-08-23 23:38:06 -07:00
zeertzjq ff5cfcdeab vim-patch:8.1.2045: the option.c file is too big (#19854)
Problem:    The option.c file is too big.
Solution:   Split off the code dealing with strings. (Yegappan Lakshmanan,
            closes vim/vim#4937)
https://github.com/vim/vim/commit/dac1347b4d9c1a1aef6aa73fdea08a9d1077d6ea

Cherry-pick set_string_option_direct_in_win() from patch 8.1.1405.
Cherry-pick shift_line() comment change from patch 8.1.2096.
Move 'clipboard' default parsing to didset_string_options().
Reorder option flags to put Nvim-only flags at the end.
2022-08-20 17:26:44 +08:00
bfredl 6adc2ae7e0 refactor: move statusline code from buffer.c and [draw]screen.c to new file
problem: code for drawing statusline is arbitrarily spreadout between drawscreen.c, screen.c and buffer.c
solution: move it to a new file statusline.c

- rename archaic internal name "status match" to public name "wildmenu"
- showruler() does not show the ruler. it show anything which displays
  info about the cursor. Rename it accordingy.
2022-08-19 22:48:03 +02:00
zeertzjq 2af9be3db5 vim-patch:8.1.1966: some code in options.c fits better elsewhere (#19840)
Problem:    Some code in options.c fits better elsewhere.
Solution:   Move functions from options.c to other files. (Yegappan
            Lakshmanan, closes vim/vim#4889)
https://github.com/vim/vim/commit/e677df8d93772a705f40a94f3c871aee78fe4d99
2022-08-19 19:20:39 +08:00
zeertzjq 02a4974418 vim-patch:7.4.1168 (#19645)
Problem:    This doesn't give the right result: eval(string(v:true)). (Nikolay
            Pavlov)
Solution:   Make the string "v:true" instead of "true".
https://github.com/vim/vim/commit/f48aa160fdd7b8caa7678e1a2139244dd2bdc547
2022-08-13 21:31:00 +08:00
Justin M. Keyes f50135a32e feat: stdpath('run'), /tmp/nvim.user/ #18993
Problem:
- Since c57f6b28d7 #8519, sockets are created in ~/.local/… but XDG
  spec says: "XDG_RUNTIME_DIR: Must be on the local filesystem", which
  implies that XDG_STATE_DIR is potentially non-local.
- Not easy to inspect Nvim-created temp files (for debugging etc).

Solution:
- Store sockets in stdpath('run') ($XDG_RUNTIME_DIR).
- Establish "/tmp/nvim.user/" as the tempdir root shared by all Nvims.
- Make ok() actually useful.
- Introduce assert_nolog().

closes #3517
closes #17093
2022-06-30 04:16:46 -07:00
Justin M. Keyes f05a2891d3 build: rename build-related dirs
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.

Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
  tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
2022-06-28 04:02:29 -07:00
zeertzjq 6130b4a84b vim-patch:8.2.1898: command modifier parsing always uses global cmdmod
Problem:    Command modifier parsing always uses global cmdmod.
Solution:   Pass in cmdmod_T to use.  Rename struct fields consistently.
https://github.com/vim/vim/commit/e10044015841711b989f9a898d427bcc1fdb4c32
2022-06-14 20:58:34 +08:00
Jun-ichi TAKIMOTO 285e738942 test(unit): use setup()/teardown() in buffer_spec.lua (#18739) 2022-05-28 10:14:12 +08:00
Jun-ichi TAKIMOTO afa99f42b3 fix(unittests): coredump when running unit tests #18663
fs_init() must be called before early_init() in init/helpers.lua

If I run 'make unittest' on my Mac (macOS 10.14/Mojave or 12/Big Sur, intel
CPU), every test produce a core dump.

Call sequence in the core is:
    early_init()            main.c:197
    set_init_1()            option.c:508
    runtimepath_default()   runtime.c:1205
    get_lib_dir()           runtime.c:1175
    os_isdir()              fs.c:137
    os_getperm()            fs.c:777
    os_stat()               fs.c:761
    fs_loop_lock()          fs.c:72
    uv_mutex_lock(&fs_loop_mutex)   thread.c:352
    abort()

.deps/build/src/libuv/src/unix/thread.c:

    void uv_mutex_lock(uv_mutex_t* mutex) {
      if (pthread_mutex_lock(mutex))
        abort();	// line 352
    }

So pthread_mutex_lock(&fs_loop_mutex) failed. The reason seems to be simple.
fs_init() was not called and fs_loop_mutex has not been initialized. fs_init()
was moved out from early_init() in main.c by
b87867e69e, but unit/helpers.lua was not updated
accordingly.
2022-05-20 20:18:17 -07:00
Dundar GocandKalle Ranki 1a0de90068 refactor: move reverse_text to strings.c as it's a string operation
Also add tests for reverse_text.

Co-authored-by: Kalle Ranki <kalle.ranki@gmail.com>
2022-05-20 16:11:54 +02:00
Dundar Goc 10868dbf89 fix(PVS/V1044): suppress warning 2022-05-17 22:26:25 +02:00
zeertzjq 3a91adabda refactor: rename keymap.{c,h} to keycodes.{c,h} (#18535)
Most code in keymap.h is for keycode definitions, while most code in
keymap.c is for the parsing and conversion of keycodes.

The name "keymap" may also make people think these two files are for
mappings, while in fact keycodes are used even when no mappings are
involved, so "keycodes" should be a better file name than "keymap".
2022-05-12 20:19:29 +08:00
zeertzjq abe91e1efe vim-patch:8.2.0855: GUI tests fail because the test doesn't use a modifier
Problem:    GUI tests fail because the test doesn't use a modifier.
Solution:   Add "\{xxx}" to be able to encode a modifier.
https://github.com/vim/vim/commit/ebe9d34aa07037cff2188a8dd424ee1f59cbb0bf

Change macros to enums to use them in unit tests.
2022-04-29 15:51:04 +08:00
zeertzjq dde4f09f51 vim-patch:8.1.2145: cannot map <C-H> when modifyOtherKeys is enabled
Problem:    Cannot map <C-H> when modifyOtherKeys is enabled.
Solution:   Add the <C-H> mapping twice, both with modifier and as 0x08.  Use
            only the first one when modifyOtherKeys has been detected.
https://github.com/vim/vim/commit/459fd785e4a8d044147a3f83a5fca8748528aa84

Add REPTERM_NO_SPECIAL instead of REPTERM_SPECIAL because the meaning of
"special" is different between Vim and Nvim.
Omit seenModifyOtherKeys as Nvim supports attaching multiple UIs.
Omit tests as they send terminal codes.
Keep the behavior of API functions.
2022-04-29 15:51:03 +08:00
zeertzjq 519e4c4472 test: correct order of arguments to eq() and neq() 2022-04-26 11:38:58 +08:00
zeertzjq 44b59d1a69 vim-patch:8.2.0004: get E685 and E931 if buffer reload is interrupted
Problem:    Get E685 and E931 if buffer reload is interrupted.
Solution:   Do not abort deleting a dummy buffer. (closes vim/vim#5361)
https://github.com/vim/vim/commit/a6e8f888e7fc31b8ab7233509254fb2e2fe4089f
2022-04-08 08:54:07 +08:00
bfredl 3c7e937a89 Merge pull request #17266 from famiu/feat/ui/global-statusline
feat(statusline): add global statusline
2022-03-17 20:16:39 +01:00
Famiu Haque 5ab1229174 feat: add support for global statusline
Ref: #9342

Adds the option to have a single global statusline for the current window at the bottom of the screen instead of a statusline at the bottom of every window. Enabled by setting `laststatus = 3`.

Due to the fact that statuslines at the bottom of windows are removed when global statusline is enabled, horizontal separators are used instead to separate horizontal splits. The horizontal separator character is configurable through the`horiz` item in `'fillchars'`. Separator connector characters are also used to connect the horizontal and vertical separators together, which are also configurable through the `horizup`, `horizdown`, `vertleft`, `vertright` and `verthoriz` items in `fillchars`.

The window separators are highlighted using the `WinSeparator` highlight group, which supersedes `VertSplit` and is linked to `VertSplit` by default in order to maintain backwards compatibility.
2022-03-18 00:21:41 +06:00
Dundar Göc fff527b88d test(strcase_save): test overlong UTF8-encoding 2022-03-05 16:40:03 +01:00
zeertzjq f4300985d3 Merge pull request #17113 from zeertzjq/vim-8.2.2569
feat(statusline): support multibyte fillchar
2022-02-01 17:57:01 +08:00
zeertzjq c0a97d982a test(unit): add unit tests for path_with_url 2022-01-24 13:01:35 +08:00
zeertzjq be15ac06ba feat(statusline): support multibyte fillchar
This includes a partial port of Vim patch 8.2.2569 and some changes to
nvim_eval_statusline() to allow a multibyte fillchar. Literally every
line of C code touched by that patch has been refactored in Nvim, and
that patch contains some irrelevant foldcolumn tests I'm not sure how to
port (as Nvim's foldcolumn behavior has diverged from Vim's).
2022-01-16 19:54:27 +08:00
Björn Linse 95ab979fde refactor(extmarks): use a more efficient representation
marktree.c was originally constructed as a "generic" datatype,
to make the prototyping of its internal logic as simple as possible
and also as the usecases for various kinds of extmarks/decorations was not yet decided.
As a consequence of this, various extra indirections and allocations was
needed to use marktree to implement extmarks (ns/id pairs) and
decorations of different kinds (some which is just a single highlight
id, other an allocated list of virtual text/lines)

This change removes a lot of indirection, by making Marktree specialized
for the usecase. In particular, the namespace id and mark id is stored
directly, instead of the 64-bit global id particular to the Marktree
struct. This removes the two maps needed to convert between global and
per-ns ids.

Also, "small" decorations are stored inline, i.e. those who
doesn't refer to external heap memory anyway. That is highlights (with
priority+flags) are stored inline, while virtual text, which anyway
occurs a lot of heap allocations, do not. (previously a hack was used
to elide heap allocations for highlights with standard prio+flags)

TODO(bfredl): the functionaltest-lua CI version of gcc is having
severe issues with uint16_t bitfields, so splitting up compound
assignments and redundant casts are needed. Clean this up once we switch
to a working compiler version.
2022-01-15 22:08:12 +01:00
0b0c4f7dfa chore: fix typos (#16816)
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Sebastian Volland <seb@baunz.net>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2022-01-04 11:07:40 -07:00
zeertzjq 5b153f5d3d test: remove references to misc1.c 2021-12-11 07:10:01 +08:00
zeertzjq 0f58ba10e2 vim-patch:8.2.3468: problem with :cd when editing file in non-existent directory
Problem:    Problem with :cd when editing file in non-existent directory. (Yee
            Cheng Chin)
Solution:   Prepend the current directory to get the full path. (closes vim/vim#8903)
https://github.com/vim/vim/commit/c6376c798433bcb9ee38a8664299d11454546950
2021-11-19 20:07:04 +08:00
Björn Linse a60beeb34f refactor(api): break out Vim script functions to its own file 2021-10-29 16:59:53 +02:00
Björn Linse 8d7816cf27 feat(decorations): support more than one virt_lines block 2021-10-23 14:17:09 +02:00
Sean Dewar 9e38c4a79f vim-patch:8.2.1473: items in a list given to :const can still be modified
Problem:    Items in a list given to :const can still be modified.
Solution:   Work like ":lockvar! name" but don't lock referenced items.
            Make locking a blob work.
https://github.com/vim/vim/commit/021bda56710d98c09a6b35610a476ab2dd8c58ad
2021-09-16 00:13:41 +01:00
Sean Dewar 90a4cf92d2 vim-patch:8.2.0886: cannot use octal numbers in scriptversion 4
Problem:    Cannot use octal numbers in scriptversion 4.
Solution:   Add the "0o" notation. (Ken Takata, closes vim/vim#5304)
https://github.com/vim/vim/commit/c17e66c5c0acd5038f1eb3d7b3049b64bb6ea30b

:scriptversion is N/A.

Cherry-pick latest str2nr() doc changes from v8.1.2035.
Cherry-pick various mentions of the 0o prefix from:
 - v8.2.2324
 - https://github.com/vim/vim/commit/2346a6378483c9871016f9fc821ec5cbea638f13
 - https://github.com/vim/vim/commit/11e3c5ba820325b69cb56f70e13c21d7b8808d33
 - https://github.com/vim/vim/commit/82be4849eed0b8fbee45bc8da99b685ec89af59a

Patch used ascii_isbdigit() by mistake, which was fixed in v8.2.2309.

Make STR2NR_OOCT work the same as STR2NR_OCT when forcing.
In Vim, STR2NR_FORCE | STR2NR_OOCT isn't handled, and doesn't actually
force anything. Rather than abort(), make it work as STR2NR_OCT.

This means STR2NR_FORCE | STR2NR_OCT works the same as
STR2NR_FORCE | STR2NR_OOCT and STR2NR_FORCE | STR2NR_OCT | STR2NR_OOCT.
2021-09-11 15:36:03 +01:00
Sean Dewar b6d9e92805 vim-patch:8.1.2036: the str2nr() tests fail
Problem:    The str2nr() tests fail.
Solution:   Add missing part of patch.
https://github.com/vim/vim/commit/1ac90b4fa63414d56750559506a3e076df6923b0

Add extra tests for quoted numbers in vim_str2nr_spec.lua, as the
included ones in this patch are somewhat lacking.
2021-09-11 15:33:20 +01:00
Sean Dewar 34cb087955 vim-patch:8.1.1355: obvious mistakes are accepted as valid expressions
Problem:    Obvious mistakes are accepted as valid expressions.
Solution:   Be more strict about parsing numbers. (Yasuhiro Matsumoto,
            closes vim/vim#3981)
https://github.com/vim/vim/commit/16e9b85113e0b354ece1cb4f5fcc7866850f3685

Update vim_str2nr_spec.lua to add more tests that use strict = true.
2021-09-11 15:33:19 +01:00
James McCoy 57fc3d3ed7 Merge pull request #15386 from jamessan/32-bit-revert
Revert "tests: unit: fix preprocess: pass -m32 for 32bit ABI (#11073)"
2021-08-16 07:29:17 -04:00
James McCoy c417d573a3 Revert "tests: unit: fix preprocess: pass -m32 for 32bit ABI (#11073)"
This reverts commit ed11721b6b.

It broke multiple 32-bit builds and isn't actually required for building
in a true x86 32-bit environment.
2021-08-16 00:02:22 -04:00
Gregory Anders 9afa0d25a6 fix(highlight): remove syncolor.vim
Remove syncolor.vim in favor of defining the default highlight groups
directly in `init_highlight`. This approach provides a number of
advantages:

1. The highlights are always defined, regardless of whether or not the
   syntax regex engine is enabled.
2. Redundant sourcing of syntax files is eliminated (syncolor.vim was
   often sourced multiple times based on how the user's colorscheme file
   was written).
3. The syntax highlighting regex engine and the highlight groups
   themselves are more fully decoupled.
4. Removal of the confusing `:syntax on` / `:syntax enable` dichotomy
   (they now both do the same thing).

This approach also correctly solves a number of bugs related to
highlighting (#15176, #12573, #15205).
2021-07-27 14:14:30 -06:00
Thomas Vigouroux ff53c5585f refactor(undo): don't assume curbuf in u_compute_hash 2021-07-09 15:36:07 +02:00
Jan Edmund Lazo 20dc3f1989 vim-patch:8.1.0897: can modify a:000 when using a reference (#14902)
Problem:    Can modify a:000 when using a reference.
Solution:   Make check for locked variable stricter. (Ozaki Kiichi,
            closes vim/vim#3930)
https://github.com/vim/vim/commit/05c00c038bc16e862e17f9e5c8d5a72af6cf7788
2021-06-26 10:19:09 -04:00
snezhniylis 43479f0ad6 extmark: fix deletable nodes in MarkTree sometimes getting skipped
As per #14236, performing extmark cleanup in a certain namespace does
not guarantee removing all the extmarks inside given namespace.
The issue resides within the tree node removal method and results in
a couple of rare edge cases.

To demonstrate what causes this bug, I'll give an example covering one
of the edge cases.

=== AN EXAMPLE ===

   (A)         (B)         (C)         (D)         (E)
---------   ---------   ---------   ---------   ---------
  <0, 1>      <0, 1>      <0, 1>      <0, 1>      <0, 1>
  <0, 2>      <0, 2>      <0, 2>      <0, 2>      <0, 2>
  <0, 3>      <0, 3>      <0, 3>      <0, 3>      <0, 3>
  <0, 4>      <0, 4>      <0, 4>      <0, 4>      <0, 4>
  <0, 5>      <0, 5>      <0, 5>      <0, 5>      <0, 5>
  <0, 6>      <0, 6>      <0, 6>      <0, 6>      <0, 6>
  <0, 7>      <0, 7>      <0, 7>      <0, 7>      <0, 7>
  <0, 8>      <0, 8>      <0, 8>      <0, 8>      <0, 8>
  <0, 9>      <0, 9> *           *    <0, 9>  *   <0, 9>
[0, 10] *   [0, 10]     <0, 9>        [0, 11]     [0, 11]
  [0, 11]     [0, 11]     [0, 11]     [0, 12]     [0, 12]  *
  [0, 12]     [0, 12]     [0, 12]     [0, 13]     [0, 13]
  [0, 13]     [0, 13]     [0, 13]     [0, 14]     [0, 14]
  [0, 14]     [0, 14]     [0, 14]     [0, 15]     [0, 15]
  [0, 15]     [0, 15]     [0, 15]     [0, 16]     [0, 16]
  [0, 16]     [0, 16]     [0, 16]     [0, 17]     [0, 17]
  [0, 17]     [0, 17]     [0, 17]     [0, 18]     [0, 18]
  [0, 18]     [0, 18]     [0, 18]     [0, 19]     [0, 19]
  [0, 19]     [0, 19]     [0, 19]   [0, 20]     [0, 20]
[0, 20]     [0, 20]     [0, 20]

DIAGRAM EXPLANATION

* Every column is a state of the marktree at a certain stage.

* To make it simple, I don't draw the whole tree. What you see are
   2 leftmost parent nodes ([0, 10], [0, 20]) and their children placed
   in order `MarkTreeIter` would iterate through. From top to bottom.

* Numbers on this diagram represent extmark coordinates. Relative
   positioning and actual mark IDs used by the marktree are avoided
   for simplicity.

* 2 types of brackets around coordinates represent 2 different
   extmark namespaces (`ns_id`s).

* '*' shows iterator position.

ACTUAL EXPLANATION

Let's assume, we have two sets of extmarks from 2 different plugins:
  * Plugin1: <0, 1-9>
  * Plugin2: [0, 10-20]

1. Plugin2 calls
    `vim.api.nvim_buf_clear_namespace(buf_handle, ns_id, 0, -1)`
    to clear all its extmarks which results in `extmark_clear` call.

2. The iteration process goes on ignoring extmarks with irrelevant
    `ns_id` from Plugin1, until it reaches [0, 10], entering state (A).

3. At the end of cleaning up process, `marktree_del_itr` gets called.
    This function is supposed to remove given node and, if necessary,
    restructure the tree. Also, move the iterator to the next node.
    The bug occurs in this function.

4. The iterator goes backwards to the node's last child, to put it
    in the place of its deleted parent later. (B)

5. The parent node is deleted and replaced with its child node. (C)

6. Since now this node has 8 children, which is less than
    `MT_BRANCH_FACTOR - 1`, it get's merged with the next node. (D)

7. Finally, since at (B) the iterator went backward, it goes forward
    twice, skipping [0, 11] node, causing this extmark to persist,
    causing the bug. (E)

ANALYSIS AND SOLUTION

The algorithm works perfectly when the parent node gets replaced by
its child, but no merging occurs. I.e. the exact same diagram,
but without the (D) stage. If not for (D), it would iterate to <0, 9>
and then to [0, 11]. So, iterating twice makes sense. The actual problem
is in (C) stage, because the iterator index isn't adjusted and still
pointing to no longer existent node. So my solution is to adjust
iterator index after removing the child node.

More info: https://github.com/neovim/neovim/pull/14719
2021-06-22 10:32:46 +02:00
dm1try 13b8857300 path: add helper for checking a file extension 2020-12-01 10:50:38 +01:00
erw7 6c1e1fe772 test,unit: Change test according to change of bg color response processing
Adjust the test for handle_background_color() according to
bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-11-20 09:26:17 -05:00
Rom Grk 10bf69a43e vim-patch:8.2.1909: number of status line items is limited to 80
Problem:    Number of status line items is limited to 80.
Solution:   Dynamically allocate the arrays. (Rom Grk, closes vim/vim#7181)
https://github.com/vim/vim/commit/8133cc6bf454eb90bb0868f7cf806fce5c0c9fe6

The members of stl_item_T have not been prefixed with stl_ contrary to
the vim patch because the amount of stl_ prefixes on single lines of
code in that region was hurtful to readability.
2020-10-31 19:54:06 -04:00
Justin M. Keyes 59712f6dbe win: avoid duplicate separators in $PATH #12869
Seems like redundant env var separators (";" on Windows) in $PATH can
cause weird behavior. From #7377:

> After some time, system(['win32yank', '-o']) and system('win32yank -o')
> start returning different results: specifically first returns an
> empty string.
>
> 1. $PATH weirdly contains double semicolon followed by path to the
>    “installation directory” (unpacked directory from archive).
> 2. If I run `let $PATH=substitute($PATH, ';;', ';', 'g')` the problem is fixed.

close #7377
ref 224f99b85d
2020-09-08 20:47:22 -07:00