3 ms·

Slightly related, I don't like (mostly in OOP langs) when I have something like: import lang.native.api.Something; import third.party.api.Else; ...and

Slightly related, I don't like (mostly in OOP langs) when I have something like: import lang.native.api.Something; import third.party.api.Else; ...and syntax file goes to colorize Something, but Else is perceived as common text. I'm aware of limitations of vim, being text editor and not an IDE, but I'd rather syntax file to ignore the native API then to have me draw visual distinction between native and third-party classes when, effectively, I couldn't care less. The dissimilarity is just visual noise to me. :/

bergmann 11y ago
I agree many of the default Vim syntax highlighting files leave a lot to be desired. You can improve it though and Vim highlighting is actually very powerful. I use a C syntax highlighting improvement plugin to add (among other things) highlighting to operators and function names in calls[1]. You can also quite easily customise syntax highlighting by placing your own additional syntax file in .vim/after/syntax for a language. I use this to add some more custom keywords. You could quite easily add highlight support for ".Else" in an after/syntax file. [1] https://github.com/justinmk/vim-syntax-extra https://github.com/justinmk/vim-syntax-extra
erikb 11y ago
Why is something limited in highlighting because it's a text editor and not an IDE? Highlighting is about text so it's quite a core feature of an editor.
- andrewaylett 11y ago
  Usually because the text editor is limited to regular expression and region matching, while the IDE parses the language into an AST so it knows what each bit actually means.
  - outworlder 11y ago
    Except a text editor can also generate the AST.
    - andrewaylett 11y ago
      What I meant was that the limitation in highlighting is usually due to the limitation in pattern matching. Of course, IDEs usually contain text editors, and they often do highlight using an AST. But that's expensive, both to develop and to run, and especially if you're not going to use the AST for any other IDE-like activity. Pattern-matching is cheap and usually good enough.
      - erikb 11y ago
        Okay, you are not talking about a problem in principle but how it practically is in reality. I don't know if text editors like Sublime/Atom also have that problem but when it comes to vim I can agree with that. Wouldn't wonder if there are some better external highlighters that can be integrated with vim. I heard that people use a vim plugin for using external linters for static analysis of code and spell checking. And just to make sure, we agree that adding a feature like AST based highlighting wouldn't make an editor an IDE, right?
        andrewaylett 11y ago
        Agreed.

bergmann 11y ago

I agree many of the default Vim syntax highlighting files leave a lot to be desired. You can improve it though and Vim highlighting is actually very powerful. I use a C syntax highlighting improvement plugin to add (among other things) highlighting to operators and function names in calls[1]. You can also quite easily customise syntax highlighting by placing your own additional syntax file in .vim/after/syntax for a language. I use this to add some more custom keywords. You could quite easily add highlight support for ".Else" in an after/syntax file. [1] https://github.com/justinmk/vim-syntax-extra https://github.com/justinmk/vim-syntax-extra

erikb 11y ago

Why is something limited in highlighting because it's a text editor and not an IDE? Highlighting is about text so it's quite a core feature of an editor.

andrewaylett 11y ago
Usually because the text editor is limited to regular expression and region matching, while the IDE parses the language into an AST so it knows what each bit actually means.
- outworlder 11y ago
  Except a text editor can also generate the AST.
  - andrewaylett 11y ago
    What I meant was that the limitation in highlighting is usually due to the limitation in pattern matching. Of course, IDEs usually contain text editors, and they often do highlight using an AST. But that's expensive, both to develop and to run, and especially if you're not going to use the AST for any other IDE-like activity. Pattern-matching is cheap and usually good enough.
    - erikb 11y ago
      Okay, you are not talking about a problem in principle but how it practically is in reality. I don't know if text editors like Sublime/Atom also have that problem but when it comes to vim I can agree with that. Wouldn't wonder if there are some better external highlighters that can be integrated with vim. I heard that people use a vim plugin for using external linters for static analysis of code and spell checking. And just to make sure, we agree that adding a feature like AST based highlighting wouldn't make an editor an IDE, right?
      - andrewaylett 11y ago
        Agreed.