Hi,

On Wed, Aug 17, 2016 at 1:48 AM, LCD 47 <lcd...@gmail.com> wrote:
> On 16 August 2016, Yegappan Lakshmanan <yegapp...@gmail.com> wrote:
>> I am in particular interested in any comments/suggestions about the following
>> new functions:
>>
>> getbufinfo()
>
>     From the manual:
>
> :               Each returned List item is a dictionary with the following
> :               entries:
> :                       changed         TRUE if the buffer is modified.
> :                       changedtick     number of changes made to the buffer.
> :                       hidden          TRUE if the buffer is hidden.
> :                       listed          TRUE if the buffer is listed.
> :                       lnum            current line number in buffer.
> :                       loaded          TRUE if the buffer is loaded.
> :                       name            full path to the file in the buffer.
> :                       nr              buffer number.
> :                       options         dictionary of buffer local options.
> :                       signs           list of signs placed in the buffer.
> :                                       Each list item is a dictionary with
> :                                       the following fields:
> :                                           id    sign identifier
> :                                           lnum  line number
> :                                           name  sign name
> :                       variables       dictionary of buffer local variables.
> :                       windows         list of window IDs with this buffer
>
>     "options", "signs", and "variables" return lists that are potentially
> huge.  Perhaps there should be a way to tell getbufinfo() to skip these lists;
> otherwise plugins would just avoid calling this function, for performance
> reasons.
>

We can use the dict argument to the getbufinfo() function to specify
what to return. The default is to return everything like above. I will send
a patch for this.

>
>     On the other hand, finding the number of lines in a buffer as "line('$')"
> is very inefficient, so maybe this would be a good place to return it.  But
> again, as an option, since it would involve loading the buffer.
>
>> gettabinfo()
>> getwininfo()
>
>     From the manual:
>
> :               Each List item is a Dictionary with the following entries:
> :                       bufnum          number of buffer in the window
> :                       height          window height
> :                       loclist         1 if showing a location list
> :                                       {only with the +quickfix feature}
> :                       nr              window number
> :                       options         dictionary of window local options
> :                       quickfix        1 if quickfix or location list window
> :                                       {only with the +quickfix feature}
> :                       tpnr            tab page number
> :                       variables       dictionary of window local variables
> :                       width           window width
> :                       winid           window ID
>
>     Perhaps "tpnr" should be renamed to something more suggestive, such as
> "tabnr"?
>

This can be changed.

>
>> getqflist()
>
>     The manual could use some rephrasing.  As it is, it sounds unnatural even
> to my broken English.
>

Any particular text in the help that is confusing?

>
>> setqflist()
>> getcompletion()
>
>     Again, getcompletion() can return some potentially huge lists.  Being able
> to restrict results to smaller subsets could make this function a lot lighter.
>

The "pattern" (first argument) can be used to filter the returned results.
Is that not sufficient?

- Yegappan

>
>     /lcd
>

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui