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: #6425fixes: #13489
Signed-off-by: Christian Brabandt <cb@256bit.org>
`: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.
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Also, enable the zip and gzip plugins by default, unless those variables
were not explicitly set by the user.
related: #13413
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>
Strace output, depending on parameters (-ttf this time), can dump both
times and pid:
1038 07:14:20.959262 execve("./e.py", ["./e.py"], 0x7ffca1422840 /* 51 vars */) = 0 <0.000150>
So loose the regexp matching this, so that the above is matched too.
Fixes#13481.
Co-authored-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Janet files are not recognised
Solution: Add filename and shebang detection (without
adding an extra filetype plugin)
Those are used by the Janet language:
http://www.janet-lang.orgcloses: #13400
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
closes: #12990closes: #12992
this partially reverses commit 71badf9 by commenting out the line that
intentionally sets the filetype to an empty string.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Fix the issue introduced by #12557. `:substitute` commands in plugins
need to take into account whether `gdefault` is set or not because
that depends on the user.
closes: #13097
Signed-off-by: Christian Brabandt <cb@256bit.org>
Modified behavior:
- Change default value of g:html_use_input_for_pc from "fallback" to
"none". This means with default settings, only the standards-based
method to make special text unselectable is used. The old method
relying on unspecified browser behavior for <input> tags is now only
used if a user specifically enables it.
- Officially deprecate g:use_xhtml option (in favor of
g:html_use_xhtml) by issuing a warning message when used.
Bugfixes:
- Fix issue #8547: LineNr and other special highlight groups did not
get proper style rules defined when using "hi link".
- Fix that diff filler was not properly added for deleted lines at the
end of a buffer.
Other:
- Refactored function definitions from long lists of strings to use
:let-heredoc variable assignment instead.
- Corrected deprecated "." string concatenation operator to ".."
operator in more places.
Signed-off-by: Christian Brabandt <cb@256bit.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>
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>
Problem: Rexx files may not be recognised
Solution: Add shebang detection and improve disambiguation of *.cls
files
closes: #12951
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Manual pages requested for output may undergo formatting
arranged by some roff-descendant program. Lines longer
than MANWIDTH or COLUMNS or real-estate width of a device
(with support for horizontal scrolling considered) can be
divided at either blank characters and/or at groups of word
characters (syllables) according to supported hyphenation
rules (although page authors are free to disable hyphenation
or prevent particular words from being hyphenated).
Groff‘s manual describes it as follows:
5.1.2 Hyphenation
Since the odds are not great for finding a set of words, for
every output line, which fit nicely on a line without
inserting excessive amounts of space between words, gtroff
hyphenates words so that it can justify lines without
inserting too much space between words. It uses an internal
hyphenation algorithm (a simplified version of the algorithm
used within TeX) to indicate which words can be hyphenated
and how to do so. When a word is hyphenated, the first part
of the word is added to the current filled line being output
(with an attached hyphen), and the other portion is added to
the next line to be filled.
It would be expedient for autoload/dist/man.vim (along with
syntax/man.vim‘s highlighting and ftplugin/man.vim‘s Ctrl-],
\K mappings) to allow for hyphenation of cross-references
to manual pages.
For example,
# Launch Vim [v9.0; patched: 1-1378, 1499] as follows:
MANWIDTH=80 vim --not-a-term +MANPAGER '+Man man' '+/conv(1)' '+norm B'
# Press Ctrl-] with cursor on _m_: "... use man‐
# conv(1) directly."_______________________[^]
#
# (Man v2.11.2)
# Launch Vim as follows:
MANWIDTH=80 vim --not-a-term +MANPAGER '+Man git' '+/config(1)' '+norm B'
# Press Ctrl-] with cursor on _g_: "... in git-
# config(1) for a more ..."_______________[^]
#
# (Git v2.39.2)
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Functions col and cursor count each tab (0x9) as a byte, and
are complementary. On the other hand, the | command motion
takes into consideration how many screen columns a tab does
occupy and may move cursor to a column closer to the start
of line than col would report at that position.
The provided changes prefer the cursor function to the | command.
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
* Dedicate upcoming Vim 9.1 to Bram
Also replace in a few more places Brams email address and mention new
maintainers.
* Remove Bram from any Maintainer role
* runtime: Align Header
* it's mailing list not mailinglist
This is a collection of various PRs from github that all require a minor
patch number:
1) https://github.com/vim/vim/pull/12612
Do not conflate dictionary key with end of block
2) https://github.com/vim/vim/pull/12729:
When saving and restoring 'undolevels', the constructs `&undolevels` and
`:set undolevels` are problematic.
The construct `&undolevels` reads an unpredictable value; it will be the
local option value (if one has been set), or the global option value
(otherwise), making it unsuitable for saving a value for later
restoration.
Similarly, if a local option value has been set for 'undolevels',
temporarily modifying the option via `:set undolevels` changes the local
value as well as the global value, requiring extra work to restore both
values.
Saving and restoring the option value in one step via the construct
`:let &undolevels = &undolevels` appears to make no changes to the
'undolevels' option, but if a local option has been set to a different
value than the global option, it has the unintended effect of changing
the global 'undolevels' value to the local value.
Update the documentation to explain these issues and recommend explicit
use of global and local option values when saving and restoring. Update
some unit tests to use `g:undolevels`.
3) https://github.com/vim/vim/pull/12702:
Problem: Pip requirements files are not recognized.
Solution: Add a pattern to match pip requirements files.
4) https://github.com/vim/vim/pull/12688:
Add indent file and tests for ABB Rapid
5) https://github.com/vim/vim/pull/12668:
Use Lua 5.1 numeric escapes in tests and add to CI
Only Lua 5.2+ and LuaJIT understand hexadecimal escapes in strings. Lua
5.1 only supports decimal escapes:
> A character in a string can also be specified by its numerical value
> using the escape sequence \ddd, where ddd is a sequence of up to three
> decimal digits. (Note that if a numerical escape is to be followed by a
> digit, it must be expressed using exactly three digits.) Strings in Lua
> can contain any 8-bit value, including embedded zeros, which can be
> specified as '\0'.
To make sure this works with Lua 5.4 and Lua 5.1 change the Vim CI to
run with Lua 5.1 as well as Lua 5.4
6) https://github.com/vim/vim/pull/12631:
Add hurl filetype detection
7) https://github.com/vim/vim/pull/12573:
Problem: Files for haskell persistent library are not recognized
Solution: Add pattern persistentmodels for haskell persistent library
closes: #12612closes: #12729closes: #12702closes: #12688closes: #12668closes: #12631closes: #12573
Co-authored-by: lacygoill <lacygoill@lacygoill.me>
Co-authored-by: Michael Henry <drmikehenry@drmikehenry.com>
Co-authored-by: ObserverOfTime <chronobserver@disroot.org>
Co-authored-by: KnoP-01 <knosowski@graeffrobotics.de>
Co-authored-by: James McCoy <jamessan@jamessan.com>
Co-authored-by: Jacob Pfeifer <jacob@pfeifer.dev>
Co-authored-by: Borys Lykah <lykahb@fastmail.com>
Problem: Some "gomod" files are not recognized.
Solution: Check for "go.mod" file name before checking out the contents.
(Omar El Halabi, closes#12462)
Problem: .fs files are falsely recognized as forth files.
Solution: Check 100 lines for something that looks like forth. (Johan
Kotlinski, closes#12219, closes#11988)
Problem: Conflict between supercollider and scala filetype detection.
Solution: Do not check for "Class : Method", it can appear in both
filetypes. (Chris Kipp, closes#11699)
