Re: breaking with history ?

Marc Weber <marco-oweber@gmx.de> a écrit:
> Happening: I asked at vim-dev about how to implement collections.
> And I was quite surprised - that people are aware of the issue, that C
> does not provide collections. Switiching language would mean "huge step"
> So I wonder which other "huge steps" should be evaluated. (This does not
> mean that any such step will be taken - however having a list of things
> which could be changed would be nice).
>
> I have written up a small list:
> http://vim-wiki.mawercer.de/wiki/vim-development/breaking-with-the-past.html
>
> But its not long enough to to justify a fork. Fixing is still the way to
> go IMHO.
>
> So if you have small things which "always bothered" you - which should
> be set differently by default, add them to the list. Also huge features
> are welcome :)

I agree with most of the items in your list; in particular, although
"Vim is just an editor" is an at least historically important part of
its philosophy, I really wouldn't mind if it became a way of life or a
kitchen sink.

But my remarks are about VimL, which I happen to like, although I
think the following could make it better:


* Organize functions in libraries – just dictionaries, really. So, for
instance, "stridx()", "strlen()", "strpart() would be
"string.index()", "string.length()", "string.part()", whereas
functions dealing with buffers would be in a "buffer" dictionary, etc.
That would make the entire language much clearer (and easier to
extend).


* Remove the one-command-per-line restriction, so you can write things
like:

while foo if bar TRUE else break endif endwhile

It might be necessary (or clearer) then to mark the end of a
condition, as in:

while foo do if bar then TRUE else break endif endwhile


* Get rid of ":call" for functions. Shouldn't it be possible for Vim
to distinguish ":foo" (a command) from ":bar()" (a function) thanks to
the parentheses?


* Allow things like "let a, b = 1, 2" or "return 1, 2" instead of
using lists to do so.


* Allow changing a variable's type without ":unlet":

for x in ["foo", ["bar"]]
...
" Mandatory, for the time being:
unlet x
endfor


* A simple numeric ":for" would be nice.


* Allow functions and Ex commands to start with a lowercase letter.
Yes, that is dangerous, but not much more than:

noremap j :qall!<CR>

And that'd be quite useful; there is room enough for new names, and
sometimes I'd like to override the default behavior of a command. Of
course, that'd require that you'd be able to retrieve the original
meaning of a command, perhaps with something like ":original"? For
instance, I use this command:

command! -nargs=? -complete=help Help tab help <args>

I'd gladly redefine it as:

command! -nargs=? -complete=help Help original help <args>
command! -nargs=? -complete=help help tab Help <args>

(so opening help in a new tab is the default behavior). Perhaps
":original" should be as simple as:

original Help help

so you don't have to bother about arguments, etc.


Now perhaps the best solution is to replace VimL with Lua or Ruby or,
as most people seem to favor, Python, but I don't think that's going
to happen soon, if ever, and in the meantime I'll be happy with a
"VimLim" – "VimL improved"! (The items above are my ideas of how to
improve it, of course, and might not be an improvement at all.)

That was my 2¢, or rather my list of itchy things in that otherwise
awesome beast.

Best,
Paul

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