> "f" means function in my dictionary, no confusion. > You can grep for "vim.f." easily.
“f” is commonly used for file objects (*one* file object for each f). It may also refer to *one* function. We have more functions there. > > • The age of punch cards is over. Nowadays the common 80 columns > > limit is just a habit without any technical reasons. Few people > > realized it, e.g. the Funtoo Linux Project has a coding standard with > > line length up to 160 characters. > > Most of my terminals are 80 columns wide. 100 when editing Java (which > has the problem of too long names). Main reason is that this way I can > see more windows side-by-side. I have slightly less then 120 columns for two windows (119 and 119 columns + 1 separator, 239 total). Thus I do not care when the limit is lesser then 119, but 160 is too much for my taste. > It's not short that matters, it's quickly reading. Common words can be > read quickly even when they are long. > > Anyway, it's more a personal preference than anything else. > > In my opinion vim.function could mean something else than the leader for > all functions. Also because there is a function() function. > Perhaps it should be vim.functions instead of vim.function? Please refer to my RFC. I *never* named it vim.function, it is vim.functions what was written there. See commit history if you don’t believe me. I also found my message where this data was duplicated. *There* is also `vim.functions`. Note that `vim.Function` is a function class, `vim.function` is the name of the type, they may be mentioned in a number of places. > Considering we have vim.windows and vim.buffers. It's not the same > though, windows and buffers are dynamic, the list of functions is fixed. > Well, unless you include user functions. Initial intention of `vim.functions` is to provide an interface *only* to user functions (main reasons: necessity to expand function names and intention of removing the need in functions and commands by adding python interfaces (obviously except for the cases when you need interaction with VimL plugins: this is why vim.functions appeared at all)). `vim.functions.bufnr` was suggested later by @Andy Kittner and I accepted this suggestion. Note: @Andy Kittner also wrote `vim.functions.bufnr`, not `vim.function.bufnr`. -- -- 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.
