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

On Nov 25, 2013 9:23 PM, "Marc Weber" <marco-oweber@gmx.de> wrote:
>
> > 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.

I mainly omit mappings changing core commands behavior too much from the original. It does not mean there are no mappings I am too used to. What you suggest is very different: start with vim -u NORC and you get no mappings and trapped in a language you are not familiar with. More, unlike VimL there is exactly no requirement on having other languages. Thus if with vim I can use my own vimrc or, at least, input some mappings by hand, what can I do if there is and *may be no* python? Not all interpreters work on the same OS+arch combination vim does.

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

Bram is creating some language which may or may not fit, do not remember the details right now though.

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

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