[vim/vim] Recognize ABB RAPID as filetype rapid (WIP) (PR #10104)
Patrick Meiser-Knosowski
On the long run I would like to have my indent, syntax and maybe (parts of) ftplugin distributed with vim. This is the first step towards this.
ABB RAPID is the programing language of these industrial robots.
Wikipedia lists RAPID as well.
Currently I distribute my files here and here.
There are a few more filename extensions to cover (*.sys, *.mod and *.cfg). All of them overlap with other file types. RAPID is easily recognized from file content.
This work in progress pull request serves the purpose to get critique about the implementation, before adapting what I did to *.prg to the remaining *.sys, *.mod and *.cfg.
I also fixed two apparent minor typos in runtime/autoload/dist/ft.vim.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/10104
Commit Summary
- 9cda658 Recognize *.prg as RAPID according to content
File Changes
(3 files)
- M runtime/autoload/dist/ft.vim (31)
- M runtime/filetype.vim (11)
- M src/testdir/test_filetype.vim (47)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #10104 (9cda658) into master (3ad2090) will decrease coverage by
80.00%.
The diff coverage isn/a.
@@ Coverage Diff @@ ## master #10104 +/- ## =========================================== - Coverage 82.01% 2.00% -80.01% =========================================== Files 167 152 -15 Lines 187584 170700 -16884 Branches 42269 39498 -2771 =========================================== - Hits 153848 3430 -150418 - Misses 21387 166575 +145188 + Partials 12349 695 -11654
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | ? |
|
| huge-gcc-none | ? |
|
| huge-gcc-testgui | ? |
|
| huge-gcc-unittests | 2.00% <ø> (ø) |
|
| linux | 2.00% <ø> (-81.95%) |
⬇️ |
| mingw-x64-HUGE-gui | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/libvterm/src/rect.h | 0.00% <0.00%> (-96.78%) |
⬇️ |
| src/sha256.c | 0.00% <0.00%> (-96.45%) |
⬇️ |
| src/libvterm/src/parser.c | 0.00% <0.00%> (-95.91%) |
⬇️ |
| src/gui_gtk_f.c | 0.00% <0.00%> (-94.72%) |
⬇️ |
| src/crypt_zip.c | 0.00% <0.00%> (-94.12%) |
⬇️ |
| src/vim9compile.c | 0.00% <0.00%> (-92.42%) |
⬇️ |
| src/debugger.c | 0.00% <0.00%> (-92.23%) |
⬇️ |
| src/eval.c | 0.10% <0.00%> (-92.18%) |
⬇️ |
| src/blob.c | 0.00% <0.00%> (-91.93%) |
⬇️ |
| src/cmdexpand.c | 0.00% <0.00%> (-91.74%) |
⬇️ |
| ... and 153 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update 3ad2090...9cda658. Read the comment docs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
In FTprg() it's better to check g:filetype_prg first. It's consistent with most other uses of g:filetype* (but not all).
It's not clear to me why you use "mod_prg_sys" as the default argument value. Perhaps it can just be an empty string?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
In FTprg() it's better to check g:filetype_prg first. It's consistent with most other uses of g:filetype* (but not all).
Sure. Same as for KRL.
It's not clear to me why you use "mod_prg_sys" as the default argument value. Perhaps it can just be an empty string?
*.mod, *.prg and *.sys are the file name extensions for programs, they all look the same at the top of the file. Then there are also *.cfg files, which look different. Maybe it will clear up when I (start to) cover the other file names.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
@KnoP-01 pushed 2 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
Oh, I guess I don't need to merge master so often. I will optimize my workflow for future pull requests.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > In FTprg() it's better to check g:filetype_prg first. It's
> > consistent with most other uses of g:filetype* (but not all).
> Sure. Same as for KRL.
>
> > It's not clear to me why you use "mod_prg_sys" as the default
> > argument value. Perhaps it can just be an empty string?
> *.mod, *.prg and *.sys are the file name extensions for programs, they
> all look the same at the top of the file. Then there are also *.cfg
> files, which look different. Maybe it will clear up when I (start to)
> cover the other file names.
but never matches the condition. Looks like dead code.
--
A fool must search for a greater fool to find admiration.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
We have redundant code now in src/testdir/test_filetype.vim. Since RAPIDs *.prg, *.mod and *.sys do look the same, the tests are the same except the file name extension. I don't know if I should make a function for this.
Apart from that it's ready to merge, I think.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
@KnoP-01 pushed 2 commits.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
All go.mod files I find start like so:
module example.com/hello
or so
module example
None I find look have a . at the end of the first line. The pattern for Lambda Prolog looks for
module modulename.
I hope that is ok. If not I can move go.mod up in the detection, so that any file named go.mod is recognized as gomod.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
I still see that IsRapid() is either called with no argument or with "cfg". The only value that is recognized is "cfg". Thus I still don't see why it has a default value of "mod_prg_sys". The default value can just be an empty string, so that the check for "cfg" works as intended.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
the mod_prg_sys suppose to be descriptive. There is no logical difference If the default is an empty string. I understand you prefer it that way.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
OK, looks good now. Let me also add g:filetype_cfg for consistency.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Hmm, commit command was messed up, did another one to get the tag at least.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Patrick Meiser-Knosowski
If you want all RAPID files to have a filetype overrule variable, then g:filetype_sys is still missing. Should I add this one and include g:filetype_sys and g:filetype_cfg in the tests?
On the other hand, I think g:filetyhpe_cfg is not necessary, the pattern for RAPID cfg files is pretty distinct. Same for *.sys files. There will be no MSDOS Batch file which is false positively caught by the RAPID pattern.
Thank you so much for including this! I will clean up the indent files next, add some tests and create a pull request for them.
One question. Is folding intended to be inside the syntax file or the ftplugin? I ask because I would like to use foldmethod=syntax if syntax is on and foldmethod=marker if not in KRL.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.