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

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

Expand Messages
  • ZyX
    May 8, 2013
    • 0 Attachment
      > > 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!?

      It is backwards compatible, but there is no additional syntax. When you call :redir with variable name it seems (I did not look at the code) to create a variable, save variable name (but not the typval_T reference) and when writing to it use usual ways to get variable and write to the structure. Thus if :redir END is called when created variable is not in (script-)local scope of this call it errors out with “variable does not exist” or like. If :redir instead saved reference to the dict_T structure and then used usual methods of assigning dictionary key that error won’t appear. Alternatively this saved reference can be used to check whether :redir END is called in the same scope and do nothing (or give different error message) in case it is not. With nested :redir’ections I have nothing against error, without you will have to wrap `:redir =>` into a separate :try..:catch (with empty :catch block, and with pattern argument in this command) to be safe. In addition to surrounding :try..:finally of course.

      > > 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.

      I am going to reduce the need for :redir for python users: further extension to python interface providing:

      - vim.maps/vim.buffer.maps (*iterable* and with output similar to maparg(lhs, mode, abbr, dict=True) (but as python object and .noremap with three values in place of two)): removes the need for parsing :redir|:map|:redir END;
      - vim.commands/vim.buffer.commands (iterable, after finished will be the only way to get command definition using something other then :redir);
      - vim.autocommands (iterable; same as above);
      - vim.signs (:sign [un]define/:sign list), vim.buffer.signs (:sign [un]place);
      - vim.registers (there is no way to get NUL out of the registers except for pasting register in a scratch buffer: any string manipulation transforms internal representation of NUL to "\n" and :redir|:reg truncates output in addition to having to guess (or much more complex: compare with `getreg()` output) whether ^@ meant NUL or somebody was typing ^ then @ like I did here).

      : this serves two purposes: make plugin writers prefer python (thus I am not talking about VimL API) and create normal API for the things that lack one. If you have other candidates tell me (I guess I already have one from you: :jumps). I will open a RFC here when API is fully designed; though I probably won’t have much time to write an implementation in next one or two months.

      Maybe I even won’t forget about the discussion after both API and implementation are finished. The thing I won’t add to python though is vim.capture: usage of :redir only means some API is missing and that is the problem that should be fixed.

      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