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

69440Re: capture() function to get output of command

Expand Messages
  • Ingo Karkat
    May 7, 2013
    • 0 Attachment
      On 07-May-2013 21:44 +0200, ZyX wrote:

      >> The functions in message.c write message with color attributes. So if splitting per line, it must get whole contents at the first.
      >> I guess someone want to get the contents as text which contains \n, but someone want to get the contents as array of lines. So I want to keep the contents as text.
      >>
      >> Thanks.
      >
      > Almost never used not splitted messages (they were only needed by me in case there is only one line of output; and only because splitting one line does not make much sense; code with proposed by @Ingo Karkat implementation of `capture()` is not a tiny bit harder to write in this case).

      Yes, that's what I thought. Thanks for this data point!

      > I have another proposal:

      You bring up very good points; I fully agree.

      > 1. Fix :redir to allow nesting.

      I think everyone agrees with this, and it should be first priority.

      > 2. Fix :redir to hold reference to dictionary containing variable (like l:, g:, s: or such) to workaround problem I mentioned in https://groups.google.com/forum/#!searchin/vim_dev/redir/vim_dev/1M3QS46SrAk/a13SqNpPWywJ. Obviously only in case redirecting to variable.

      I don't fully understand, but as long as it's backwards compatible,
      additional syntax, why not!?

      > 3. Make :redir automatically end when function ends if it holds reference to l:. In any case I doubt anybody needs to start redir in one function and end in another and do redirection to function-local variable at the time. This also must workaround stale :redir's left due to an exception (plugin authors almost always capture to function-local variables).

      This would alleviate a common programming error. Currently, all :redir
      commands have to be wrapped in try..finally to be safe, but few people
      do this.

      > 4. (optional) Add capture() function, but it should return a list of lists of dictionaries:
      >
      > [
      > [{'hl': "Error", 'text': "Error on first line"}, {'hl': "OtherHL", 'text': "Other highlight in first line (possible when using :echon)"}],
      > [{'hl': "Normal", 'text': "Regular message on second line"}],
      > ]
      >
      > . It is useful in some cases (like any use of :redir this cases happen mainly because of problems in API: distinguishing between `<LT>Space>` and `<Space>` in :map output (current code I use assumes nobody needs to define mapping like `<LT>F1>`; assumption has not proved false by the time, but having to use it bugs me); distinguishing between regular text and special characters in messages (don’t remember when I needed this, but there was some case)).

      Good idea. I had this need once with the :jumps output: Without the
      highlighting information, I had to implement a 99%-successful heuristic
      to decide whether the line refers to the current buffer or another file.
      It would be even better if the (mostly column-based) information issued
      by most commands came pre-parsed, but that probably would mean modifying
      all command implementations.

      > 5. (optional) Extend syntax of :redir to capture to a list of lines.

      Since this only applies for redirecting into a variable (not files or
      registers), I'd rather not further complicate the existing :redir
      command with this. Instead, if your proposal 4. capture() is
      implemented, have it take an argument {includeHl}, and just return a
      list of lines (without the Dictionary stuff) if 0 is passed. Most uses
      don't need the highlighting; this would make the function applicable to
      more use cases.


      I'd love to have all of those good enhancements, but I know that unless
      someone now starts working on a patch, this great discussion will again
      fizzle out, like so many before.

      -- 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.
    • Show all 26 messages in this topic