Hacker News Reader

Comment by synthmeat | Hacker News Reader

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. :/

View on HN

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

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.

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.

Except a text editor can also generate the AST.

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.

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?

Agreed.

Reply on news.ycombinator.com