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

Re: capture() function to get output of command

Expand Messages
  • ZyX
    ... Show me them then. It breaks only with nested redirections and it breaks only in the fashion that you get more expected output in place of error and empty
    Message 1 of 26 , May 10, 2013
    • 0 Attachment
      пятница, 10 мая 2013 г., 6:09:15 UTC+4 пользователь mattn написал:
      > On Thursday, May 9, 2013 7:54:38 AM UTC+9, ZyX wrote:
      > <snip>
      >
      > I don't hope that capture() contains highlight attributes. It should be plain text. And I guess fixing redir nesting has problems.
      >
      > 1. There are plugins that depend on original behavior. This break compatible.

      Show me them then. It breaks only with nested redirections and it breaks only in the fashion that you get more expected output in place of error and empty string in variable. There is only one case when nested :redir breaks in other fashion: a sequence of :redir's in one function without :redir ENDs except for last one. I have never seen such a strange thing, but there is a way to fix this case: make :redir update variable immediately each time new :redir is called without waiting for :redir END (in any case you need something to store text redirected at this level, why not make it store in variable/register/file? I do not think anybody benefits from "The variable will remain empty until redirection ends."). Unneeded :redirs will likely be GCed when function ends (third suggestion).

      > 2. If skipped 'redir END' with exceptions, we can't close the nesting.

      This is why I have 3-rd suggestion. Most of the time :redir is used to redirect to variables.

      >
      > For about 2, one of solution is adding bang like 'redir! END'. but this will close all of redir nesting. So it's become un-expected behavior.

      You don't need :redir! END. Just don't leave all redirection options to user besides for redirection to variable inside a function. Or use :try..:finally.

      If somebody has left stale redirections currently you will see unexpected behavior (error) with regular :redir, refer to the link in my first message. In addition to the text logged somewhere (but only to one place) until next :redir is called.

      If somebody has left stale redirections with new proposal you will just have text logged somewhere (but only to one place as well) until session ends. It is very rare to see stale redirections: I have never seen them so far and never written something that leaves such redirections; and logging to some place with usual amount of messages is not too harmful. Thus advantages are greater then disadvantages.

      To diagnose the issue :redir (without arguments) should print the stack of places where redirected text will go in order; it will only be actually written to the one last position.

      >
      > Thanks.
      > - Yasuhiro Matsumoto

      --
      --
      You received this message from the "vim_dev" 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_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ingo Karkat
      On 10-May-2013 04:09 +0200, mattn wrote: I beg your pardon, but I find your entire argument weak and unconstructive. ... Both ZyX s and my recent messages have
      Message 2 of 26 , May 13, 2013
      • 0 Attachment
        On 10-May-2013 04:09 +0200, mattn wrote:

        I beg your pardon, but I find your entire argument weak and unconstructive.

        > On Thursday, May 9, 2013 7:54:38 AM UTC+9, ZyX wrote:
        > <snip>
        >
        > I don't hope that capture() contains highlight attributes. It should
        > be plain text.

        Both ZyX's and my recent messages have already shown cases where this
        additional information is essential. If you don't need it, ignore the
        information / don't request it (my suggestion makes this optional via a
        passed flag).

        > And I guess fixing redir nesting has problems.

        Your intuitions and guesses aren't really helpful in this otherwise very
        factual discussion.

        > 1. There are plugins that depend on original behavior. This break compatible.

        I cannot think of a plugin that depends on having a nested :redir throw
        an error. That's just bad coding practice, and it could easily be
        corrected in the plugin. Do you have an actual example? As I've shown,
        contrarily there are plugins that (when working together) are indeed
        broken due to what I would call an implementation deficiency.

        > [3 lines deleted]

        Please take no offense, I value your opinion like every other, but
        please support them with facts and concrete examples as much as
        possible. Thank you.

        -- regards, ingo

        --
        --
        You received this message from the "vim_dev" 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_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Ingo Karkat
        ... ever hear python `subprocess` module refusing to work because user has wrong configuration options? Also try to write down rules for dividing a string into
        Message 3 of 26 , May 13, 2013
        • 0 Attachment
          On 09-May-2013 00:54 +0200, ZyX wrote:

          > > > [10 sentences deleted]
          >
          >> I've heard the dislike of Vimscript, but much of that is probably due to
          >> the developers' relative unfamiliarity with it. For extensions that are
          >> closely related to text-editing, I found it quite nice and powerful, and
          >> there is no mismatch between the Vim API and another language to bridge.
          >> But I agree that other stuff (e.g. any interfacing with external systems
          >> or networking stuff) is extremely hard (though people have written
          >> hashing functions or JSON parsers in Vimscript).
          >
          > This is not a problem with other stuff. I have to care about a big bunch of options like &ignorecase. I have to always remember about strange defaults (:map without nore while best practices tell nore should be default, :command without -bar while most commands will be more convenient to use with it and so on). I have to remember about escaping, and correct escaping (three common escaping variants for different cases). I have to forget about writing some neat code because it does not work reliably (e.g. :!python %). I have to generate a big number of lines just to take care of NUL case when in python it is just a regular symbol. Even in zsh it looks like a regular symbol though zsh uses just the same NUL-terminated strings. I have to know about some inconsistencies which will never be fixed due to backwards compatibility. Do you know that there is no option for filename completion in user-defined commands except for `custom…`? I have to hope user have sane configuration. Did you
          ever hear python `subprocess` module refusing to work because user has wrong configuration options? Also try to write down rules for dividing a string into a list of statements for python and for VimL and compare it. There is no such thing like a bunch of variants of handling newline depending on the bunch of variants of non-immediately-surrounding context† in python.

          Good explanation of the pain points. My take on this is: Vimscript is
          made primarily for interactive use, and therefore it is difficult to
          write watertight plugin code that works under all circumstances.

          It's great to be able to write :! python % when you know the Python in
          your PATH is the right one, and your file doesn't contain spaces, but in
          a plugin, you have to pull together configuration variables,
          executable(), fnamescape(), etc., and it gets messy quickly. Likewise,
          :map is often right for ad-hoc mappings, but all plugins should use
          :noremap. Same for 'ignorecase'.

          > [2 sentences deleted]
          >
          > Developers do not like VimL not because they do not know it. They dislike it because they do. I cannot say there are no things that bug me in python, zsh or perl (high-level languages I know good enough to judge, best known first), but VimL is the only one that bugs me that much. I have to say though that when I was writing some simple things it seemed good, but “the farther into the forest, the thicker the trees”. I just did not know all the cases where my simple things can break and did not care about them.

          For me, it's again the trade off (or historical accident) that was made
          in favor of easy migration from ad-hoc macros to mappings to
          full-fledged personal plugins to published plugins. The great thing is
          that it's Vimscript all down that path, the downside is that what was a
          simple one-liner has to be rewritten to a complex dozen-line function
          (with stuff that has to be tediously learned) in order to be fully
          robust under most users' customizations.

          On the other hand, maybe we're holding ourselves to too high ideals.
          Most plugins I've tried and reviewed (even from venerable long-time
          contributors like Tim Pope or Dr. Chip, though admittedly much less so)
          have certain deficiencies or break when used with obscure settings or
          environments, but most people are happy to use them, anyway. So I tend
          to defend Vimscript on its "worse is better" philosophy when language
          purists try to bash it too much. But I would be happy if a different
          approach (like your planned much-extended Python interface) turns out to
          be as productive without so many pitfalls.

          > [11 sentences deleted]

          -- regards, ingo

          --
          --
          You received this message from the "vim_dev" 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_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • ZyX
          ... Refer to my message. Nested :redir throws an error only when context is switched, it is possible to have redir = commands command redir = mappings map
          Message 4 of 26 , May 13, 2013
          • 0 Attachment
            > I cannot think of a plugin that depends on having a nested :redir throw
            > an error.

            Refer to my message. Nested :redir throws an error only when context is switched, it is possible to have

            redir => commands
            command
            redir => mappings
            map
            redir => imappings
            imap
            " and so on
            redir END

            > That's just bad coding practice, and it could easily be
            > corrected in the plugin.

            I completely agree there. Also refer to my message, I explained there how this situation may easily be worked around (just making it always write to target when any :redir is issued is enough for plugins to work; finishing redirections to local variables after function finishes will delete stale redirs in all cases that make sense to write from my point of view and even not finishing should be rare enough and not result in much harm: at maximum vim killed by OOM killer or a few MiBs long file). I have never actually seen plugins with the above code though.

            > Do you have an actual example? As I've shown,
            > contrarily there are plugins that (when working together) are indeed
            > broken due to what I would call an implementation deficiency.

            --
            --
            You received this message from the "vim_dev" 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_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • mattn
            ... I m thinking capture() is not replacement of redir. So I m thinking this issue should be separated with redir s issue. 1. The redir have a problem
            Message 5 of 26 , Jun 16, 2013
            • 0 Attachment
              On Tuesday, May 14, 2013 5:46:25 AM UTC+9, ZyX wrote:
              > > I cannot think of a plugin that depends on having a nested :redir throw
              > > an error.
              >
              > Refer to my message. Nested :redir throws an error only when context is switched, it is possible to have
              >
              > redir => commands
              > command
              > redir => mappings
              > map
              > redir => imappings
              > imap
              > " and so on
              > redir END
              >
              > > That's just bad coding practice, and it could easily be
              > > corrected in the plugin.
              >
              > I completely agree there. Also refer to my message, I explained there how this situation may easily be worked around (just making it always write to target when any :redir is issued is enough for plugins to work; finishing redirections to local variables after function finishes will delete stale redirs in all cases that make sense to write from my point of view and even not finishing should be rare enough and not result in much harm: at maximum vim killed by OOM killer or a few MiBs long file). I have never actually seen plugins with the above code though.
              >
              > > Do you have an actual example? As I've shown,
              > > contrarily there are plugins that (when working together) are indeed
              > > broken due to what I would call an implementation deficiency.


              I'm thinking capture() is not replacement of redir. So I'm thinking this issue should be separated with redir's issue.

              1. The redir have a problem currently, But capture() doesn't.
              2. Reasonable to implement.
              3. Easy to use. Possible to write per one line.
              4. I know there are some users who want capture().

              I'm thinking it's good idea to solve some problem.

              Thanks.

              --
              --
              You received this message from the "vim_dev" 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_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Shougo
              ... Yes. I think so, too. 1. I can use capture() easily than :redir. Example: let foo = capture( :mes ) redir = foo mes redir END Which is the easy to
              Message 6 of 26 , Jun 16, 2013
              • 0 Attachment
                2013年6月17日月曜日 11時49分10秒 UTC+9 mattn:
                > On Tuesday, May 14, 2013 5:46:25 AM UTC+9, ZyX wrote:
                > > > I cannot think of a plugin that depends on having a nested :redir throw
                > > > an error.
                > >
                > > Refer to my message. Nested :redir throws an error only when context is switched, it is possible to have
                > >
                > > redir => commands
                > > command
                > > redir => mappings
                > > map
                > > redir => imappings
                > > imap
                > > " and so on
                > > redir END
                > >
                > > > That's just bad coding practice, and it could easily be
                > > > corrected in the plugin.
                > >
                > > I completely agree there. Also refer to my message, I explained there how this situation may easily be worked around (just making it always write to target when any :redir is issued is enough for plugins to work; finishing redirections to local variables after function finishes will delete stale redirs in all cases that make sense to write from my point of view and even not finishing should be rare enough and not result in much harm: at maximum vim killed by OOM killer or a few MiBs long file). I have never actually seen plugins with the above code though.
                > >
                > > > Do you have an actual example? As I've shown,
                > > > contrarily there are plugins that (when working together) are indeed
                > > > broken due to what I would call an implementation deficiency.
                >
                >
                > I'm thinking capture() is not replacement of redir. So I'm thinking this issue should be separated with redir's issue.
                >
                > 1. The redir have a problem currently, But capture() doesn't.
                > 2. Reasonable to implement.
                > 3. Easy to use. Possible to write per one line.
                > 4. I know there are some users who want capture().
                >
                > I'm thinking it's good idea to solve some problem.
                >
                > Thanks.

                Yes. I think so, too.

                1. I can use capture() easily than :redir.

                Example:
                let foo = capture(":mes")

                redir => foo
                mes
                redir END

                Which is the easy to understand?

                2. And, the capture() is used for function arguments.

                Example:
                echo remote_expr("GVIM1", "capture(':mes')")

                I think function is better than command to use it in Vim script.

                3. I think the patch works well(because I tested it).
                But to fix redir is no patches, it is too far to use it in my plugins.

                --
                --
                You received this message from the "vim_dev" 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_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+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.