Re: [OT] "steep learning curve" ... but what is it actually?
I think the learning curve is said to be steep by comparison with an uphill path. So x would be how far you get and y would be the amount of expended effort. But does Vim really have a steep learning curve? IMHO what it has is a virtually unlimited set of capabilities — considering that it has a Turing-complete configuration language which seems more or less Algol-like to me (though without begin..end statements, instead with specialised endif, endwhile, endfunction, etc.) it feels to me that the power of Vim, especially of a feature-rich "huge" build, is limited only by the user's ingenuity and by his/her command of the scripting language. Who says Vim has a "steep" learning curve after all? I may be wrong, but I have a hunch that it's mostly people who tried Vim for an hour or maybe a day and noticed that they were still far from knowing all and every bit of the ins and outs of Vim. So what? My take on the subject is that, on the contrary, Vim is easy to learn because: • there is the vimtutor, a very well thought-out step-by-step hands-on tutorial; • the online help is at your fingertips and it covers every single bit of what there is to know about Vim. • there is even help about how to use the help: see :help helphelp Other programs have a page or two of online help — when they have any — and even with their limited featureset, their help falls far short of it. I admit that there are a very few, extremely few even, exceptions such as Mercurial. But even the Mercurial help, which is quite complete compared to many other programs' help, doesn't compare with the Vim help for ease of use. In Vim, once you're in the help, you go from one topic to another by double-clicking or hitting Ctrl-] on any word on which you want help, allowing you to learn Vim by reading its help by the Monte-Carlo method, as you would an encyclopædia, by going from one topic to another in no predefined sequence. But — yes, there is a but — with Vim, unlike with, say, Notepad, there is a lot to learn. You can master Notepad in a few minutes, a few hours if you're a slow learner. With Vim's, Socrates's maxim comes into its full force: «The more I learn, and the better I see how little I know.» To my way of looking at it, this is not a defect but a quality: it means that Vim packs so much power that it is worth learning it bit by bit, a little every day for years after years. Best regards, Tony. -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT] "steep learning curve" ... but what is it actually?
> On 2017-07-30 09:10, tu...@posteo.de wrote: >> Suppose this "steep learning curve" would be a graph >> in the mathematical sense -- I would think, that >> the X-axis represents t (time) and the Y-axis represents >> the amount of knowledge k in turn. > Really, the cliche's the wrong way around. It depends on whether you are looking at it as the rate of acquisition that's possible, (in which case a steep vertical represents an easy task), the rate that's necessary to survive, e.g. in an emergency, (in which case a steep gradient represents a challenge, learn quickly or die), or the effort required to achieve proficiency, with the X axis as proficiency and the Y axis as effort. -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT] "steep learning curve" ... but what is it actually?
On 2017-07-30 09:10, tu...@posteo.de wrote: > Suppose this "steep learning curve" would be a graph > in the mathematical sense -- I would think, that > the X-axis represents t (time) and the Y-axis represents > the amount of knowledge k in turn. I think the confusion comes because it seems to be a factor of two things over time: there's how much you need to know before you can accomplish something productively, and how completely you know the editor. With something like nano or notepad, you start typing and the text appears. There are on-screen menus to guide you in quitting/saving and basic search/replace. Additionally, their feature-set is sufficiently small that you quickly learn all their limited functionality[1] Meanwhile, the next set of editors (Sublime, Visual Studio, Atom, etc) tend to make things accessible via menus and GUIs. They present a lot more power and complexity, but still manage to keep things approachable for basic activities. Finally, editors like vi/vim, emacs, and ed have next to no help (vim improved on this with the opening screen's tips, but they're not visible if you are dumped in a file). Vi/vim/emacs have huge numbers of features (I've been using vim since around the turn of the century and am still learning new tricks ~18yrs later) that can be combined for combinatorial functionality, including scriptability meaning they can grow functionality that the original authors never created. So the proverbial graphs tend to refer to "how quickly can you get started" as well as "how limited are you". -tim [1] notepad does have one or to obscure features like the timestamped log, and nano does have additional functionality to learn like syntax highlighting. But these "advanced" features are a pretty small extension of the whole. -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: standard way include plugin as a dependency of another plugin
On 30/07/2017 04:40, sash...@gmail.com wrote: Hi I'm writing a plugin and want it to depend on another plugin installed. At the moment I just have a line source in my plugin that pulls in that plugin. Is there a standard way of doing this or do plugin authors just invent their own way? Could I use Vundle here instead? I think that the usual solution is just to document the dependencies. Then, it is the user's responsibility to get them, manually or using a plugin manager. The "modern" way (aka, Vim 8) is to use packages. From `:h packages`: "A package can contain multiple plugins that depend on each other." If you do not have control over one or more of your dependencies (because they are plugins written by other people), and if you distribute your package as a Git repo, a possibility is to include the dependencies you need as Git submodules. Mind that using submodules might result in users having multiple copies of the same plugin (i.e., one from your package and one installed by the user elsewhere, or even by another package). Typically, it shouldn't do any harm, but it is something to keep in mind, at least until packages become a mature feature of Vim, and widely adopted by plugin developers (which has not been the case, so far), so that best practices will emerge. Life. -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[OT] "steep learning curve" ... but what is it actually?
Hi, Often it i said, vim would have a steep learning curve... If I think aboyt a "steep learning curve" as such in a more mathematical sense...I dont understand this argument for being a negative one. Suppose this "steep learning curve" would be a graph in the mathematical sense -- I would think, that the X-axis represents t (time) and the Y-axis represents the amount of knowledge k in turn. With this setuo a steep curve would imply, that mu knowledge about for example vim would increase more in a shorter period of time than with other tools with a flat learning curve which does not reaches that high values for Ynotepad for example. Why is this taken as a negative feature? Let us build more tools with steep learninging curves to seperate those from tools which has nothing to offer... ;) This is not meant as an argument for overcomplicated tools, though... Or did I understand totally wrong here...? Cheers Meino PS: I dont understand "editor wars" -- how can be there a war between a sole editor? ;) -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
