[vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
dkearns
Add new filetype detection and syntax file for Algol 68.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19818
Commit Summary
- 4131534 runtime(algol68): Add new syntax file and filetype detection
File Changes
(4 files)
- M runtime/autoload/dist/ft.vim (2)
- A runtime/syntax/algol68.vim (560)
- M runtime/syntax/sh.vim (2)
- M src/Makefile (4)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19818)Thanks Doug, I was actually also going to create a PR for this, so thanks for taking care :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
Thanks.
What is the issue with the many commented out lines in the syntax script? Can you please revert the changes to src/Makefile and runtime/syntax/sh.vim ?
Can you please also update the MAINTAINERS file?
In runtime/syntax/algol68.vim:
> +syn keyword algol68Operator SORT ELEMS
+syn keyword algol68Repeat FOR FROM BY UPTO DOWNTO TO WHILE DO UNTIL OD
+syn keyword algol68Statement PAR BEGIN END EXIT
+syn keyword algol68Struct STRUCT
+syn keyword algol68PreProc VECTOR
+syn keyword algol68Type FLEX HEAP LOC LONG REF SHORT
+syn keyword algol68Type VOID BOOL INT REAL COMPL CHAR STRING COMPLEX
+syn keyword algol68Type BITS BYTES FILE CHANNEL PIPE SEMA SOUND
+syn keyword algol68Type FORMAT STRUCT UNION
+
+ " 20011222az: Added new items.
+syn keyword algol68Todo contained TODO FIXME XXX DEBUG NOTE
+
+ " 20010723az: When wanted, highlight the trailing whitespace -- this is
+ " based on c_space_errors; to enable, use "algol68_space_errors".
+if exists("algol68_space_errors")
those settings should be documented
> @@ -831,7 +831,7 @@ endif
" Arithmetic Parenthesized Expressions: {{{1
"syn region shParen matchgroup=shArithRegion start='[^$]\zs(\%(\ze[^(]\|$\)' end=')' contains=@shArithParenList
-syn region shParen matchgroup=shArithRegion start='\$\@!(\%(\ze[^(]\|$\)' end=')' contains=@shArithParenList
+" syn region shParen matchgroup=shArithRegion start='\$\@!(\%(\ze[^(]\|$\)' end=')' contains=@shArithParenList
that probably does not belong here
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- 2198dd7 runtime(algol68): Add new syntax file and filetype detection
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- 1640d1c runtime(algol68): Add new syntax file and filetype detection
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- aed8698 Replace all groups in patterns with the non-capturing variant \%(...\)
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#19818)@chrisbra, it's too early to be reviewing. As I mentioned in the mail thread it'll take a few days to finalise, I was just trying to put it in motion during the last minutes of the day.
Thanks. What is the issue with the many commented out lines in the syntax script?
These are in the original patch and appear to exclude the non-ASCII operators. I don't think there's any reason these can't eventually be supported. These commented-out lines are also apparent in version 0.2 from fifteen years ago.
There's also what looks like some experimentation with priorities of the operator patterns, tests would be useful to clean this up.
Can you please also update the MAINTAINERS file?
I doubt Janis, from comments in the mail thread, has a GitHub handle so I've just used mine for now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19818)@chrisbra, it's too early to be reviewing.
Ah okay, I'll hold off then, thanks for taking care
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- 7a7d84f Add a rudimentary ftplugin.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- 4fd060a Add a rudimentary ftplugin.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#19818)It looks GNU Algol is going to be utilising the SUPPER stropping regime which this file doesn't support. I don't suppose that's a blocker but it would be nice to support sooner rather than later.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 1 commit.
- d38de11 Fix the radix-16 BITS denotation pattern
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
Janis Papanagnou
I've seen the hex-number fix and the change of the RE grouping parenthesis;
all fine with me.
Is there anything for me to do to complete Vim's syntax support for Algol 68?
There was I mention of testcases, but I'm unsure what to provide since that's
hard to regression test automatically in case of syntax highlighting.
All I could possibly provide (if it's necessary) is probably a file with all the
Algol 68 library prelude functions listed, maybe in more than one variant,
to visually inspect the correct highlighting function. - Please inform me if
there's a demand for that or something else to finish the incorporation.
Thanks!
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von dkearns <vim-dev...@256bit.org>
Gesendet: Dienstag, 31. März 2026 14:56
An: vim/vim
Cc: Push
Betreff: Re: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
—
View it on GitHub<https://github.com/vim/vim/pull/19818/changes/4fd060a4d24979f79e4c0ca581ae5b4aadf98d59..d38de117445507eb56d8d26f071cc591ec8e3bcb?email_source=notifications&email_token=ACY5DGCZHDR6UQBHLR2AND34TO565A5CNFSNUAF7M5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKB2XG2CON52GSZTJMNQXI2LPNYXVA5LMNQSTEMZTGQ2DINZRGY2DGNSCMVTG64TFEUZDGNDGMQYDMMDBGRSDENBZG44WMNZZMU2GGMDDME2TQMLBMU2WENDBMFSGMOJYMQ2TSQLGORSXEJJSGNSDGODEMUYTCNZUGQ2TKMBXMVRDKNTEHBSDENTGGA3TCY3DGU4TCZLDHBSTGYTDMJIHK43IMVSEC5BFGIZTCNZXGQ4TMMJXGE4VA5LTNBSXEJJSGMYTSMZSG2THEZLBONXW5JDQOVZWRJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ>.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19818/before/4fd060a4d24979f79e4c0ca581ae5b4aadf98d59/after/d38de117445507eb56d8...@github.com>
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/19818/before/4fd060a4d24979f79e4c0ca581ae5b4aadf98d59/after/d38de117445507eb56d8d26f071cc591ec8e3bcb%40github.com<https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/19818/before/4fd060a4d24979f79e4c0ca581ae5b4aadf98d59/after/d38de117445507eb56d8d26f071cc591ec8e3bcb%40github.com?utm_medium=email&utm_source=footer>.
Christian Brabandt
On Mi, 08 Apr 2026, Janis Papanagnou wrote:
> Hi Doug,
>
> I've seen the hex-number fix and the change of the RE grouping parenthesis;
> all fine with me.
>
> Is there anything for me to do to complete Vim's syntax support for Algol 68?
>
> There was I mention of testcases, but I'm unsure what to provide since that's
> hard to regression test automatically in case of syntax highlighting.
> All I could possibly provide (if it's necessary) is probably a file with all the
> Algol 68 library prelude functions listed, maybe in more than one variant,
> to visually inspect the correct highlighting function. - Please inform me if
> there's a demand for that or something else to finish the incorporation.
turn this into a syntax test.
Thanks,
Christian
--
Politics is the ability to foretell what is going to happen tomorrow, next
week, next month and next year. And to have the ability afterwards to
explain why it didn't happen.
-- Winston Churchill
Doug Kearns
On Wed, 8 Apr 2026 at 22:03, Janis Papanagnou
<janis_pa...@hotmail.com> wrote:
>
> Hi Doug,
>
> I've seen the hex-number fix and the change of the RE grouping parenthesis;
> all fine with me.
>
> Is there anything for me to do to complete Vim's syntax support for Algol 68?
I have half a dozen other fixes including tests that I'll try to push
by the end of this week for your approval. Then we can merge this and
improve it in the future as desired.
I had a loose plan to reach feature parity with the Emacs mode but
that can wait until later.
Thanks,
Doug
Janis Papanagnou
thanks for your quick replies!
I've just extracted all the ~2500+ keywords (including context duplicates)
from the Algol 68 Genie sources and visually inspected the highlighting.
There's some things I saw that need a fix.
I'm going to fix the missing matches and provide you then with the files
containing the keywords and information about the necessary changes
in the syntax file. - I hope that's okay for you to work with.
BTW, it would be good to be able to work on the version that Doug had
checked in and modified, but I don't know how to get the last version of
the changed source file from github/vim. Hints are welcome. - Thanks.
Regards,
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Christian Brabandt <cbl...@256bit.org>
Gesendet: Mittwoch, 8. April 2026 14:17
An: vim...@googlegroups.com
Betreff: Re: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/adZHdTHMlkZIg7JR%40256bit.org.
Christian Brabandt
On Mi, 08 Apr 2026, Janis Papanagnou wrote:
> Hi Christian and Doug,
>
> thanks for your quick replies!
>
> I've just extracted all the ~2500+ keywords (including context duplicates)
> from the Algol 68 Genie sources and visually inspected the highlighting.
> There's some things I saw that need a fix.
> I'm going to fix the missing matches and provide you then with the files
> containing the keywords and information about the necessary changes
> in the syntax file. - I hope that's okay for you to work with.
>
> BTW, it would be good to be able to work on the version that Doug had
> checked in and modified, but I don't know how to get the last version of
> the changed source file from github/vim. Hints are welcome. - Thanks.
if you go to the PR from Doug https://github.com/vim/vim/pull/19818
and click on the "Files Changed" Tab and then on the file you are
interested, so runtime/syntax/algol68.vim you should reach a link like
this:
https://github.com/vim/vim/pull/19818/changes#diff-32e6cd4c61024033f8a0d77fc69e3518843f255c1a2d8b5e2e8b47e117cd78ca
On the displayed diff for the file you want to see in whole, click on
the little 3-dot menu ("More options") and select "View file". This will
bring you to the complete file from Dougs PR, currently this is:
https://github.com/dkearns/vim/blob/d38de117445507eb56d8d26f071cc591ec8e3bcb/runtime/syntax/algol68.vim
From there, you can click the "Download Raw File" button, to get the
complete syntax file.
Note that the d38de117 is the commit hash from Dougs fork of Vim. If he
pushes a new change, this id will change, so you'll have to redo the
whole exercise to get the latest version.
Best,
Christian
--
On SECOND thought, maybe I'll heat up some BAKED BEANS and watch REGIS
PHILBIN ... It's GREAT to be ALIVE!!
Janis Papanagnou
I deposited information and updated files at http://algol68.gridbug.de/ for inclusion.
The files I uploaded are:
* The file with the Genie/Algol 68 identifiers for incorporation in the test environment
http://algol68.gridbug.de/all_preludes.txt
* The file I retrieved today from github/vim with the recent changes from Doug
http://algol68.gridbug.de/algol68_doug.vim
* The complete algol68.vim file I tested with all changes to fix the observed issues
http://algol68.gridbug.de/algol68_test.vim
* The diff-file between the previous two files containing only the necessary changes
http://algol68.gridbug.de/algol68.vim.diff
If there's anything else you need please let me know. - Thanks!
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Christian Brabandt <cbl...@256bit.org>
Gesendet: Mittwoch, 8. April 2026 17:22
An: vim...@googlegroups.com
Betreff: Re: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
Hi Janis,
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/adZyn43yV%2BAtSn4v%40256bit.org.
Janis Papanagnou
Fixed in http://algol68.gridbug.de/algol68.vim
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Janis Papanagnou <janis_pa...@hotmail.com>
Gesendet: Mittwoch, 8. April 2026 20:04
An: vim...@googlegroups.com
Betreff: AW: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
Janis
Hi Janis,
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/DU0PR02MB10422C82D60C60FC0959D3BBBF35B2%40DU0PR02MB10422.eurprd02.prod.outlook.com.
dkearns
@dkearns pushed 4 commits.
- a5b94a0 Improve number highlighting
- 7da3f09 Merge Janis' updates.
- d7e6c3a Remove Pascal string implementation.
- 927c174 Set 'include' to support read and include pragmats.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
@dkearns pushed 8 commits.
- b3eaf62 runtime(algol68): Add new syntax file and filetype detection
- a780a76 Replace all groups in patterns with the non-capturing variant \%(...\)
- ac1f922 Add a rudimentary ftplugin.
- 019a5a5 Fix the radix-16 BITS denotation pattern
- a3f1b54 Improve number highlighting
- e93067b Merge Janis' updates.
- a3402f6 Remove Pascal string implementation.
- e55a234 Set 'include' to support read and include pragmats.
You are receiving this because you are subscribed to this thread.
Janis Papanagnou
I suggest to enhance one more detail (allow optional space) here:
< syn match algol68Function "\<curses\s*\%(green\|cyan\|red\|yellow\|magenta\|blue\|white\)\%(inverse\)\?\>"
---
> syn match algol68Function "\<curses\s*\%(green\|cyan\|red\|yellow\|magenta\|blue\|white\)\%(\s*inverse\)\?\>"
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von dkearns <vim-dev...@256bit.org>
Gesendet: Dienstag, 14. April 2026 12:54
An: vim/vim
Cc: Push
Betreff: Re: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
@dkearns<https://github.com/dkearns> pushed 8 commits.
* b3eaf62<https://github.com/vim/vim/commit/b3eaf6218a759dcfb4602e6d9f95f298ee21b91f> runtime(algol68): Add new syntax file and filetype detection
* a780a76<https://github.com/vim/vim/commit/a780a7607e05ffd7ac54817f0d623bb143901dfd> Replace all groups in patterns with the non-capturing variant \%(...\)
* ac1f922<https://github.com/vim/vim/commit/ac1f922d3e6ee59d23151404528110ed53b7c60c> Add a rudimentary ftplugin.
* 019a5a5<https://github.com/vim/vim/commit/019a5a5d44cb89a8218073104600a8f82663066a> Fix the radix-16 BITS denotation pattern
* a3f1b54<https://github.com/vim/vim/commit/a3f1b545ee396c26ab30186a608816f676432ad7> Improve number highlighting
* e93067b<https://github.com/vim/vim/commit/e93067ba9ea2bc424c194e92ce398944a85ca298> Merge Janis' updates.
* a3402f6<https://github.com/vim/vim/commit/a3402f65be9a9528b98723ab940b0d05b8550164> Remove Pascal string implementation.
* e55a234<https://github.com/vim/vim/commit/e55a2348861fda28d610a71162a0f771c900d804> Set 'include' to support read and include pragmats.
—
View it on GitHub<https://github.com/vim/vim/pull/19818/changes/927c1745ab79fa10b1df1260877174237ea2714f..e55a2348861fda28d610a71162a0f771c900d804> or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACY5DGH4DXV7QKNCSWEGP2L4VYKG5AVCNFSM6AAAAACW6YPNYGVHI2DSMVQWIX3LMV45UAFHKB2WY3CSMVYXKZLTORIHK43IJZXXI2LGNFRWC5DJN5XDWUDVNRWCGMZUGQ2DOMJWGQZTMQTFMZXXEZJDHEZDOYZRG42DKYLCG44WMYJRGBRDCZDGGEZDMMBYG43TCNZUGIZTOZLBGI3TCNDGIFTHIZLSENSTKNLBGIZTIOBYGYYWMZDBGI4GINRRGBQTOMJRGYZGCMDGG43TCYZZGAYGIOBQGRIHK43IMVSEC5BDGE3TONRRGY2DAMZQKB2XG2DFOIRTCOJTGI3A>.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19818/before/927c1745ab79fa10b1df1260877174237ea2714f/after/e55a2348861fda28d610...@github.com>
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/19818/before/927c1745ab79fa10b1df1260877174237ea2714f/after/e55a2348861fda28d610a71162a0f771c900d804%40github.com<https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/19818/before/927c1745ab79fa10b1df1260877174237ea2714f/after/e55a2348861fda28d610a71162a0f771c900d804%40github.com?utm_medium=email&utm_source=footer>.
Janis Papanagnou
The problem is as follows...
In these testcases
bitswidth
bits width
maxbits
max bits
all but the second one are correctly highlighted as predefined (yellow), where the
second one is blue (first word) and non-highlighted (second word) respectively.
The rule that should cover the first two entries is
syn match algol68Predefined "\<\%(\%(long\s*\)\?long\s*\)\?\%(bits\|bytes\|exp\|int\|real\)\s*width\>"
And according to the (later appearing!) rule
syn match algol68Function "\<\%(bits\|whole\|fixed\|float\|real\)\>"
the function 'bits' is highlighted (blue). - For a standalone 'bits' that's as desired!
So for 'bits width' the first rule seems to be overwritten/invalidated by the second.
And moving the latter rule above the former will "fix" the observable behavior.
But that's IMO not as it should be.
(Apparently there's no return "longest match" principle between different rules.)
A cleaner solution might need to formulate some context dependency?
But I'm not familiar enough with Vim's syntax rules to suggest something here.
Do you have an idea for a clean/cleaner solution to fix that?
Thanks!
Janis
Janis Papanagnou
I extended the test-file I had sent by a variant with spaces in identifiers added.
It can be retrieved here:
http://algol68.gridbug.de/all_preludes_w_sp.txt
With that test-file we can see that there's some issues of the sort reported below
(cf. 'bits' vs 'bits width'); as said, I'm not sure how to best fix these.
(I will provide a list of these identifiers soon as a followup.)
I also found some yet unsupported spaced versions that I intend to fix soon.
(I will send a proposed update soon.)
Thanks.
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Janis Papanagnou <janis_pa...@hotmail.com>
Gesendet: Mittwoch, 15. April 2026 03:37
An: vim...@googlegroups.com
Betreff: AW: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
Thanks!
Janis
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/DU0PR02MB10422086D75D3FB2C22DC2E27F3222%40DU0PR02MB10422.eurprd02.prod.outlook.com.
Janis Papanagnou
The diff to fix some previously unsupported spaced variants:
http://algol68.gridbug.de/2026-04-15_algol68.vim.diff
(Note: the line numbers may not match your actual version.)
The remaining issues are based on the fact that some prefixes
(bits, exp, real, system, blank, newline) are already used on
their own; here I'd need your assistance how to best fix that:
http://algol68.gridbug.de/2026-04-15_blank_issues.txt
(Note: it probably could be fixed by reordering of lines, but
then the semantic grouping would get lost, so that's not
advisable if there's another cleaner solution existing. - I will
have a look at it myself, but that may need some time and
an acceptable outcome is not sure.)
Thanks.
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Janis Papanagnou <janis_pa...@hotmail.com>
Gesendet: Mittwoch, 15. April 2026 10:53
Thanks.
Janis
Thanks!
Janis
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/DU0PR02MB104223DE4CD3CDDCD2618F23EF3222%40DU0PR02MB10422.eurprd02.prod.outlook.com.
Janis Papanagnou
* added a couple more (optional) spaces in some identifiers
* removed consecutive duplicate lines in the file
________________________________________
To identify problems with spaces in identifiers as reported in my previous mail
I extended the test-file I had sent by a variant with spaces in identifiers added.
It can be retrieved here:
http://algol68.gridbug.de/all_preludes_w_sp.txt
[...]
Doug Kearns
<janis_pa...@hotmail.com> wrote:
>
> Doug, I noticed an issue but could not sensibly resolve it. - Maybe you have an idea?
>
> The problem is as follows...
>
> In these testcases
> bitswidth
> bits width
> maxbits
> max bits
> all but the second one are correctly highlighted as predefined (yellow), where the
> second one is blue (first word) and non-highlighted (second word) respectively.
>
> The rule that should cover the first two entries is
> syn match algol68Predefined "\<\%(\%(long\s*\)\?long\s*\)\?\%(bits\|bytes\|exp\|int\|real\)\s*width\>"
>
> And according to the (later appearing!) rule
> syn match algol68Function "\<\%(bits\|whole\|fixed\|float\|real\)\>"
> the function 'bits' is highlighted (blue). - For a standalone 'bits' that's as desired!
>
> So for 'bits width' the first rule seems to be overwritten/invalidated by the second.
> And moving the latter rule above the former will "fix" the observable behavior.
> But that's IMO not as it should be.
> (Apparently there's no return "longest match" principle between different rules.)
> A cleaner solution might need to formulate some context dependency?
> But I'm not familiar enough with Vim's syntax rules to suggest something here.
> Do you have an idea for a clean/cleaner solution to fix that?
taggle separators so changing the priorities will only get us so far.
The best solution, as you suggest, is to try and match the grammar by
:syn-contain-ing tags and using a combination of :syn-nextgroup and
pattern look-aheads. As I'm sure you're aware, these highlighted
groups also wreak havoc with user defined tags, e.g., clear bits.
SUPPER stropping avoids this so things will be simpler there. I'd
like to eventually support all stropping regimes so that even the
ancient code can at least be read comfortably even if none of the
modern compilers support it. However, it appears this file was only
ever intended to support Genie's default UPPER stropping so I think
it's fine to just target that for now. It would be nice if we could
fully support ga68 for the release of GCC 16 but I suspect we're out
of time.
What exactly is the "algol68_traditional" variable attempting to
achieve? I assume the "traditional" refers to the highlighting and
not the language? If so, that would normally be called something like
"algol68_prelude".
I think I've merged all your latest changes.
Thanks,
Doug
Janis Papanagnou
> Latest match wins, by design. See :help :syn-priority
Yeah, I feared so.
Would it be a sensible request to ask for a vim-syntax change here?
(I'm aware that this could cause not only severe efforts but might also
have undesired influences on existing syntax files, unless it's an option
that could be chosen/activated in parallel.)
>> [ context dependency? ]
> Unfortunately there are no simple tag boundaries with whitespace as
> taggle separators so changing the priorities will only get us so far. [...]
Okay. - And I see the hassles and suboptimal workarounds. - So I'd
think that we better accept (for the moment) the infelicities with
that handful of tokens that produce inappropriate highlighting in
the special case of using spaces here.
> SUPPER stropping avoids this so things will be simpler there. I'd
> like to eventually support all stropping regimes so that even the
> ancient code can at least be read comfortably even if none of the
> modern compilers support it. However, it appears this file was only
> ever intended to support Genie's default UPPER stropping so I think
> it's fine to just target that for now.
Yes, and that would also be my suggestion to reach a milestone here.
> It would be nice if we could
> fully support ga68 for the release of GCC 16 but I suspect we're out
> of time.
This is actually a topic I intended to ask once we have the first
Algol 68 syntax-file ready and made publicly available...
How could Algol 68's files syntax highlighting be parameterized to
accept various stopping regimes. (I'm not sure but seem to recall
that the GNU Algol 68 project has also an '.a68' file extension but
uses a different stropping as default.) A solution might get tricky?
> What exactly is the "algol68_traditional" variable attempting to
> achieve? I assume the "traditional" refers to the highlighting and
> not the language? If so, that would normally be called something like
> "algol68_prelude".
Frankly, I cannot tell what that means. It's a remnant from Neville's
original version. - Personally I think the term is misleading, given
that all the matches are included in that section, and that there's
not only the "traditional" features supported but also the features
imported from those third-party libraries and all Genie extensions.
I think a subsequent "0.5" release (that might cover more stropping
regimes or not) could also be cleaned up by more strictly separating
the various feature sets, if possible by technical means (if-sections).
> I think I've merged all your latest changes.
Thanks! - When do you think will the Algol 68 support be available in
the repository for public use?
Janis
Janis Papanagnou
Vim syntax file for Algol 68.
These new operators and new predefined words as shown in this diff are supported:
46a47,48
> " Genie extensions in addition to ROUND and ENTIER
> syn keyword algol68Operator FLOOR CEIL NINT TRUNC FRAC FIX
194c194
< syn match algol68Predefined "\<\%(blank\|formfeed\|newline\|null\|tab\)\s*char\%(acter\)\?\>"
---
> syn match algol68Predefined "\<\%(blank\|formfeed\|newline\|null\|tab\|eof\)\s*char\%(acter\)\?\>"
Thanks!
Regards,
Janis
dkearns
@dkearns pushed 4 commits.
- 7bd3af0 Add new Genie prelude additions (from Janis)
- 5d9c969 Add help file entry
- 4051016 Remove unused groups from :highlight definitions
- 62dde2d Use the Identifier highlight group for prelude identifiers.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
Doug Kearns
<janis_pa...@hotmail.com> wrote:
>
> >> (Apparently there's no return "longest match" principle between different rules.)
>
> > Latest match wins, by design. See :help :syn-priority
>
> Yeah, I feared so.
>
> Would it be a sensible request to ask for a vim-syntax change here?
> (I'm aware that this could cause not only severe efforts but might also
> have undesired influences on existing syntax files, unless it's an option
> that could be chosen/activated in parallel.)
much capability it would add beyond organisational convenience for
matches of predictable length. One can always ask. :)
> >> [ context dependency? ]
>
> > Unfortunately there are no simple tag boundaries with whitespace as
> > taggle separators so changing the priorities will only get us so far. [...]
>
> Okay. - And I see the hassles and suboptimal workarounds. - So I'd
> think that we better accept (for the moment) the infelicities with
> that handful of tokens that produce inappropriate highlighting in
> the special case of using spaces here.
obvious, even in the small Genie test suite.
I think the following would fix it but I may be overlooking some
contexts. Note this won't work with the current test file because of
the column layout.
181c181
< syn match algol68Function
"\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>"
---
> syn match algol68Function "\%([a-z0-9]\s\+\)\@8<!\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>\%(\s\+[a-z0-9]\)\@!"
228c228
> syn match algol68Function "\%([a-z0-9]\s\+\)\@8<!\<\%(bits\|whole\|fixed\|float\|real\)\>\%(\s\+[a-z0-9]\)\@!"
<snip>
> How could Algol 68's files syntax highlighting be parameterized to
> accept various stopping regimes. (I'm not sure but seem to recall
> that the GNU Algol 68 project has also an '.a68' file extension but
> uses a different stropping as default.) A solution might get tricky?
specify the compiler (for prelude highlighting) and the different
stropping regimes.
> > What exactly is the "algol68_traditional" variable attempting to
> > achieve? I assume the "traditional" refers to the highlighting and
> > not the language? If so, that would normally be called something like
> > "algol68_prelude".
>
> Frankly, I cannot tell what that means. It's a remnant from Neville's
> original version. - Personally I think the term is misleading, given
> that all the matches are included in that section, and that there's
> not only the "traditional" features supported but also the features
> imported from those third-party libraries and all Genie extensions.
"algol68_preludes" that takes an array of values in the future to make
this more granular.
> I think a subsequent "0.5" release (that might cover more stropping
> regimes or not) could also be cleaned up by more strictly separating
> the various feature sets, if possible by technical means (if-sections).
>
> > I think I've merged all your latest changes.
>
> Thanks! - When do you think will the Algol 68 support be available in
> the repository for public use?
I think that the declarators using PreProc for highlighting should
probably just use Statement/Keyword. Are you attached to that? This
isn't a blocker, just something I noticed.
The only other issue is the "algol68_no_tabs" feature. If we want to
keep that it should be folded into the "algol68_space_errors" config.
Regards,
Doug
Janis Papanagnou
> > > Unfortunately there are no simple tag boundaries with whitespace as
> > > taggle separators so changing the priorities will only get us so far. [...]
> >
> > Okay. - And I see the hassles and suboptimal workarounds. - So I'd
> > think that we better accept (for the moment) the infelicities with
> > that handful of tokens that produce inappropriate highlighting in
> > the special case of using spaces here.
>
> I had a look at some real code and the errors are quite common and
> obvious, even in the small Genie test suite.
>
> I think the following would fix it but I may be overlooking some
> contexts. Note this won't work with the current test file because of
> the column layout.
With all what I say please keep in mind that I'm not familiar with
the Vim syntax highlighting "programming", so take it with a grain
of salt...
Below code seems to look for context. If you say it doesn't work
with the columnar data in the test suite then I fear it doesn't
qualify as solution since I think we cannot rule out consecutive
function identifiers (i.e. those without arguments and syntactic
parenthesis, for example) in Algol 68 programs.
Pondering about the issue I meanwhile reached the point where I'd
value _correct highlighting in all cases_ as highly desirable. For
that I'd accept the "structuring flaw" and collect all the single
word entities (that appear as prefix before) at top, instrumented
with a comment; so that the implicit "later appearing beats former"
match-rule will address that. - What do you think?
> 181c181
> < syn match algol68Function
> "\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>"
> ---
> > syn match algol68Function "\%([a-z0-9]\s\+\)\@8<!\<\%(\%(\%(long\s*\)\?long\s*\)\|[qd]\)\?\%(sqrt\|cbrt\|curt\|exp\|ln\|log\)\>\%(\s\+[a-z0-9]\)\@!"
> 228c228
> < syn match algol68Function "\<\%(bits\|whole\|fixed\|float\|real\)\>"
> ---
> > syn match algol68Function "\%([a-z0-9]\s\+\)\@8<!\<\%(bits\|whole\|fixed\|float\|real\)\>\%(\s\+[a-z0-9]\)\@!"
>
> <snip>
>
> > How could Algol 68's files syntax highlighting be parameterized to
> > accept various stopping regimes. (I'm not sure but seem to recall
> > that the GNU Algol 68 project has also an '.a68' file extension but
> > uses a different stropping as default.) A solution might get tricky?
>
> I think we'd probably need a combination of config variables to
> specify the compiler (for prelude highlighting) and the different
> stropping regimes.
If you think it's possible to achieve in principle that's good news! :-)
I also think it might not be as bulky as I initially imagined since most
of the identifiers are exempt from stropping; it's mainly only the keywords
of the language and the operators I think, a comparable small data-set.
(It would be perfect if an implicit heuristic could determine the used
stropping variant, or an optional modelines argument for example like
'syntax=algol68(upper)', but I'm probably expecting too much.)
>
> I've pushed some more commits recently. Can you please check them?
I'm unsure about what the following changes will do; could you please
explain:
*algol68_space_errors* trailing white space and spaces before a <Tab>
*algol68_no_trail_space_error* ... but no trailing spaces
*algol68_no_tab_space_error* ... but no spaces before a <Tab>
I'm asking because Algol 68 is very permissible about tabs and spaces
(even in identifiers), and I wouldn't like restrictions.
> I think that the declarators using PreProc for highlighting should
> probably just use Statement/Keyword. Are you attached to that? This
> isn't a blocker, just something I noticed.
Frankly, I'm not sure. (Myself I haven't touched that with my additions.)
The PreProc seems to describe some "technical semantics". Various things
are marked as those; for example language basics like MODE OP PRIO PROC,
specific extensions that have a slight semantic difference to related
keywords like ANDF ORF ANDTH OREL ANDTHEN ORELSE, and a couple other
additions which I cannot really judge about.
Programming Algol 68 I'm (personally) used to have the former two groups
(MODE... and ANDF...) differentiated from other Statements/Keywords.
I'll ponder about that, but for the moment I'd suggest to keep the
existing differentiation.
>
> The only other issue is the "algol68_no_tabs" feature. If we want to
> keep that it should be folded into the "algol68_space_errors" config.
Is this related to my "space-error" question above? - Yet I'm unable to
recognize the implications.
Thanks!
Regards,
Janis
Doug Kearns
<janis_pa...@hotmail.com> wrote:
<snip>
> > I think the following would fix it but I may be overlooking some
> > contexts. Note this won't work with the current test file because of
> > the column layout.
>
> With all what I say please keep in mind that I'm not familiar with
> the Vim syntax highlighting "programming", so take it with a grain
> of salt...
>
> Below code seems to look for context. If you say it doesn't work
> with the columnar data in the test suite then I fear it doesn't
> qualify as solution since I think we cannot rule out consecutive
> function identifiers (i.e. those without arguments and syntactic
> parenthesis, for example) in Algol 68 programs.
represent a single tag?
> Pondering about the issue I meanwhile reached the point where I'd
> value _correct highlighting in all cases_ as highly desirable. For
> that I'd accept the "structuring flaw" and collect all the single
> word entities (that appear as prefix before) at top, instrumented
> with a comment; so that the implicit "later appearing beats former"
> match-rule will address that. - What do you think?
newline` will always have `newline` incorrectly highlighted. This
doesn't happen with my proposed fix.
<snip>
> > I've pushed some more commits recently. Can you please check them?
>
> I'm unsure about what the following changes will do; could you please
> explain:
>
> *algol68_space_errors* trailing white space and spaces before a <Tab>
> *algol68_no_trail_space_error* ... but no trailing spaces
> *algol68_no_tab_space_error* ... but no spaces before a <Tab>
>
> I'm asking because Algol 68 is very permissible about tabs and spaces
> (even in identifiers), and I wouldn't like restrictions.
trailing space (at the end of a line) or tabs with unnecessary leading
spaces as errors. These are usually considered stylistically
undesirable, some people get quite worked up about it. :)
The "algol68_no_tabs" variable adds error highlighting for any tabs so
if it's to be included I think it should be nested under control of
the global "algol68_space_errors" variable as well.
If you didn't add these and aren't interested in the feature we could
just rip it all out. Personally I think this whitespace error
highlighting belongs in a separate plugin that can be conditionally
applied to any syntax file rather than added to each of them
separately.
> > I think that the declarators using PreProc for highlighting should
> > probably just use Statement/Keyword. Are you attached to that? This
> > isn't a blocker, just something I noticed.
>
> Frankly, I'm not sure. (Myself I haven't touched that with my additions.)
>
> The PreProc seems to describe some "technical semantics". Various things
> are marked as those; for example language basics like MODE OP PRIO PROC,
> specific extensions that have a slight semantic difference to related
> keywords like ANDF ORF ANDTH OREL ANDTHEN ORELSE, and a couple other
> additions which I cannot really judge about.
>
> Programming Algol 68 I'm (personally) used to have the former two groups
> (MODE... and ANDF...) differentiated from other Statements/Keywords.
>
> I'll ponder about that, but for the moment I'd suggest to keep the
> existing differentiation.
consider MODE OP PRIO PROC and boolean operators as preprocessor
directives like PRAGMAT. It can be jarring to read if you attach
meaning to the highlighting as I do. We have the Operator highlight
group for the bold word boolean operators like ANDTHEN but there's not
currently enough granularity to assign a definition keyword highlight
group as opposed to the more general Statement or Keyword. It looks,
as with quite a lot of the file, like it was modelled on the ancient
Ruby syntax file but I think it was a mistake there too.
<snip>
Regards,
Doug
Janis Papanagnou
>
> In what context would consecutive whitespace separated identifiers not
> represent a single tag?
Wrong thinking on my side. (Tired and severe lack of coffee probably.)
> > [...]
>
> It doesn't help because a user-defined tag of, say, `my special
> newline` will always have `newline` incorrectly highlighted. This
> doesn't happen with my proposed fix.
You are right. And if your patch addresses that, even better. - Given
your previous comment I also see why the simple test data file wouldn't
work. (I suppose the test file could be syntactically changed to fit,
perhaps by interspersing spurious "X" characters?)
>
> <snip>
>
> > > I've pushed some more commits recently. Can you please check them?
> >
> > I'm unsure about what the following changes will do; could you please
> > explain:
> >
> > *algol68_space_errors* trailing white space and spaces before a <Tab>
> > *algol68_no_trail_space_error* ... but no trailing spaces
> > *algol68_no_tab_space_error* ... but no spaces before a <Tab>
> >
> > I'm asking because Algol 68 is very permissible about tabs and spaces
> > (even in identifiers), and I wouldn't like restrictions.
>
> Sorry, I thought you had added that feature. It just highlights
> trailing space (at the end of a line) or tabs with unnecessary leading
> spaces as errors. These are usually considered stylistically
> undesirable, some people get quite worked up about it. :)
All these 'space_error' things were probably a remnant of Neville's
version; I haven't checked. - To understand the behavior of that
feature or your proposed change I'd have to load the newest version
and play with it. (I never considered processing trailing space.)
Personally I would focus just on the highlighting of the identifiers.
> The "algol68_no_tabs" variable adds error highlighting for any tabs so
> if it's to be included I think it should be nested under control of
> the global "algol68_space_errors" variable as well.
I've no opinion on that, but what you say sounds reasonable.
> If you didn't add these and aren't interested in the feature we could
> just rip it all out. Personally I think this whitespace error
> highlighting belongs in a separate plugin that can be conditionally
> applied to any syntax file rather than added to each of them
> separately.
Sounds sensible what you say. Feel free to change it as you think. :-)
> > > I think that the declarators using PreProc for highlighting should
> > > probably just use Statement/Keyword. Are you attached to that? This
> > > isn't a blocker, just something I noticed.
> >
> > Frankly, I'm not sure. (Myself I haven't touched that with my additions.)
> >
> > The PreProc seems to describe some "technical semantics". Various things
> > are marked as those; for example language basics like MODE OP PRIO PROC,
> > specific extensions that have a slight semantic difference to related
> > keywords like ANDF ORF ANDTH OREL ANDTHEN ORELSE, and a couple other
> > additions which I cannot really judge about.
> >
> > Programming Algol 68 I'm (personally) used to have the former two groups
> > (MODE... and ANDF...) differentiated from other Statements/Keywords.
> >
> > I'll ponder about that, but for the moment I'd suggest to keep the
> > existing differentiation.
>
> The highlight groups are also semantic and it's a bit of a stretch to
> consider MODE OP PRIO PROC and boolean operators as preprocessor
> directives like PRAGMAT.
Yes, sure, preprocessor directives (and similar) are a different thing.
The question I had was whether they need differentiation anyway.
> It can be jarring to read if you attach
> meaning to the highlighting as I do. We have the Operator highlight
> group for the bold word boolean operators like ANDTHEN but there's not
> currently enough granularity to assign a definition keyword highlight
> group as opposed to the more general Statement or Keyword. It looks,
> as with quite a lot of the file, like it was modelled on the ancient
> Ruby syntax file but I think it was a mistake there too.
Well, yet I haven't pondered about it. I was basically just having a
conservative stance here, as said. - What I was concerned about were
primarily the condition-conjunctions that, if I recall correctly, seem
to have a different role and handling than the standard conjunctions;
they are neither operators nor part of or like the IF-construct keywords.
This might make them worthwhile to differentiate them. - Yet I can't say
that I would have a strong feeling about that. - If you think it makes
sense to (as I understand it) streamline the highlighting let's do it.
(If in future we feel it needs differentiation we can open a change
request and then re-discuss it in the light of those new experiences
or insights.)
Regards,
Janis
Janis Papanagnou
http://algol68.gridbug.de/all_preludes_w_sp_X.txt
Syntax for the simple case is:
<blank> X <blank> <identifier-with-spaces> <tab> X <blank> <identifier-without-spaces>
For lines that include abbreviated variants there's two additional "X <identifier>" parts present.
For example:
X cos pi X cospi
X arc cos dg X acosdg X arccosdg X acosdg
Hope that fits. - If you need something different for the tests please let me know.
Thanks.
Regards,
Janis
________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Janis Papanagnou <janis_pa...@hotmail.com>
Gesendet: Samstag, 18. April 2026 00:20
An: vim...@googlegroups.com
Betreff: AW: [vim/vim] runtime(algol68): Add new syntax file and filetype detection (PR #19818)
> > [...]
>
> It doesn't help because a user-defined tag of, say, `my special
> newline` will always have `newline` incorrectly highlighted. This
> doesn't happen with my proposed fix.
You are right. And if your patch addresses that, even better. - Given
your previous comment I also see why the simple test data file wouldn't
work. (I suppose the test file could be syntactically changed to fit,
perhaps by interspersing spurious "X" characters?)
[...]
dkearns
@dkearns pushed 3 commits.
- 92a252f Match PLUSTO symbolic operator
- 59c0804 Highlight `ln poch` spelling of `lnpoch`.
- e117e39 EXPERIMENTAL: Define tag boundaries with pattern lookarounds
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
Doug Kearns
<janis_pa...@hotmail.com> wrote:
>
> I've modified the test file as outlined in my previous mail. It's available here:
>
> http://algol68.gridbug.de/all_preludes_w_sp_X.txt
>
> Syntax for the simple case is:
> <blank> X <blank> <identifier-with-spaces> <tab> X <blank> <identifier-without-spaces>
>
> For lines that include abbreviated variants there's two additional "X <identifier>" parts present.
>
> For example:
> X cos pi X cospi
> X arc cos dg X acosdg X arccosdg X acosdg
>
> Hope that fits. - If you need something different for the tests please let me know.
Could you please have a look at the latest commits and let me know if
you have any essential changes you want included? Otherwise, I think
this is ready to merge.
At some stage I'll look at adding compiler plugins for Genie and GNU.
I noticed there's some keywords in Genie's `a68g/a68g-keywords.c` that
are not matched but that can be done at a later date.
Thanks,
Doug