On 08-May-2013 19:57 +0200, ZyX wrote:
>>> 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
> :tr
y..:finally of course.
Ah, thanks for the clarification; I think I understand now. I've never
done :redir END in a different scope, but it would be nice if this
corner case bug could be fixed.
>>> 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.
I've seen your many recent Python patches, and it's certainly good to
have more things exposed in a native language way. However, I'm a bit
concerned if (but I know too little about your patches to be sure) you
have to write all the plumbing from Vim's internal structures to the
Python interface in a Python-specific way. I would prefer if most of the
plumbing were done in Vim core, so that Vimscript as well as other
language integrations could easily benefit. I imagine that the object
model of Vimscript, Python, Perl, Ruby, Lua, etc. are similar enough
that if all that access functionality existed in Vim core, each
integration could get at that with a very thin language-dependent bridge.
To put it in another way: Christian Brabandt recently implemented a
Vimscript getsign() function and extended exists() to be able to access
the sign information. I would hope that your vim.signs implementation
could leverage most of that from Vim core. It would be bad if your
implementation is a completely separate access of the core Vim
structures, because of:
- duplication = code bloat
- other language integrations will eventually want to have the same
access; each has to tediously reinvent the wheel, and will probably do
so inconsistently
- since maintenance is separate for each language, we end up with Python
abilities for A, B, and C, Vimscript access for A & B (and use of :redir
for C), and e.g. Ruby access only for C.
> 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.
Don't get me wrong; I appreciate your efforts to improve the Python
interface. I'm just a bit afraid that in the future, people will use
Python just because there's no equally convenient way to access the
information from Vimscript. To me, that would be bad. The Vimscript API
should remain the first-class, full interface (that doesn't preclude
other languages from having an equally rich interface), so that other
languages are chosen based on their merits (mostly familiarity and
external APIs that not available inside Vim), not based on need.
-- 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
