Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

> Making some interpreter standard not only risks slowing user down, but also
> makes it close to impossible to use other people's vim.
Well - that's already the case - and I don't care. People remap :; in
normal mode only (to reduce stress) and the like.

But starting up Vim is fast, adding conditional code in ~/.vimrc
like if $VIM_CONFIG == "me" ... seems to be reasonable.

VAM/vundle/pathogen support having plugins in directories. So this
is no problem at all.

> There are other concerns though: C is portable (with lots of macros, but
> they are primary isolated), there is a way to use a C function from nearly
> anywhere (e.g. like with python ctypes, etc), there is a big bunch of
> things that have C bindings and sometimes are even written in C and it does
> not forbid any optimization you may come up with.
That's why I want something "D/Haskell/disciple/urweb" like which can
compile down to C, and which knows about "things close to C" so that you
can replace pieces only without having to rewrite all code at once.
And that language does not exist yet to my knowledge.

> I do not understand the statement about reusing syntax highlighting though:
> you either write in JS, something that compiles to it (C *does*) or forget
> about the idea AFAIK (assuming you are talking about browser js).
Ideally syntax is easy: start parsing a document, build up an ast,
compile ast down to something like char 1-20 red, char 21 to 50 blue and
so on.

Thus the interface would look like:

parse_line(parser_state, new_line, more_lines_if_needed){
return {new_parses_state: ..., highlighting_of_this_line}
}

unless you need lookahead or such ..

I can easily imagine writing the parser in a functional language, then
compiling it down to either JS or C.

But yes - getting this right would be a lot of work but eventually worth
trying.

> I would suggest limiting options to only languages that work on all
> kernel+architecture combinations debian works.
:) That's why if a new language was choosen it should be able to target
C, so that compatibility is not affected much.

But I'd like to abstract over lists, hashes, ... without having to start
type casting or write hacky preprocessor macros.

Ideally I'd like to have something which represents vim behavior, then
just tell it "compile to C using C strings" or "compile to C using
arrays as strings so that we can represent \0 bytes".

Something like ocaml/urweb modules, but when instantiating those modules
allow additional arguments such as "memory-management-system: ref-count,
boehm, other"

Yes - this is still uncertain and just an idea.

If somebody knows a project which tries to achieve this let me know.

Marc Weber

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.