Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken character literal highlighting #132

Open
nhatanh002 opened this issue Nov 19, 2021 · 2 comments
Open

Broken character literal highlighting #132

nhatanh002 opened this issue Nov 19, 2021 · 2 comments

Comments

@nhatanh002
Copy link

When a character literal contains a "region" start pattern ('(','[','{','"'), everything after the start pattern is interpreted as a contained region, and consequently breaks syntax highlighting. After further investigation, the regex used to match character literal is actually incorrect according to the Haskell 2010 language specification (https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-200002.6), which means most valid character literals aren't highlighted at all, and the \u<code> pattern while not being a legal character in Haskell, is correctly highlighted.

For example, '[' here breaks everything after it: ) is not highlighted as a delimiter - like its matching (, and showVol is not highlighted as it should've been, like getVol above:
2021-11-20T01:31:47,889252436+07:00

With the addition of a ' and a ], they "close" the bogus "open" token [ and ', and everything is highlighted correctly again:
2021-11-20T01:33:18,134189766+07:00

The character literal highlighting is not even correct!
2021-11-20T01:47:43,282991015+07:00

This is how the plugin defines the way haskellCharacter should've been highlighted, notice that the "characters" inside of the single quotes are highlighted as if they weren't character literals instead, e.g. A is highlighted as a type, 9 as a number, + as an operator, z as normal text:
2021-11-20T01:49:22,307889855+07:00

nhatanh002 added a commit to nhatanh002/haskell-vim that referenced this issue Nov 19, 2021
  (See neovimhaskell#132)
  When a character literal contains a "region" start pattern
  ('(','[','{','"'), everything after the start pattern is interpreted as
  a contained region, and consequently breaks syntax highlighting. After
  further investigation, the regex used to match character literal is
  actually incorrect according to the Haskell 2010 language specification
  (https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-200002.6),
  which means most valid character literals aren't highlighted at all,
  and the \u<code> pattern while not being a legal character in Haskell,
  is correctly highlighted.

  This commit tries to remedy the above issues.
@maurges
Copy link

maurges commented Jan 4, 2022

Oh god it's not just me. The character literals used to work fine, then I took some time off haskell, and now they're broken for both vim and neovim.

@maurges
Copy link

maurges commented Jan 4, 2022

Yep, just tested it and it's a regression somewhere between neovim 0.4.1 and neovim 0.6.0. It's got something to do with matching \<', and it's the reason I couldn't fix your MR of this issue. Going to open an issue in neovim.

Update: wow, it's more weird. Apparently \<' was always broken, but something in neovim 0.4.1 fixes matching of chars for haskell specifically. Maybe it's the remnants of default highlighting, I don't know. Here is a small test:

" 'a'
syn match haskellChar "\<'[^'\\]'"
highlight def link haskellChar String

If you open it in nvim and :source %, you will see that 'a' is not highlighted.

Update2: my bad, to make this test file work for both nvim 0.4.1 and 0.6.0 you need to add setlocal iskeyword+='. The search for reproducing continues..

Update3: using \< in a :syn remembers the value of iskeyword at the time of creating the :syn. Since iskeyword is set in "after/ftplugin", it seems it applies too late for syntax definitions.

Update4: I conclude that it broke in neovim 0.6.0 exactly, since in 0.5.1 it works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants