[dlikhten]

I started using VIM 3 months ago. And now I can't fucking use anything else. The ergo gains of vim are so rediculously awesome, and NOBODY else does VI right, other than VI. Even Sublime 2, it has vintage mode but its not VI, it's missing most of the magic. This is why we need a new VI. One that has better syntax highlighting, one that can use something other than VIMScript AND STILL support all of vimscript. Something with better graphics like what Sublime 2 has, but still lose nothing of VIM's power.

Tough project, but needs to be done.

[pka]

This [1] is an attempt to do just that. I haven't really looked at the source, but from what I gather it is a way to combine keymaps, actions, parsers, and syntax grammars however you like. There's also a vi mode (don't know how complete) and I think the modular approach they've taken is the way to go.

Also, it is written in Haskell.

[1] http://www.haskell.org/haskellwiki/Yi

[slurgfest]

urgh; I feel that the last thing we need is to couple our editors even more strongly to the flavors of the month (and 500mb+ of dependencies). I wish these things were more ecumenical...

[eridius]

How is Haskell a flavor of the month?

For the record, the first commit to the Yi project was 8 years ago. This isn't some flash in the pan project.

[slurgfest]

We are speaking in a context set by vi/vim (remember, that was the jumping off point for promoting yi here).

If you cannot think of at least one language which is older and a better common denominator than Haskell (both at the binary level and at the interface presented to programmers)... I don't know what to say.

What actual reason do I have for switching from vim to yi? Just because it's written in Haskell and that obviously makes it better, or what?

[eridius]

I... have absolutely no idea what you're trying to say. It's not worth ever using a language if there's an older one around? Are you saying you don't want to switch editors unless the new one is written in FORTRAN?

[pka]

Yes, we should write our editors in assembler.

[ibotty]

it's not that haskell is bloated...

[bcrescimanno]

Better syntax highlighting? For what language? In all honesty, it's not super-tough to write your own syntax for any language. If you do it, release it on github and others will probably be willing to contribute.

Vim has support for scripting against Python and Ruby in addition to VimScript.

Better graphics? For what purpose? For displaying text?

[Ralith]

> it's not super-tough to write your own syntax for any language

Spoken like somebody who's never tried to parse C++.

[slurgfest]

Parsing C++ isn't required if all you are doing is syntax coloring.

vim has a fully configurable syntax highlighting system; its behavior is not hard-coded. So if you have a problem with how C++ is highlighted then you don't need to petition for the developers to patch or rewrite vim for you.

You can tweak the related configuration. And it's true that it's really not that hard to make your own new configuration to do this. Because you aren't compiling the code, you are only highlighting it according to your own tastes.

[Ralith]

Any syntax highlighting scheme which does not leverage a language parser is woefully limited. If you're satisfied with a scattering of heuristics, great; you'll find satisfaction in a much wider set of tools. Myself, I want syntax highlighting that doesn't break as soon as I do something unusual, and which is capable of more than identifying keywords.

Given that vim is open source, I'm not sure why you think hard-coded syntax highlighting would be impossible for me to modify.

[slurgfest]

Mind the context: the guy said there needed to be a "new VI" to have "better" syntax highlighting (whatever specifically he meant by that). You broke in to emphasize how tough it is to parse C++, which is true, but not entirely relevant; the person you replied to was simply pointing out that it's easy to reconfigure vim's syntax highlighting to almost any requirement. Which is true, by the way.

It appears that you are preoccupied with hard-coded construction of ASTs for some dialect of C++ inside your editor. I never suggested it could not be done. But, this is a different issue.

However, I really don't think many people need that when the facilities for configuring syntax highlighting are so good. The existing system has allowed vim to support a crazy number of languages and have fresh support for languages quite quickly after they start to be used.

If you like vim, and you want something SPECIFIC to be fixed about its C++ highlighting (not just a general complaint that you feel it is 'woefully limited' because it isn't based on hardcoded static analysis for C++) ... then don't waste time on doubt. Just try it. Make your own highlighting script and see if it works to a usable level. If it does not, then you know, and not just because of some a priori principle that syntax highlighting is useless unless it is based on an AST generated by your compiler toolchain or something.

If you really did have any practical reason to believe that the existing syntax highlighting facility was totally unsuitable for more than a handful of people... maybe it would be interesting to have some way of plugging in external modules of some kind to provide ASTs for specific languages. (Because I think the idea of making my text editor totally coupled to a specific hard-coded implementation of a parser for a particular language sucks really bad; but if you don't think that, then maybe you just want to buy a C++ IDE and be done with it)

[Ralith]

What makes you think I want anything hard-coded?

[lloeki]

Ruby is quite a beast too, in that parsing Ruby is easy, except for a bunch of wicked corner cases which makes parsing exactly like ruby(1) tricky.

[bcrescimanno]

Ha! Fair enough!

[adiM]

Well, vim cannot syntax highlight markdown. Period.

There are multiple markdown syntax highlighting plugins, but none of them work most non-trivial markdown features (a paragraph indented by four spaces after a list item is a regular paragraph not a code block; extend the same analogy to multiple nested lists...).

[insertnickname]

>Vim has support for scripting against Python and Ruby in addition to VimScript.

and Lua, Perl Tcl and Racket.

[ibotty]

replying to every person to point out, that syntax highlighting _is_ pretty complete in vim. yes, it is.

... but, what about microformats (not the w3c-flavor) in other files. say: any in-place templating language (php), code blocks in markdown, etc.

that would be really great. it does not stop at syntax highlighting though. i'd really like my erlang mode in markdown code blocks :D.

[sigzero]

Vim has support for scripting in Scheme and Lua as well I think.

[slurgfest]

vim already supports things other than vimscript (e.g. perl, ruby, python). Depends on what your OS packages provide, or compile it yourself (really not too hard).

I don't know how the syntax highlighting could be better since it is already fully scriptable and allows 256 colors, etc.

So what is it that needs to be done? All I get from this is that you think vim should have "better graphics like what Sublime 2 has". So I ask sincerely: what is the actual essential functionality required and why would it demand a 'new VI' rather than a patch or plugin?

If you can formulate what is needed more specifically then it's more likely that you can fix it yourself or at least have a chance of enlisting someone else to do it.

[bitcracker]

> The ergo gains of vim are so rediculously awesome

For instance?