On Wed, Aug 17, 2016 at 3: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. >
I was about to make a similar suggestion. As it is now, the docs claim that the "options" dictionary will only contain buffer-local options. But this is a bit misleading. That dictionary will hold the values of the so-called "global-local" options, even when the local value doesn't differ from the global one. For example, in my vimrc I have ":set stl=blah", and nowhere do I have ":setlocal stl=blah"; yet my entire statusline string appears in the "options" dictionary. This is very unexpected. For an even more annoying example, the entire gigantic string for "&lispwords"---an option I have never touched in my life---appears in the options dict, because &lispwords is global-local. I think it should not appear there unless the user has (in that buffer) set the local value to something different from the global one. Also I'm not sure why the get*info() functions have a "variables" dict, since there is already get*var() and one can call get*var() on whatever bufs/wins/tabs are returned by get*info(). It would probably be nice if there were also analogous get*options() functions. Then the "variables" and "options" dicts could both be removed from get*info(), and that would make get*info() return lighter lists. In summary, I think the get*info() functions would be improved by (1) not including global-local options in the "options" dict unless the local values differ from the global ones; (2) eliminating the "variables" dictionary, since that information is easily found by combining get*info() with get*var(). -Manny -- -- 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.
