- Add a syntax file update to Neville Dempsey's long-serving version
- Add a new rudimentary ftplugin
- Add filetype detection
Changes to the syntax file include:
- improved prelude, number and symbol highlighting
- prelude highlighting tests
- updated boiler plate
Note that these runtime files currently target Algol 68 Genie employing
the default UPPER stropping regime. Support for GNU Algol 68 should
also be usable with the UPPER stropping regime, although somewhat less
complete. Full support for the SUPPER stropping regime in GNU Algol 68
is also planned.
closes: #19818
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Janis Papanagnou <janis_papanagnou@hotmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: some Beancount files are not recognized
Solution: Detect *.bean files as beancount filetype
(Bruno Belanyi)
closes: #20037
Signed-off-by: Bruno Belanyi <bruno@belanyi.fr>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: ghostty config files are not recognized
Solution: Detect ghostty configuration files as ghostty filetype,
include a simple ghostty filetype plugin (Bez Hermoso)
closes: #20002
Co-authored-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Bez Hermoso <me@bez.dev>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Before 71fd19d7ac this function went
through a `:!` command on all platforms, so it needed special escaping for `#` and
others. After that commit it doesn't go through that path on unix
platforms. Then with 48581f2ba9 this
escaping was re-added on unix and it's needs since it goes through
`sh -c`, but it should not have the extra escaping specific to `:!`.
Specifically my original broken command is:
```
PATH=/usr/bin:/bin VIMRUNTIME=~/dev/vim/runtime ./src/vim -u NONE -c 'call dist#vim9#Open("https://github.com/keith/dotfiles/blob/7bce9f5c697df6a549cf97bf5606d8b639e5bf5a/vimrc#L19")'
```
Where the `#L19` ends up being opened as `%5C#L19`. But I verified this
case still works as well:
```
PATH=/usr/bin:/bin VIMRUNTIME=~/dev/vim/runtime ./src/vim -u NONE -c 'call dist#vim9#Open("foo bar.txt")'
```
Which is what would otherwise break if we weren't doing any shell
escaping on unix.
closes: #19996
Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(vimball): still path traversal attacks possible
Solution: block Windows driver letter paths (Yasuhiro Matsumoto)
The path traversal check in vimball#Vimball() did not reject file
names starting with a Windows drive letter (e.g. "C:/foo"). Backslashes
are normalized to forward slashes earlier, so UNC paths are caught by
the leading-slash check, but absolute drive-letter paths slipped
through and could write outside of g:vimball_home on Windows.
Add a "^\a:" check next to the existing "^/" check, and cover it with
a new test.
closes: #19989
Signed-off-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(tar): missing path traversal checks in tar#Extract()
Solution: Add check for leading slash, however gnu tar should already
detect this (q1uf3ng)
tar#Extract() did not check for ../ sequences or absolute paths,
unlike zip#Extract() which was patched in recent commits. Add the
same checks: ../ (relative traversal), leading slash (Unix), drive
letter and UNC/leading slash (Windows).
closes: #19981
Signed-off-by: q1uf3ng <q1uf3ng@protone.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: not all Bitbake include files are recognized
Solution: Enhance the file detection logic and consider varflags
(Martin Schwan)
closes: #19983
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Signed-off-by: Christian Brabandt <cb@256bit.org>
zip#Write(): the Windows path check did not match a single leading
slash (/path), which resolves to the current drive root on Windows.
Simplify the regex to match any leading slash or backslash.
zip#Extract(): add absolute path checks for both Unix and Windows,
matching the existing checks in zip#Write().
closes: #19976
Signed-off-by: q1uf3ng <glna9@protonmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(tar): but with dotted path
Solution: Do not strip everything after the first dot
(Aaron Burrow)
tar#Extract was getting the extensionless basename by
stripping away everything starting with the leftmost
dot. So if a directory had a dot or the file had an
'extra' dot then the code did the wrong thing. For
example, if it was given:
/tmp/foo.bar/baz.tar.gz
Then it would treat /tmp/foo as the extensionless
basename, but it actually should have grabbed:
/tmp/foo.bar/baz
This patch fixes the issue by instead looking at the
rightmost dot(s).
This bug was discovered by ChatGPT 5.4. I wrote the
patch and tested vim.
closes: #19930
Signed-off-by: Aaron Burrow <burrows@fastmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: patch 9.2.0325: runtime(tar): bug in zstd handling
Solution: use correct --zstd argument, separated from other arguments,
rework testing framework (Aaron Burrow).
The tar.vim plugin allows vim to read and manipulate zstd archives,
but it had a bug that caused extraction attempts to fail.
Specifically, if the archive has a .tar.zst or .tzst extension, then
the code was generating invalid extraction commands that looked like
this:
tar --zstdpxf foo.tar.zst foo
When they should be like this:
tar --zstd -pxf foo.tar.zst foo
This patch changes the flag manipulation logic so that --zstd isn't
glued to pxf.
The labor for this change was divided between ChatGPT 5.4 and me.
ChatGPT 5.4 identified the issue (from a code scan?), and I wrote
the patch and tested vim.
related: #19930
Signed-off-by: Aaron Burrow <burrows@fastmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(tar): some issues with lz4 support
Solution: Fix bugs (see below) (Aaron Burrow)
The tar plugin allows users to extract files from tar archives that are
compressed with lz4. But, tar#Extract() builds malformed extraction commands
for lz4-compressed tar archives. This commit fixes three issues in that code.
The first affects archives with a .tlz4 extension and the other two affect
archives with .tar.lz4 extension (but one of these is symmetric to the issue
that .tlz4 archives had).
(1) When trying to extract .tlz4 archives the command created by
tar#Extract looked like this:
tar -I lz4pxf foo.tlz4 foo
This isn't right. It should be something like this:
tar -I lz4 -pxf foo.tlz4 foo
This was happening because tar.plugin is just substituting on the
first - in "tar -pxf". This works fine if we just add a simple flag for
extraction (eg, z for .tgz), but for lz4 we need to add "-I lz4".
I don't believe that there is an obvious good way to fix this without
reworking the way the command is generated. Probably we should collect
the command and flags separately and the flags should be stored in a
set. Then put everything together into a string just before issuing it
as an extraction command. Unfortunately, this might break things for users
because they have access to tar_extractcmd.
This patch just makes the substitution a little bit more clever so that it
does the right thing when substituting on a string like "tar -pxf".
(2) .tar.lz4 extractions had the same issue, which my patch fixes in
the same way.
(3) .tar.lz4 extractions had another issue. There was a space missing
in the command generated by tar#Extract. This meant that commands
looked like this (notice the lack of space between the archive and output
file names):
tar -I lz4pxf foo.tar.lz4foo
This patch just puts a space where it should be.
Finally, I should note that ChatGPT 5.4 initially identified this issue
in the code and generated the test cases. I reviewed the test cases,
wrote the patch, and actually ran vim against the tests (both with and
without the patch).
closes: #19925
Signed-off-by: Aaron Burrow <burrows@fastmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: dist#vim9#Open() fails to open files with spaces on Linux
because Launch() splits the command string. Also,
background GUI viewers (e.g., xdg-open) crash with SIGPIPE
when Vim destroys the default job_start() IO pipes.
Solution: Use job_start() with 'sh -c' to let the POSIX shell parse
the shellescaped quotes safely. Set 'in_io', 'out_io', and
'err_io' to 'null' to completely detach the background
process and prevent pipe crashes. Unify the Launch()
execution block across all operating systems.
closes: #19928
fixes: #19916
Signed-off-by: Furkan Sahin <furkan-dev@proton.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The vimball plugin needs some love
(syndicate)
Solution: Clean-up, refactor and update the plugin,
in particular, catch path traversal attacks
This change does the following
- Clean up Indentation and remove calls to Decho
- Increase minimum Vim version to 7.4 for mkdir()
- Use mkdir() consistently
- Update Metadata Header
- Remove check for fnameescape()
- Catch path traversal attacks
- Add vimball basic tests
- Remove mentioning of g:vimball_mkdir in documentation
closes: #19921
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(zip): may write using absolute paths
(syndicate)
Solution: Detect this case and abort on Unix, warn in the documentation
about possible issues
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: not all ObjectScript routines are recognized
Solution: Also detect "%RO" and "iris" patterns inside *.rtn files
(Hannah Kimura)
closes: #19873
Signed-off-by: Hannah Kimura <hannah.kimura@intersystems.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(vimgoto): not correctly escaping the filenames
Solution: Use fnamescape() (Michał Majchrowicz)
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(typeset) does not escape the detected directory
Solution: Use fnameescape() (Michał Majchrowicz)
fyi @lifepillar
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime(context) does not escape the detected log file
Solution: Use fnameescape() (Michał Majchrowicz)
fyi @lifepillar
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: cto files are not recognized
Solution: Detect *.cto as concerto filetype (Jamie Shorten)
Add filetype detection for the Concerto Modelling Language. Concerto
is a schema language by the Accord Project for defining data models
used in smart legal contracts and business networks.
Reference:
Language spec: https://concerto.accordproject.org
Tree-sitter grammar: https://github.com/accordproject/concerto-tree-sittercloses: #19760
Signed-off-by: Jamie Shorten <jamie@jamieshorten.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: With zsh, executing :!nohup xdg-open url >/dev/null 2>&1 &
does not launch the browser. This occurs presumably because
gvim/zsh cleans up background processes in a non-interactive
session too quickly.
Solution: Use job_start() with "stoponexit" set to an empty string.
This bypasses the shell entirely (fixing the zsh issue)
and ensures the browser process is not killed when Vim exits.
On Linux, shellescape() is removed as job_start() in list
mode handles special characters natively.
fixes: #19594
Signed-off-by: Christian Brabandt <cb@256bit.org>
- ':!' is not stable, so use system() to get more consistent behaviour.
- Only warns when using 'pwsh'.
- Remove trailing spaces.
closes: #19370
Co-Authored-by: @lxhillwind
Signed-off-by: Mao-Yining <mao.yining@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: `gf` in Vim script fails if multiple target files exist.
Solution: Use globpath() which returns an array.
In a Vim script, `gf` on `some#func()` will jump to `autoload/some.vim`.
In this case, if there are multiple `autoload/foo.vim`s in
'runtimepath', `globpath(&runtimepath, path)` will return multiple
paths, separated by newlines.
As a result, the second and subsequent paths will be executed as
commands in `autoload/vimgoto.vim:195`, causing an error.
This change fixes this issue by making the result of `globpath()` an
array.
closes: #19379
Signed-off-by: thinca <thinca@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: search() is used to check for the message from tar that
indicates leading slashes found in the tar archive, or to
check for the leading slashes themselves. However, if
'nowrapscan' is in effect these searches are limited to the
last line and don't find any results. This causes the warning
message from tar to be seen in the buffer, the "Path Traversal
Attack Detected" message to be omitted, and editing actions
can fail. This can be seen, for example, when editing
src/testdir/samples/evil.tar.
Solution: Use the 'w' flag for search() (Kevin Goodsell)
closes: #19333
Signed-off-by: Kevin Goodsell <kevin-opensource@omegacrash.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Remove `--nonstopmode` because (a) ConTeXt always stops anyway, and (b)
`--nonstopmode` disables SyncTeX unconditionally. Add `--paranoid`,
which prevents the command to descend to `..` and `../..`.
Pass the typesetting command only the name of the input file rather than
its full path, as that is more compatible with ConTeXt's syncing
mechanism.
closes: #19323
Signed-off-by: Lifepillar <lifepillar@lifepillar.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: skhd files are not recognized
Solution: Detect .skhdrc and skhdrc as skhd filetype,
include a syntax and filetype plugin, add syntax tests
(Kiyoon Kim)
Add syntax highlighting for skhd (simple hotkey daemon for macOS)
configuration files. Includes filetype detection for skhdrc and
.skhdrc files.
Reference:
- https://github.com/asmvik/skhdcloses: #19235
Signed-off-by: Kiyoon Kim <kiyoon@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Yasuhiro Matsumoto
Christian Brabandt
Doug Kearns
Bruno Belanyi
Bez Hermoso
Keith Smiley
q1uf3ng
Martin Schwan
Aaron Burrow
Furkan Sahin
Hannah
Jamie Shorten
Guillaume Barbier
przepompownia
Ivan Pešić
Thomas Dupuy
tris203
Mao-Yining
Stefan VanBuren
thinca
Kevin Goodsell
Amelia Clarke
Lifepillar
Arkissa
Mateo Gjika
Kiyoon Kim