Problem: Opening a zipfile from HTTP gives an empty buffer.
Solution: Ensure that the magic bytes check does not
skip protocol processing.
Also use readblob() and remove commented out lines.
closes: vim/vim#15396c4be066817
Co-authored-by: Damien <141588647+xrandomname@users.noreply.github.com>
This is a breaking change which will make refactor of typval and shada
code a lot easier. In particular, code that would use or check for
v:msgpack_types.binary in the wild would be broken. This appears to be
rarely used in existing plugins.
Also some cases where v:msgpack_type.string would be used to represent a
binary string of "string" type, we use a BLOB instead, which is
vimscripts native type for binary blobs, and already was used for BIN
formats when necessary.
msgpackdump(msgpackparse(data)) no longer preserves the distinction
of BIN and STR strings. This is very common behavior for
language-specific msgpack bindings. Nvim uses msgpack as a tool to
serialize its data. Nvim is not a tool to bit-perfectly manipulate
arbitrary msgpack data out in the wild.
The changed tests should indicate how behavior changes in various edge
cases.
This was wrongly included as of patch 1c6734291295bf8aa39577840b40bb
because apparently I messed up the use of git apply :/
52f2ff0363
Co-authored-by: Christian Brabandt <cb@256bit.org>
This change does the following 3 things:
1) non need to quote the file to be extracted
The zipfile plugin used to quote and fnameescape() the path to the
file to be extracted. However testing with unzip showed, that while this
works on Linux on Windows you shall not escape the blanks in filenames.
As long as the pathname is properly quoted, this words on Linux and
Windows.
2) reset shellslash (MS-Windows only)
When shellslash is set, filenames to the zip archive will be forward
quoted. However since the filename is eventually handed over to the
unzip command, we need to make sure to use native paths so that the
command will understand what file to open. Therefore, if shellslash is
set (and the shell is cmd.exe), replace any forward slashes by the
expected backslashes
3) style:
Use tabs for the Header, remove a few comments in the s:Escape() and
zip#read() functions
fixes: vim/vim#149981c67342912
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(netrw): prefer scp over pscp
regression introduced in ce2ad9ffd79fe6b2307cd46b9
The current logic is a bit funny, in that it checks for an executable of
scp, then pscp and if neither exists, it uses: scp :/
Anyway, let's fall back to the logic used before the above commit.
related: vim/vim#1473943f2edc096
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(doc,netrw): update "Last Change header", remove trailing whitespace
Update Last-Change Header for netrw and doc/indent.txt, fix a trailing
whitespace in indent.txt and make CI happy.
8fad5d5887
Co-authored-by: Christian Brabandt <cb@256bit.org>
The benefit of this is that users only pay for what they use. If e.g.
only `vim.lsp.buf_get_clients()` is called then they don't need to load
all modules under `vim.lsp` which could lead to significant startuptime
saving.
Also `vim.lsp.module` is a bit nicer to user compared to
`require("vim.lsp.module")`.
This isn't used for some nested modules such as `filetype` as it breaks
tests with error messages such as "attempt to index field 'detect'".
It's not entirely certain the reason for this, but it is likely it is
due to filetype being precompiled which would imply deferred loading
isn't needed for performance reasons.
Problem: Modula2 filetype support lacking
Solution: Improve the Modula-2 runtime support, add additional modula2
dialects, add compiler plugin, update syntax highlighting,
include syntax tests, update Makefiles (Doug Kearns)
closes: vim/vim#6796closes: vim/vim#811568a8947069
- Luaify the detection script:
- Split the `(*!m2foo*)` and `(*!m2foo+bar*)` detection into two Lua patterns,
as Lua capture groups cannot be used with `?` and friends (as they only work
on character classes).
- Use `vim.api.nvim_buf_call()` (ew) to call `modula2#SetDialect()` to ensure
`b:modula2` is set for the given bufnr.
- Skip the syntax screendump tests. (A shame as they test some of the detection
from `(*!m2foo+bar*)` tags, but I tested this locally and it seems to work)
- Port the synmenu.vim changes from Vim9 script. (Also tested this locally)
- (And also add the missing comma for `b:browsefilter` from earlier.)
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
runtime(netrw): Decode multibyte percent-encoding filename correctly (vim/vim#13842)
Use `printf("%c")` instead of `nr2char()` to handle '%xx' as a byte.
Closevim/vim#137872357765304
Co-authored-by: K.Takata <kentkt@csc.jp>
runtime(netrw): Fix handling of very long filename on longlist style (vim/vim#12150)
If there is a file with a very long filename (longer than
g:netrw_maxfilenamelen), and if g:netrw_liststyle is set to 1, no space
is inserted between the filename and the filesize and the file cannot be
opened because of this.
E.g.:
```
$ echo hello > 12345678901234567890123456789012 # 32 bytes: OK
$ echo hello > 123456789012345678901234567890123 # 33 bytes: not OK
$ echo hello > 1234567890123456789012345678901234 # 34 bytes: not OK
$ echo hello > こんにちは # multibyte filename
$ LC_ALL=C.UTF-8 vim . --clean --cmd "set loadplugins" --cmd "let g:netrw_liststyle=1"
```
Then, it will be shown like this:
```
" ============================================================================
" Netrw Directory Listing (netrw v171)
" /cygdrive/c/work/netrw-test
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../ 0 Mon Mar 13 19:25:16 2023
./ 0 Mon Mar 13 19:44:58 2023
12345678901234567890123456789012 6 Mon Mar 13 19:29:43 2023
12345678901234567890123456789012346 Mon Mar 13 19:32:40 2023
1234567890123456789012345678901236 Mon Mar 13 19:29:49 2023
こんにちは 6 Mon Mar 13 19:30:41 2023
```
If the length of the filename is 32 bytes, there is a space between the
filename and the filesize. However, when it is longer than 32 bytes, no
space is shown.
Also, you may find that the filesize of the multibyte named file is not
aligned.
After this patch is applied, the filelist will be shown like this:
```
" ============================================================================
" Netrw Directory Listing (netrw v171)
" /cygdrive/c/work/netrw-test
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../ 0 Mon Mar 13 20:49:22 2023
./ 0 Mon Mar 13 21:12:14 2023
1234567890123456789012345678901 10000 Mon Mar 13 20:57:55 2023
12345678901234567890123456789012 6 Mon Mar 13 19:29:43 2023
123456789012345678901234567890123 6 Mon Mar 13 19:29:49 2023
1234567890123456789012345678901234 6 Mon Mar 13 19:32:40 2023
1234567890123456789012345678901234567 10000 Mon Mar 13 21:03:23 2023
1234567890123456789012345678901234567890 10000 Mon Mar 13 21:03:36 2023
123456789012345678901234567890123456789012 10000 Mon Mar 13 21:03:59 2023
1234567890123456789012345678901234567890123 10000 Mon Mar 13 21:03:45 2023
1234567890123456789012345678901234567890123456 5 Mon Mar 13 21:08:15 2023
12345678901234567890123456789012345678901234567 10 Mon Mar 13 21:05:21 2023
こんにちは 6 Mon Mar 13 19:30:41 2023
```
Now we have 32 + 2 + 15 = 49 characters for filename and filesize.
It tries to align the filesize as much as possible.
The last line that has multibyte filename is also aligned.
Also fixed the issue that the file list is not shown correctly when
g:netrw_sort_by is set to 'size' and g:netrw_sizestyle is set to 'h' or
'H'.
8750e3cf81
Co-authored-by: K.Takata <kentkt@csc.jp>
runtime(netrw): expand $COMSPEC without applying 'wildignore' (vim/vim#13542)
When expanding $COMSPEC and a user has set :set wildignore=*.exe
netrw won't be able to properly cmd.exe, because it does not ignore the
wildignore setting.
So let's explicitly use expand() without applying the 'wildignore' and
'suffixes' settings to the result
closes: vim/vim#13426cb0c113ddc
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(tar): improve the error detection
Do not rely on the fact, that the last line matches warning, error,
inappropriate or unrecognized to determine if an error occurred. It
could also be a file, contains such a keyword.
So make the error detection slightly more strict and only assume an
error occured, if in addition to those 4 keywords, also a space matches
(this assumes the error message contains a space), which luckily on Unix
not many files match by default.
The whole if condition seems however slightly dubious. In case an error
happened, this would probably already be caught in the previous if
statement, since this checks for the return code of the tar program.
There may however be tar implementations, that do not set the exit code
for some kind of error (but print an error message)? But let's keep this
check for now, not many people have noticed this behaviour until now, so
it seems to work reasonably well anyhow.
related: vim/vim#6425fixes: vim/vim#134893d37231437
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(dist): Make dist/vim.vim work properly when lacking vim9script support (vim/vim#13487)
`:return` cannot be used outside of `:function` (or `:def`) in older Vims
lacking Vim9script support or in Neovim, even when evaluation is being skipped
in the dead `:else` branch.
Instead, use the pattern described in `:h vim9-mix`, which uses `:finish` to end
script processing before it reaches the vim9script stuff.
b2a4c110a5
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
