breaking with history ?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

breaking with history ?

MarcWeber
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 :)

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Steve Litt
On Sat, 08 Jun 2013 23:20:22 +0200
Marc Weber <[hidden email]> wrote:


> I have written up a small list:
> http://vim-wiki.mawercer.de/wiki/vim-development/breaking-with-the-past.html

I looked at that list, and speaking for myself, not one of those
features would be worth a huge amount of coding/recoding, with the
resulting bugs and possible loss of existing features.

> But its not long enough to to justify a fork. Fixing is still the way
> to go IMHO.

I'd prefer a fork to trying to do any of those things in the existing
Vim, if those things would require large amounts of coding or recoding.
At least that way, I'd still have "Vim Classic" to depend on, and if
there are kewl new features I want, then I could use "New Vim" to get
those features.

> So if you have small things which "always bothered" you

Yeah, VimL sucks hard. But I'd rather have to be required to learn and
use that arcane language than significantly disrupt the existing Vim.

A centralized, easy to read documentation of VimL would be just about
as good as replacing VimL with something else.

Vim can already use Python, Ruby and Lua in place of VimL. The problem
is that the distro builders don't uniformly put those things in.

One word about the feature concerning threads and Netbeans
imitation: Geez, Vim's an editor, not a way of life. If I wanted a way
of life, I'd already be using Emacs.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
Hi Steve,

Please don't get me wrong. I'm trying to collect all ideas so that the
simplest way to move into the near future can be found.

I also depend on VimL. And I've also documented on that wiki page that
I think fixing is the way to go. However before getting started I'd like
to know whether there are other features people may want to have which I
should keep in mind.

> python
Its not only a problem that "python is not packaged" by default.
You cannot write multi threaded applications (reading stdin/out)
of foreign tools easily. This is very common today. Examples are
sbt, haskell yesod live reload mode etc.

If you know a sane way to implement such without depending on "on idle"
features.

I'm not talking about "turning Vim into a kitchen sink", but eventually
about moving into a direction so that APIs will happen which allow
plugins to do so.

That extension such as "netbeans" exist arleady show that Vim basically
failed that time (for whatever reasons).

I want to follow the linux philosophy: One tool should be good at one
task. But make it easy for other tools to use this one tool.

This is basically a "try to understand" before getting started request.

If not much replies happen, the better. That then means that everything
is fine, and that getting small features in will do it.

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Robert R. Melton
Marc--

Lots of people in the Vim community have thought about, maybe even started writing vim clones (I am guilty of this).  There are lots of partial vim emulators embedded into other editors (vintage mode in Sublime, ViEMU for visual studio, many many more).  These clones are considered "good" or "bad" based on if they support the X features you require.  If they do, they seem fine, but as soon as they don't, they land on the trash heap, because the editor you spend your day in is the land of muscle memory.  

Vim has thousands of features, each individual may only use a few, but they aren't the SAME few.  Hence if you a vim clone, you would have to start by matching the feature set.  Don't assume because you put a low value on feature X that the community agrees with your assessment.  Once you have the giant feature list (every vim feature, maybe less some compatibility ones since you are breaking with the past), you could start to bucket them into core and extension buckets. 

In theory, with a good small core and a decent light language as the default (maybe forced only) extension language (something like Lua, not something like Python), you might be able to rebucket a lot of features that currently live in core vim into extensions that ship with your clone.  But the level of effort and the time investment is absolutely massive.

I think an aggressive attempt to fix the flaws you see in Vim is worth more than trying to fork or rewrite. 

--
Robert Melton 

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Davido
In reply to this post by MarcWeber
Marc Weber <[hidden email]> wrote, on sam 08 jun 23:20 :

> 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 :)

Improving the builtin pager would be great. I often use the "less" pager
from the shell, and it's really nice to be able to search text or filter
the lines of the file/stdin.  This is a feature I miss in vim.

--
Regards,

Davido

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
You know that vim can read from stdin?:

  cat file | vim - ?

So what is really missing to make you happy?

Also using goole and "wikia" as keyword you'll find pages like:
http://vim.wikia.com/wiki/Using_vim_as_a_syntax-highlighting_pager

does this come close?

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Paul Isambert
In reply to this post by MarcWeber
Marc Weber <[hidden email]> 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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Davido
In reply to this post by MarcWeber
Marc Weber <[hidden email]> wrote, on mer 12 jun 11:38 :

> You know that vim can read from stdin?:
>
>   cat file | vim - ?
>
> So what is really missing to make you happy?

Well, my previous post was confusing.  To be more specific, I'm talking
about the internal vim pager, used when ex commands produce output. For
instance, when you run :

:browse oldfiles
:digraph
...

and you have a lot of output. It would be great to search for some string
inside it, or to filter :

:messages

using a keyword (the name of a function, plugin, ...). Even the completion
list (when you hit C-D) can generate a lot of output sometimes. There
are probably a lot of other cases where this feature would be useful.

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
> Well, my previous post was confusing.  To be more specific, I'm talking
> about the internal vim pager, used when ex commands produce output. For
> instance, when you run :

Get tlib, then try :TBrowseOutput digraph

<c-z> suspends filtering

Should be easy to lookup that code and make your own version which
exactly fits your needs.

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
In reply to this post by Paul Isambert
I guess the perfect thing for VimL would be moving it into its own
library (like python).

Then other projects could use VimL, too. And it would allow some future
optimizations.

Then it would be an optional dependency (which most users are very very
likely to use)

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

You can al ready do so:

  let string = {}
  for n in ['stridx','length','part']
    exec 'fun string.'.n.'(...) | return call('.n.', a:000) | endf'
  endfor

or such (untested)

> * Remove the one-command-per-line restriction, so you can write things
> like:
>     while foo if bar TRUE else break endif endwhile

See example above - often you already can use |
  eg while foo | if | bar | TRUE | else | break| endif| endwhile
or such.

> * 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?
If we start that, then we can work on a viml2 version adding proper
object support, closures - but then, why not just use python or ruby or
perl, or ... ?

> Now perhaps the best solution is to replace VimL with Lua or Ruby or,
You got it - improving VimL would lead to something other have already
invented.

We cannot replace VimL, but we can make python, ruby work as nice as viml.
Then this switch may naturally happen without breaking existing code.

There are cool languages such as urweb, disciple which deserve love and
have unique new features.

The next big thing is: Do I have enough to time to contribute to help
making this all happen - and if so - which is the best way.

Eg if somebody could investigate whether Vim could benefit from all the
work which is but into gobjectIntrospection this would be great.

I don't know yet - all I know is that they have similar goals: make C
apps scriptable by scripting languages.

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Davido
In reply to this post by MarcWeber
Marc Weber <[hidden email]> wrote, on mer 12 jun 14:35 :

> > Well, my previous post was confusing.  To be more specific, I'm talking
> > about the internal vim pager, used when ex commands produce output. For
> > instance, when you run :
>
> Get tlib, then try :TBrowseOutput digraph
>
> <c-z> suspends filtering
>
> Should be easy to lookup that code and make your own version which
> exactly fits your needs.
>
> Marc Weber

It looks fine, I shall see if it can be adapted for interactive menu
like with :browse

Thanks for your precious help !

> --
> --
> 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 [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
Regards,

Davido

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
Excerpts from Davido's message of Wed Jun 12 14:49:11 +0200 2013:
> It looks fine, I shall see if it can be adapted for interactive menu
> like with :browse
How is :browse related to a pager?

Talk about the use case you want to optimise, such as "opening a file"
and we can help you to find the fastest way.

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Davido
Marc Weber <[hidden email]> wrote, on mer 12 jun 15:01 :

> Excerpts from Davido's message of Wed Jun 12 14:49:11 +0200 2013:
> > It looks fine, I shall see if it can be adapted for interactive menu
> > like with :browse
> How is :browse related to a pager?
>
> Talk about the use case you want to optimise, such as "opening a file"
> and we can help you to find the fastest way.
>
> Marc Weber

When you enter :

:browse oldfiles

you get a list of files. You can then select the file you want to edit
by entering the corresponding number. Fine, unless you have a lot of
files and many pages to browse. The "more prompt" of vim appears then,
but you can't make any search in the output stream.

It becomes easier with the TBrowseOutput command. Once the file selected
and inserted in the ex command-line, all you have to do is replacing
the beginning of the line, say :

        :25: ~/source/edit/vim/README_extra.txt

so that it becomes :

        :e ~/source/edit/vim/README_extra.txt (and <cr>)

I'll look into the code to see if that change can be made and validated
automatically.

A more generic approach  would be to feed the input of the initial
vim command with the adequate value (in this case, the number of the
selected entry, ie 25).  Then, it would also work for :

        :tselect /pattern
        z=
        ...

--
Regards,

Davido

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Paul Isambert
In reply to this post by MarcWeber
Marc Weber <[hidden email]> a écrit:
> I guess the perfect thing for VimL would be moving it into its own
> library (like python).
>
> Then other projects could use VimL, too. And it would allow some future
> optimizations.
>
> Then it would be an optional dependency (which most users are very very
> likely to use)

Then this raises the question: can VimL stand on its own, i.e. even if
it were enhanced as far as functionality is concerned, why would
somebody use it rather than any other language? If you compare Python,
Ruby and Lua, there are strong reasons why you could favor one or the
other; what could VimL bring? (You more or less answer the question
below when you ask “Why not use Python or ... then?”)

> > * 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).
>
> You can al ready do so:
>
>   let string = {}
>   for n in ['stridx','length','part']
>     exec 'fun string.'.n.'(...) | return call('.n.', a:000) | endf'
>   endfor
>
> or such (untested)

Of course I can do that but it’d just be so much simpler if it were
already done (not to mention sharing code that use such a convention).

> > * Remove the one-command-per-line restriction, so you can write things
> > like:
> >     while foo if bar TRUE else break endif endwhile
>
> See example above - often you already can use |
>   eg while foo | if | bar | TRUE | else | break| endif| endwhile
> or such.

I forgot to mention: allow multiple commands on the same line without
the bar :) But thinking about it, perhaps that’s even simpler than
“then”, “do”, and/or “;” (albeit more dangerous because it *often*
works, not always).

> > * 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?
> If we start that, then we can work on a viml2 version adding proper
> object support, closures - but then, why not just use python or ruby or
> perl, or ... ?

Would it really be such a major change that you’d need an entirely new
version of the language?

> > Now perhaps the best solution is to replace VimL with Lua or Ruby or,
> You got it - improving VimL would lead to something other have already
> invented.
>
> We cannot replace VimL, but we can make python, ruby work as nice as viml.
> Then this switch may naturally happen without breaking existing code.

Yes, of course; but, as you put it, it “may naturally happen”, which
implies it might never happen too and perhaps ten years from now we’ll
still have an “official” yet limited scripting language and countless
extensions relying on “unofficial” languages (mostly Python) that
won’t work for everybody. So, in my opinion, it should rather be
decided now what we want to script Vim with in the future: either
VimL, and then it should be improved, or Python/Ruby/Lua/YouNameIt,
and then development should go in that direction now; the latter
solution would be quite a change.

> There are cool languages such as urweb, disciple which deserve love and
> have unique new features.

Oh, googling those, I see that both are Haskell-like languages
(Disciple is actually a dialect of Haskell). A few weeks ago, I
started trying to learn Haskell for fun; that *was* fun, but I
definitely wouldn’t want that to script my editor and I’m afraid it
would repel new users (one of the reasons why I chose Vim over Emacs
myself was that I just couldn’t get my head around Lisp and I wanted to
be able to customize the editor at once).

> The next big thing is: Do I have enough to time to contribute to help
> making this all happen - and if so - which is the best way.
>
> Eg if somebody could investigate whether Vim could benefit from all the
> work which is but into gobjectIntrospection this would be great.
>
> I don't know yet - all I know is that they have similar goals: make C
> apps scriptable by scripting languages.

Unfortunately I’m illiterate in C (I’m not a programmer, and I use Vim
mostly for TeX files), so I’m useless here – in case I wasn’t elsewhere :).

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber
In reply to this post by Davido
Excerpts from Davido's message of Wed Jun 12 15:26:08 +0200 2013:
> :browse oldfiles
oldfiles is broken by design becuase it doesn't cope with multiple vim
instances running at the same time.

github.com/MarcWeber/vim-addon-mru is a very simple alternative
implementation - and the author of tlist also has a tmru
plugin.

Try such:

  :exec 'e '.fnameescape(tlib#input#List('list', tlib#cmd#OutputAsList('browse oldfiles') ))

github.com/MarcWeber/vim-addon-command-line-completion is close, too. It
completes <c-d> completable things in command line showing a list.
However that plugin is not well supported by me.

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Davido
Marc Weber <[hidden email]> wrote, on mer 12 jun 15:53 :

> Excerpts from Davido's message of Wed Jun 12 15:26:08 +0200 2013:
> > :browse oldfiles
> oldfiles is broken by design becuase it doesn't cope with multiple vim
> instances running at the same time.
>
> github.com/MarcWeber/vim-addon-mru is a very simple alternative
> implementation - and the author of tlist also has a tmru
> plugin.

These are nice plugins, indeed. Also, mru and ozzy are great. I was just
thinking about a more generic approach. That's why I first introduced
this sub-topic as an enhancement of the native vim "more prompt".

> Try such:
>
>   :exec 'e '.fnameescape(tlib#input#List('list', tlib#cmd#OutputAsList('browse oldfiles') ))

it re-edit the current file.

> github.com/MarcWeber/vim-addon-command-line-completion is close, too. It
> completes <c-d> completable things in command line showing a list.
> However that plugin is not well supported by me.
>
> Marc Weber

You mean, it's one of your low-priority project ? I'll have a look at it.

--
Regards,

Davido

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

LCD 47
In reply to this post by MarcWeber
On 8 June 2013, Marc Weber <[hidden email]> wrote:
[...]
> 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 :)

    Personally I'd wish for a more consistent library of functions, and
for better docs, or at least a better indexing of the existing docs.

    Examples: there are bufexists(), buflisted(), and bufloaded()
functions, but no bufactive(); there are getbufvar() and setbufvar(),
but no undefbufvar(); you can do let $ENV='val' and let $ENV='', but not
unlet $ENV; placing and unplacing signs require IDs, but you can't get a
list of the existing IDs; findfile() can take wildcards in the path
argument but not in the filename.  And so on, and so forth; I'm pretty
sure everybody who ever wrote some VimL code has been driven up the wall
at some point or another by the absence of some "obvious" functions.

    On the flip side, there are a number of options that should be
removed.  Take f.i. 'magic'; this is pure evil: it's incomplete (you
can't set it to 'verymagic' or 'verynomagic'), yet it forces every
single script out there to handle it.  Then 'lazyredraw', off by
default, no less: why is this an option to begin with?

    About the docs, can you tell off the top of your head how can I get
to the list of functions gouped by category?  To the list of operator
priorities?  The list of exceptions?  How do you even search for these?

    As for what I'd do differently should the Vim project start from
scratch, I'd say that would be the GUI.  There are a few Vim refugees
that switched to Sublime Text, read what they say about their
experience.  It's enlightening, and they do make some unpleasant (to
most of us) but still valid points.  Example of such a rant:

http://delvarworld.github.io/blog/2013/03/16/just-use-sublime-text/

    Playing a little with Sublime Text might be inspiring, too.

    /lcd

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

MarcWeber

> magic [..] forces every single script out there to handle it.
That's fixable by prefixing all regex by \m ?

Then 'lazyredraw', off by
> default, no less: why is this an option to begin with?
Can you add this to the page?
http://vim-wiki.mawercer.de/wiki/vim-development/breaking-with-the-past.html then add ?vim_edit=1
And describe why which options should be gone (or at least be hidden)

>     About the docs, can you tell off the top of your head how can I get
> to the list of functions gouped by category?  To the list of operator
> priorities?  The list of exceptions?  How do you even search for these?
But is it a problem? Join irc, ask. Join mailinglist, ask. You usually
get good replies instantly. Yes - it sucks, but people listen and they
do help.

>     As for what I'd do differently should the Vim project start from
> scratch, I'd say that would be the GUI.
That's not enough. What exactly are you missing slowing you down?

> most of us) but still valid points.  Example of such a rant:
> http://delvarworld.github.io/blog/2013/03/16/just-use-sublime-text/

Let me comment shortly. (CCing the author, because I cannot comment on that
homepage)

> mouse faster than /word<cr>
Vim allows using the mouse, so that's not against Vim

> 1% of time you use features you train yourself for about 2 years
> (thus after leaving the learning curve)
Well, Vim has a 'insertmode' setting. I have a collegue who only is
using Vim for merging. I set that option, and he knowns how to :w.
That's it. That's again not against Vim (eventuall against how to learn
Vim).

> Plugins and Extensibility 1: Management
This really makes me angry. I've been very loud trying to fix this
problem. Still a lot of people don't know that VAM (vim-addon-manager)
is a solution to this. VAM was started end of 2009, exactly to
solve all of this problems. Yet in 2013, there are too many people who
don't even know that it exsits. The blog post dates 2013.
That's why the blog post talks only about "Pathogen" and "Vundle" - note that
Vundle was started after VAM.

So why does this happen? There is no way to modify vim.sf.net in a nice
way, to tell people about what options exist.

That's why almost all plugin authors jump to github, copy paste a
plugin, and adopt it. So they also adopt the "how to use pathogen"
section. After all pathogen is cool, it solves a problem, doesn't it?
Thus if you look at 10 plugins at github you're very likely to
learn about Pathogen, and you're very likely to miss vim-addon-manager.

Why? Because VAM tries to make plugin management that easy that its not
necessary to add long install instructions.

Wikia is not on www.vim.org - so Wikia is not always used. Also people
like me today don't want to contiribute, because Wikia shows too much
ads (for my taste) - yet you cannot get rid of it because it is indexed
by google.

My answer to this is a git based wiki you can editor online:
http://vim-wiki.mawercer.de/wiki/index.html
Its as simple as not needing anything but builtin gf feature for
navigation.

So please join that new wiki effort, so that we can move it to
vim.sf.net in the future. The only way doing so is by having enough
valuable content and contributions happening.

Of course the text I wrote about is based on my view, which might be
incomplete.

But yeah, it would be damn cool if we could create an API so that
plugins could be used by sublime and by Vim (and by Emacs, which also
has python bindings)

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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

LCD 47
On 12 June 2013, Marc Weber <[hidden email]> wrote:
>
> > magic [..] forces every single script out there to handle it.
> That's fixable by prefixing all regex by \m ?

    That's exactly my point: your options are (1) set 'magic' in your
script and make sure it never, ever, under any circumstance spills onto
the command line, or (2) litter every single regexp with \m.

> > Then 'lazyredraw', off by default, no less: why is this an option to
> > begin with?
> Can you add this to the page?
> http://vim-wiki.mawercer.de/wiki/vim-development/breaking-with-the-past.html
> then add ?vim_edit=1 And describe why which options should be gone (or
> at least be hidden)

    I might gather the time and determination to go through that list
some day, but then I'll probably find it easier to write a patch than
write a story about it.

> > About the docs, can you tell off the top of your head how can I get
> > to the list of functions gouped by category?  To the list of
> > operator priorities?  The list of exceptions?  How do you even
> > search for these?
> But is it a problem?

    Yes, it is, a big one.  When I need a reference, I almost always
need it right away.  If I receive it two hours later when somebody posts
an answer to some list, it will be out of context for my tiny brain.
I'm an old fart researcher, and to me a reference is a reference, and a
help desk is a help desk.  They serve very different purposes.

> Join irc, ask. Join mailinglist, ask. You usually get good replies
> instantly. Yes - it sucks, but people listen and they do help.
>
> > As for what I'd do differently should the Vim project start from
> > scratch, I'd say that would be the GUI.
> That's not enough. What exactly are you missing slowing you down?

    I added the link to that blog post mainly for that particular point.
There are a number of things we'll never ever see in Vim, such as more
than one font size on the screen at the same time, or minimap.  Do try
Sublime Text some time, you'll be surprised how nice it actually is.

> > most of us) but still valid points.  Example of such a rant:
> > http://delvarworld.github.io/blog/2013/03/16/just-use-sublime-text/
>
> Let me comment shortly. (CCing the author, because I cannot comment on
> that homepage)

    FWIW, I'm not that author of that post, and I don't agree with
everything there.  I was just pointing at a different way to look at
Vim.

[...]
> After all pathogen is cool, it solves a problem, doesn't it?
[...]

    Actually, yes, pathogen does solves the problem for some of us.
Whether you like pathogen, vundle, your vam, or something else, is a
matter of your personal style of doing things.  Pathogen does exactly
one thing, it does it well, and stays out of your way.  Some people do
appreciate this kind of minimalism.

    /lcd

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: breaking with history ?

Andy Wokula
In reply to this post by MarcWeber
Am 12.06.2013 15:53, schrieb Marc Weber:
> Try such:
>
>    :exec 'e '.fnameescape(tlib#input#List('list', tlib#cmd#OutputAsList('browse oldfiles') ))

This works here:

     :exec 'e' fnameescape(tlib#input#List('s', 'Old file', v:oldfiles))

(I haven't updated tlib for a while ...)

--
Andy

--
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.