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>
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>
ftplugin/rmd.vim:
- Set 'commentstring' dynamically according to code region.
syntax/rmd.vim:
- Include syntax highlighting of fenced languages dynamically.
- Add conceal char for line break.
Signed-off-by: Christian Brabandt <cb@256bit.org>
This is a followup to 816fbcc262 (patch
9.0.1833: [security] runtime file fixes)
It basically disables that external commands are run on loading of the
filetype plugin, **unless** the user has set the `g:plugin_exec = 1`
global variable in their configuration or for a specific filetype the
variable g:<filetype>_exec=1.
There are a few more plugins, that may execute system commands like
debchangelog, gitcommit, sh, racket, zsh, ps1 but those do at least
do not run those commands by default during loading of the filetype plugin
(there the command is mostly run as convenience for auto-completion or
to provide documentation lookup).
closes: #13034
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Tim Pope <vim@tpope.org>
In case the current directory is present as valid $PATH entry, it is OK
to call the program from it, even if vim curdir is in that same
directory.
(Without that patch, for instance, you will not be able to open .zip
files while your current directory is /bin)
closes: #13027
Signed-off-by: Christian Brabandt <cb@256bit.org>
While making changes to the ruby ftplugin, slightly change the exepath()
conditional from patch 9.0.1833 and move it after the :cd invocation.
closes: 12981
closes: 12994
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Tim Pope <code@tpope.net>
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: runtime files may execute code in current dir
Solution: only execute, if not run from current directory
The perl, zig and ruby filetype plugins and the zip and gzip autoload
plugins may try to load malicious executable files from the current
working directory. This is especially a problem on windows, where the
current directory is implicitly in your $PATH and windows may even run a
file with the extension `.bat` because of $PATHEXT.
So make sure that we are not trying to execute a file from the current
directory. If this would be the case, error out (for the zip and gzip)
plugins or silently do not run those commands (for the ftplugins).
This assumes, that only the current working directory is bad. For all
other directories, it is assumed that those directories were
intentionally set to the $PATH by the user.
Signed-off-by: Christian Brabandt <cb@256bit.org>
dkearns
Christian Brabandt
Luca Saccarola
Melker Ulander
Maxim Kim
Tim Pope
George Guimarães
Lifepillar
Ajit-Thakkar
Csaba Hoch
Paulo Moura
Karl Yngve Lervåg
Julien Marrec
rhysd
ObserverOfTime
D. Ben Knoble
James McCoy
Colin Kennedy
Gregory Anders
Enno
Jakson Alves de Aquino
Eisuke Kawashima
Anton Sharonov
Anton Sharonov (ant0sha)