Problem: When running tests on a source tree checked out with git for
Windows, the old tests fail.
The Git for Windows installer installs git with core.autocrlf=true by
default. If you check out, build, and run tests using such a git, the
old test .ok files will likely fail because they use CRLF line endings.
Tests on Windows assume that .ok files use LF line endings, and
appropriately convert the line endings of related files. This
assumption breaks down when .ok files use CRLF.
Solution: Force LF line endings for old test .ok files in the
.gitattributes file. Related to that, we've stopped explicitly
specifying line endings when checking out in CI, since this is no longer
necessary.
While at it, also fix a typo in the comment of the gitattributes file.
closes: #19086
Signed-off-by: Muraoka Taro <koron.kaoriya@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Current CI Windows testing does not test Vim using ConPTY.
Solution: Added a configuration to enable ConPTY to the Windows matrix.
This configuration suppresses the installation of winpty,
allowing testing with ConPTY.
Since the fixes made at the end of last year, all tests now pass when
using ConPTY, just like when using winpty. ConPTY itself is stable on
recent versions of Windows, so there are no longer any reasons not to
test it.
closes: #19066
Signed-off-by: Muraoka Taro <koron.kaoriya@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Ruby 4.0 is broken upstream in Vim. Once that's fixed, we can remove
this.
This should not be in a release build, as it's a temporary measure to
unblock CI.
Problem: No indention support when editing bpftrace files.
Solution: Add indention settings based on cindent with custom options.
closes: #19030
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: bicep filetype used for 2 bicep file types
Solution: Detect *.bicepparam files as bicep-param filetype, include
new bicep-params and bicep filetype plugin
(Scott McKendry)
The bicep language server handles parameter files differently than
regular bicep files. Treating them the same at the editor level leads to
false positive diagnostics in the editor.
References:
Bicep Language Constants:
- 51392d32ca/src/Bicep.Core/LanguageConstants.cs (L23)
VS Code Extension definition:
- 51392d32ca/src/vscode-bicep/package.json (L47)closes: #19026
Signed-off-by: Scott McKendry <me@scottmckendry.tech>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No syntax highlighting for bpftrace files.
Solution: Add basic syntax rules, which cover comments, keywords, strings,
numbers, macros and probes (the bpftrace specific items).
closes: #18999
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Christian Brabandt <cb@256bit.org>
macOS-13 is retired from GitHub hosted runners, so we need to remove it.
With this change we also no longer have any x86 runners in the mix.
While GitHub Actions provides a macos-15-intel runner, it will be
deprecate in near future as well, so it's not really worth setting it
up. If we care to test MacVim on x86 machines we may have to find
alternative solutions, but for now it should be ok as we haven't seen
any issues with universal builds for a long time.
Problem: filetype: Erlang lexical files are not recognized
Solution: Detect *.xrl files as leex filetype, include syntax and
filetype plugins (Jon Parise).
leex is the lexical analyzer generator for Erlang. Its input file format
follows a section-based structure and uses the `.xrl` file extension.
This initial work includes file detection, an ftplugin (which inherits
the Erlang configuration), and a syntax definition.
Reference:
- https://www.erlang.org/doc/apps/parsetools/leex.html
related: #18819closes: #18832
Signed-off-by: Jon Parise <jon@indelible.org>
Signed-off-by: Csaba Hoch <csaba.hoch@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Separate out the building step into a separate group. This makes the
tests output more concise to read when a test has failed and we want to
look at the logs.
The test_artifacts action (which we use to upload artifacts when a test
has failed) relies on parsing the CI matrix values to generate a unique
artifact name. However, in #1559 we switched to using a reusable
workflow instead, which no longer uses a matrix inside the composable
workflow. We could simply make a matrix with only one item in it to
satisfy the test_artifact action but that seems a bit overkill. Instead,
just modify it so we manually pass in the preferred artifact name
instead which also gives us more flexibility in the naming. It does mean
future upstream merges may cause conflicts.
And include "extra" Linux elements to further disambiguate
archive names.
The current naming of artifacts is inadequate when it comes
to files whose differing name-parts only come from array
values, as arrays are not automatically converted to string.
For example, both artifacts for failing "socketserver" and
"no_x11" CI jobs will claim the same name, and whichever job
finishes last is allowed to overwrite another matching name
artifact.
Reference:
https://docs.github.com/en/actions/reference/workflows-and-actions/expressions#functionscloses: #18556
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Generating prototype files does not work on all platforms
Solution: Rework prototypes generation using python instead of cproto,
enable it in CI to test it for each PR (Hirohito Higashi).
closes: #18045
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: KerML and SysML files are not recognized
Solution: Detect *.kerml as kerml filetype, detect *.sysml as sysml
filetype, include a kerml and sysml filetype plugin
(Daumantas Kavolis)
closes: #18476
Signed-off-by: Daumantas Kavolis <daumantas.kavolis@sensmetry.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: Not all PKL files are recognized
Solution: Detect *.pcf as pkl filetype, detect using the pkl-lsp://
protocol as pkl filetype, include PKL syntax script
(Jan Claußen)
This adds basic syntax support for the new PKL language by Apple.
What works:
- Shebang support
- Comment support
- Integers (decimal, hex, octal and binary) support
- Floating point support including exponentials
- Basic datatype support
- Unicode escape delimiters
- Escape code support
- String interpolation
- Support up to five pounds for custom delimiters
- Folding of multi-line comments and blocks
What doesn't work:
The language heavily uses parameterized type declarations, which can get
very complex. It is very hard to highlight this properly. There is
official Tree-sitter support for this. Since it is hard to pull this off
in a vim syntax file, I opted for basic support of the data types.
References:
https://github.com/apple/pkl-pantryfixes: #18271closes: #18274
Signed-off-by: Jan Claußen <jan.claussen10@web.de>
Signed-off-by: Christian Brabandt <cb@256bit.org>
> The macOS 13 runner image will be retired by December 4th, 2025.
Update to the macos-15-intel runner.
It seems that runners ending with "large" require an enterprise plan, so
macos-15-intel is the only other available macOS Intel runner.
Also both macOS 15 runners now use Xcode 16.4 by default, so there is no
need to install it manually.
closes: #18471
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: kitty config files are not recognized
Solution: Detect */kitty/*.conf as kitty filetype, include a syntax
script (Shawon).
closes: #18280
Signed-off-by: Shawon <mdmoinulhossainshawon@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This merges the upstream socket client server code. For now it is
disabled to prevent it from interferring with MacVim's own client server
implementation.
Problem: CI is not run with clang 21
Solution: Update CI to v21, fix a few warnings that are uncovered when
using clang 21 (Philip H)
closes: #18142
Signed-off-by: Philip H. <47042125+pheiduck@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
