Loading ...
Sorry, an error occurred while loading the content.

breaking with history ?

Expand Messages
  • Marc Weber
    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
    Message 1 of 20 , Jun 8, 2013
    • 0 Attachment
      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 vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Steve Litt
      On Sat, 08 Jun 2013 23:20:22 +0200 ... I looked at that list, and speaking for myself, not one of those features would be worth a huge amount of
      Message 2 of 20 , Jun 8, 2013
      • 0 Attachment
        On Sat, 08 Jun 2013 23:20:22 +0200
        Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        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.
        Message 3 of 20 , Jun 8, 2013
        • 0 Attachment
          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 vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Robert 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
          Message 4 of 20 , Jun 8, 2013
          • 0 Attachment
            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 vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
             
             
          • Davido
            ... 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
            Message 5 of 20 , Jun 12, 2013
            • 0 Attachment
              Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Marc Weber
              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
              Message 6 of 20 , Jun 12, 2013
              • 0 Attachment
                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 vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Paul Isambert
                ... 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
                Message 7 of 20 , Jun 12, 2013
                • 0 Attachment
                  Marc Weber <marco-oweber@...> 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@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Davido
                  ... 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 ... ... and
                  Message 8 of 20 , Jun 12, 2013
                  • 0 Attachment
                    Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Marc Weber
                    ... Get tlib, then try :TBrowseOutput digraph suspends filtering Should be easy to lookup that code and make your own version which exactly fits your
                    Message 9 of 20 , Jun 12, 2013
                    • 0 Attachment
                      > 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 vim_use+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Marc Weber
                      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
                      Message 10 of 20 , Jun 12, 2013
                      • 0 Attachment
                        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 vim_use+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Davido
                        ... It looks fine, I shall see if it can be adapted for interactive menu like with :browse Thanks for your precious help ! ... -- Regards, Davido -- -- You
                        Message 11 of 20 , Jun 12, 2013
                        • 0 Attachment
                          Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                          > 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 vim_use+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Marc Weber
                          ... 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
                          Message 12 of 20 , Jun 12, 2013
                          • 0 Attachment
                            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 vim_use+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • Davido
                            ... 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
                            Message 13 of 20 , Jun 12, 2013
                            • 0 Attachment
                              Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Paul Isambert
                              ... 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
                              Message 14 of 20 , Jun 12, 2013
                              • 0 Attachment
                                Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • Marc Weber
                                ... 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
                                Message 15 of 20 , Jun 12, 2013
                                • 0 Attachment
                                  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 vim_use+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • Davido
                                  ... 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
                                  Message 16 of 20 , Jun 12, 2013
                                  • 0 Attachment
                                    Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                                    For more options, visit https://groups.google.com/groups/opt_out.
                                  • LCD 47
                                    On 8 June 2013, Marc Weber wrote: [...] ... Personally I d wish for a more consistent library of functions, and for better docs, or at
                                    Message 17 of 20 , Jun 12, 2013
                                    • 0 Attachment
                                      On 8 June 2013, Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • Marc Weber
                                      ... That s fixable by prefixing all regex by m ? Then lazyredraw , off by ... Can you add this to the page?
                                      Message 18 of 20 , Jun 12, 2013
                                      • 0 Attachment
                                        > 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 vim_use+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                      • LCD 47
                                        ... 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,
                                        Message 19 of 20 , Jun 12, 2013
                                        • 0 Attachment
                                          On 12 June 2013, Marc Weber <marco-oweber@...> 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 vim_use+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        • Andy Wokula
                                          ... (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
                                          Message 20 of 20 , Jun 14, 2013
                                          • 0 Attachment
                                            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 vim_use+unsubscribe@....
                                            For more options, visit https://groups.google.com/groups/opt_out.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.