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

Re: breaking with history ?

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