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

Re: breaking with history ?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.