> > 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
