Problem: filetype: some requirements files are not recognized
Solution: Detect '*-requirements.txt', 'constraints.txt',
'requirements.in', 'requirements/*.txt' and 'requires/*.txt'
as requirements filetype, include pip compiler, include
requirements filetype and syntax plugin
(Wu, Zhenyu, @raimon49)
closes: #14379
Co-authored-by: raimon <raimon49@hotmail.com>
Signed-off-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Signed-off-by: Christian Brabandt <cb@256bit.org>
* runtime(java): Recognise non-ASCII identifiers
Also:
- Remove the already commented out and less general in its
definition javaFuncDef alternative.
- Stop recognising some bespoke {p,trace} debugging API.
Non-ASCII identifiers have been supported from the outset
of the Java language.
> An _identifier_ is an unlimited-length sequence of _Java
> letters_ and _Java digits_, the first of which must be a
> Java letter. An identifier cannot have the same spelling
> (Unicode character sequence) as a keyword . . . Boolean
> literal . . . or the null literal . . .
> . . . . . . . .
> Letters and digits may be drawn from the entire Unicode
> character set . . .
> . . . . . . . .
> A Java letter is a character for which the method
> Character.isJavaLetter . . . returns true. A Java
> letter-or-digit is a character for which the method
> Character.isJavaLetterOrDigit . . . returns true.
> . . . . . . . .
> The Java letters include . . . for historical reasons, the
> ASCII underscore (_) . . . and dollar sign ($) . . .
(Separate syntax tests will be written when particular parts
now touched will have been further improved.)
Reference:
https://javaalmanac.io/jdk/1.0/langspec.pdf [§3.8]
* Take on the maintenance of Java filetype and syntax files
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This is a first-pass attempt to limit matching of Vim9 and legacy-script
comments to the appropriate syntactic contexts.
Vim9-script comments are highlighted at top level in a Vim9-script file,
in all :def functions, and in all :autocmd and :commmand command blocks.
Legacy-script comments are highlighted at top level in a legacy script
file, in all :func functions and in the Vim9-script preamble before the
:vim9script marker command.
Fixes#13047, #11307 and #9587.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Use the standard format for browsefilter labels:
"File Description (*.ext1, *.ext2, *.ext3)"
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add the 'b' flag to 'comments', so that the shebang line is not detected as comment.
Fixes#14101.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Improve matching of line-continuations and interspersed comments.
These are now also matched in multiline syntax command patterns,
dictionary literals, and parenthesised expressions and argument lists.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Note for Neovim Contributors: this is bundled as Vim9 Script. If you want to use this on Neovim, you need to convert the Vim9 scripts to Vim Script or Lua or leave it out.
Signed-off-by: Maxim Kim <habamax@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The "*.*" browsefilter pattern only matches all files on
Windows (Daryl Lee)
Solution: Use "*" to filter on all platforms but keep "*.*" as the label
text on Windows. (Fixes#12685, Doug Kearns)
The *.* browsefilter pattern used to match "All Files" on Windows is a
legacy of the DOS 8.3 filename wildcard matching algorithm. For reasons
of backward compatibility this still works on Windows to match all
files, even those without an extension.
However, this pattern only matches filenames containing a dot on other
platforms. This often makes files without an extension difficult to
access from the file dialog, e.g., "Makefile"
On Windows it is still standard practice to use "*.*" for the filter
label so ftplugins should use "All Files (*.*)" on Windows and "All
Files (*)" on other platforms. This matches Vim's default browsefilter
values.
This commit also normalises the browsefilter conditional test to check
for the Win32 and GTK GUI features and an unset b:browsefilter.
closes: #12759
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Update to the ConTeXt runtime files. Changes:
1. shared syntax files updated with `mtxrun --script interface --vim`
using the latest ConTeXt LMTX.
2. fixed reference to `make` tag in the help file.
3. added `keepend` to mitigate issues with embedded Lua syntax (see
below).
4. the latest revision date of each ConTeXt runtime file has been
updated to the date of this commit.
The issue about embedded Lua was reported by a user:
>Take the following valid ConTeXt file:
> \starttext
> \ctxlua{context("Text generated from Lua.")}
> \ctxlua{context("Another text generated from Lua.")}
> \stoptext
>On my Vim installation (including when I start Vim with `--clean`), the
>closing bracket and curly braces on line 2 are highlighted red and the
>syntax highlighting after that is off.
>I was trying to dig a little bit into what was going on, using the
>`synID()` and `synIDattr()` functions. It appears that the closing
>bracket on line 2 is matched as a `luaParentError` instead of the end
>of the `luaParen` region. Therefore, the `luaParen` region continues
>all the way to the end of the file. The closing curly brace on line
>2 is matched as a `luaError`, the 2nd `\ctxlua` on line 3 as
>`luaParen`, etc.
>This issue doesn't occur in a plain Lua file, where the closing bracket
>is correctly matched as the end of the `luaParen` region. So it seems
>that something goes wrong when the Lua syntax file is included in the
>ConTeXt one.
By adding `keepend`, the right parenthesis for some reason is still
highlighted as a `luaParenError`, but at least the right curly brace
should correctly end the Lua block.
From what I've seen, I think it is very difficult to embed Lua syntax
properly without help from the Lua syntax file (that is, without
patching it). It has global rules such as:
syn match luaParenError ")"
syn match luaError "}"
which make it difficult, if not impossible, to contain Lua syntax
without `keepend` (and its limitations).
Signed-off-by: Lifepillar <lifepillar@lifepillar.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
* runtime update fortran.vim
Add folding for newer features of Fortran
* Runtime Update fortran.vim
Add indent support for newer features of Fortran
* Runtime Update fortran.vim
Add newer features of Fortran to matchit patterns
Signed-off-by: Ajit-Thakkar <142174202+Ajit-Thakkar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This commit updates the Erlang runtime files to be in sync with the
`vim-erlang-runtime` repository. In particular, it adds the following
commit (with some cleanup and simplification afterwards):
6ea8b85bc9
Signed-off-by: Csaba Hoch <csaba.hoch@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The `b:did_ftplugin` guard was set and prevented us from actually sourcing `ftplugin/scala.vim`. Since the latter script also sets the guard properly, we can simply remove the guard here.
Signed-off-by: =?UTF-8?q?Karl=20Yngve=20Lerv=C3=A5g?= <karl.yngve+git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript #1247 (which I found after writing this).
closes: #13562
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
Co-authored-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: wast filetype should be replaced by wat filetype
Solution: start using the official wat filetype name
runtime: rename `wast` filetype to `wat` (Wasm text format)
The problem is the name of the current filetype wast. When the plugin
was initially created, the file extension for Wasm text format was not
fixed and .wast was more popular.
However, recently .wat became the official file extension for
WebAssembly text (WAT) format and .wast is now a file extension for the
unofficial WAST format, which is a superset of .wat for the convenience
to describe the Wasm specification conformance tests.
https://webassembly.js.org/docs/contrib-wat-vs-wast.html
However for now, let's keep using the `wat` filetype even for the .wast
extension, so that we at least do not lose the filetype settings and
syntax highlighting. This can be adjusted later, if it turns out to have
a separate need for.
closes: #13533
Signed-off-by: rhysd <lin90162@yahoo.co.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No filetype support for xcompose files
Solution: Add filetype detection
closes: #13508
Signed-off-by: ObserverOfTime <chronobserver@disroot.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Follow up to 816fbcc26 (patch 9.0.1833: [security] runtime file fixes,
2023-08-31) and f7ac0ef50 (runtime: don't execute external commands when
loading ftplugins, 2023-09-06).
This puts the logic for safe executable checks in a single place, by introducing
a central vim library, so all filetypes benefit from consistency.
Notable changes:
- dist#vim because the (autoload) namespace for a new runtime support
library. Supporting functions should get documentation. It might make
life easier for NeoVim devs to make the documentation a new file
rather than cram it into existing files, though we may want
cross-references to it somewhere…
- The gzip and zip plugins need to be opted into by enabling execution
of those programs (or the global plugin_exec). This needs
documentation or discussion.
- This fixes a bug in the zig plugin: code setting s:tmp_cwd was removed
in f7ac0ef50 (runtime: don't execute external commands when loading
ftplugins, 2023-09-06), but the variable was still referenced. Since
the new function takes care of that automatically, the variable is no
longer needed.
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
* Update Debian runtime files
Add mantic as a supported Ubuntu release and move buster/kinetic to
unsupported.
Add syntax highlighting for deb822sources filetype.
Add debsources ftplugin to set relevant comment options.
Move common version information to shared/debversions.vim
Closes#11934
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: James McCoy <jamessan@jamessan.com>
* Add myself as codeowner for Debian-related runtime files
Signed-off-by: James McCoy <jamessan@jamessan.com>
---------
Signed-off-by: James McCoy <jamessan@jamessan.com>
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: objdump files not recognized
Solution: detect *.objdump files, add a filetype plugin
Added the objdump file/text format
closes: #13425
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Colin Kennedy <colinvfx@gmail.com>
Fix the pattern used by comment-motion mappings to match the start of a
block comment.
Block-comment start lines were being ignored if the previous line
contained a double-quote character anywhere in the line. Line comments
should only be ignored if the previous line is a full-line comment and,
therefore, part of the current block comment.
Signed-off-by: Christian Brabandt <cb@256bit.org>
