> No other software product that I've ever come across or used has had a better documentation.
Vim requires so much documentation just to be usable. There is no GUI to hint at how to do anything. No toolbars, no application menus, no context menus or buttons. Vim's documentation is probably somewhat responsible for its popularity. I've never not found something I needed in Vim's documentation.
I'm not saying there isn't a time and a place for that, but after your 2nd or 3rd decade of using a tool, sometimes you just want to see the text you're working on.
You may have hit on my fundamental frustration with Unix command line. Every tool is designed around the basic assumption that the user has a couple of decades of experience and wants the tool to get out out of the way and let them work. That's great for veterans, but actively hostile to newbies.
You'd think there could be some sort of middle ground.
> That's great for veterans, but actively hostile to newbies.
I would have to respectfully disagree. With the copious amounts of man-pages, the availability of vim-tutor (for this particular case), and all other avenues of help available within most Unix tools, I cannot agree with the notion that software (vim, in particular) is actively hostile. Compared to the copious amounts of software that is far less documented, and far less robust than the standard Unix set of tools, I think calling the command line hostile is at best downright laziness.
Please don't call something hostile if you've barely given it a chance. Not every tool needs to be wrapped in a fully animated tutorial with buttons everywhere. In fact, the more elegant tools often don't have these things and do their best to stay out of your way. Which leads to the next part of your comment:
> You'd think there could be some sort of middle ground.
Why would there be? Any middle ground would risk upsetting two groups: the power users that want the tool to stay out of the way and do what it's meant to do, and the group of newbies (or regular users) that can't figure out what the tool was designed for or the best way to use it. The regular users wouldn't be satisfied with the help available for any middle-ground tool, and power users would just find that the half-baked tutorials, help system, or user support just got in the way. This would cause a rift in the community, which would force some users to search for a replacement that gives better help, while the power users would drift to a similar tool with the cruft and bell and whistles removed.
If you're just a regular user, and you end up using a tool like Notepad++ or Nano or some other editor instead of Vim or Emacs, and you can't for the life of you figure out vim or emacs, that is completely fine. Continue using the tool you are capable of wielding. However, that's not to say that vim or emacs don't have their own documentation and help systems, it's just that they're not served to the user in the same way. It may not be directly obvious when switching between systems (example: standard help documentation in Windows is nothing like using man or info pages), but I would reckon that it is only immediately non-obvious because you're already used to another way of searching for help.
So please stop calling software hostile, and give it a chance. Truly hostile software exists, but I can guarantee you that basic command line utilities are not it.
Whether you call it hostile or unintuitive, or something else, it's a fact. Unless you're in the field you want to fire up an app, do what the title/description has set in terms of expectation and, if you're the kind that needs it, slowly begin to discover and learn the advanced features.
Starting an app and needing to spend half an hour in documentation is not how to sell it. No matter how good the documentation is. Someone else made the same tool that's a lot easier to use, and that's what the users migrate to.
There are Linux tools which are optimized toward easy use. If it's editing you want, there are are equivalents of Windows Notepad AND HAVE BEEN FROM VERY EARLY ON.
xedit, nedit, kedit, gedit, and more, are all basic GUI text editors. nano (and pico) are very basic console editors aimed at basic users.
The point about vim and emacs is that they're not fundamental editors (though learning the basics is quick), they're very powerful performance tools.
The problem with tools that don't offer advanced features is that you bang into their limitations very, very quickly. They lack automation, they lack the ability to perform large tasks quickly.
And the problem with proprietary tools is that they are limited in availability: they're online-only, or limited to a specific OS, or, worst of all: they company folds and the tools become unsupported and/or unavailable.
I suppose one of the advantages of a GUI is that it shows you what options are available; it's kind of inherently "explorable".
There's probably a few factors that confound this. First, a GUI for something as abstract and powerful as VI is difficult to create, and still keep usable. The only way I can really imagine it is a kind of tutorial overlay which presents common options on the screen. Similar problem for the shell, I guess, there are just too many things you can / want to do in there to distill into a GUI.
Second, I suspect that these tools come from an age where people had different expectations, and with those, different ways of looking for help. I guess most *nix people are aware of man-pages, and are pretty efficient at reading it's syntax. Despite it's lack of GUI, VIM tries pretty hard to point you to the help (e.g. on my installation, the help commands are always shown when you start it - I guess this is by default).
The CLI version of this is using two "things" at the same time, one thing in the CLI and another thing in some form of docs or tutorial or google result or whatever. Where "thing" equals window, monitor, screen/tmux, console tab, whatever. (edited to add, I've never learned a programming language any other way, in the olden days we used ink on paper books as the "other screen")
> different ways of looking for help
Windows / GUI way is one huge app that does absolutely everything and includes the entire world within it including all documentation and tutorials and its a failure to ever need anything outside that app, no matter if its a tool or a doc. This doesn't scale very well.
Unix / CLI way is many tools each perfect at one task, and the perfect tool for docs might be some tutorial on the net or perhaps a manpage, and that is philosophically the way it should be. Feature not bug. This scales pretty well.
GUI way is a swiss army knife. CLI way is a Wiha made in Germany of chromed hardened tool steel posidriv shape size #1 50mm blade length, which costs as much as a generic Chinese swiss army knife, but is a world class screwdriver.
Agreed, although the "perfect tool at one task" becomes slightly complex when we consider something like vim. Sure, I consider it to be very good at the "one task" of text editing, but that's such a broad subject, with so many sub tasks that the argument tends to break down.
Regarding help and explorability, I mean something a bit more than this. Take man pages for example; if I know what command I want to know more about, it's great. Without that knowledge, it's much harder to get information. In a weird GUI equivalent, you could click on an "administration" screen, and see the top 20 functionalities under that category (say, "you might be looking for: chmod, last, etc). Kind of a hierarchical breakdown of common functionality. Not only is this situation of zero knowledge more prevalent in today's non-expert PC user world, but it's also the way we've been "brought up" in the GUI world.
The problem with GUI explorability is that you're limited to the number of options displayable on the screen. Typically that's 8-12 menus, another 10-40 menu entries (and try scanning a menu of 40 entries), with submenus. You end up hiding as much as you reveal, and useful commands are buried under multiple layers of menus and dialogs.
By contrast, a commandline help plus a filter (e.g., grep) gives you a rapid way of finding a specific term. Or a commandline manual viewer plus inline search.
Tools with autocomplete (the vimperator plugin is a classic case of this, emacs as well) will start completing matching commands and patterns as you type and hit <tab>. It's hugely efficient for cutting through a vast command space.
From my bash shell prompt, hitting <tab> twice, I find I've got access to over 3900 commands. Try fitting that into a GUI.
You really don't need decades. A few months and a grounding in some basic unix philosophies is all you need to transition from Win to *nix. The CLI doesn't hold your hand like a GUI does, but it gives you oh-so-much-more power and flexibility. This is precisely why Windows developed PowerShell.
In any case, there is no general-purpose operating system that is not actively hostile to new administrators. People just forget all the little Windows weirdnesses, idiosyncracies, and idiocies over the years. When you switch OS, you're get hit with all the quirks at once, so it seems worse.
I can still remember learning vi, back when you had to duck dinosaurs on the way to the computer lab.
Took a couple of weeks to get comfortable with it, really only a few days to learn the basics.
No, that's not good enough for a use-it-once-and-never-again Web interface, but for an editor you'll be spending hours in daily for decades, it's entirely acceptable.
> You'd think there could be some sort of middle ground.
I am kind of an odd vim user. I use vim as my only editor, but I barely know any advanced commands. If I have to do a replace job, I do it by hand. I'm too lazy to learn macros. I'd rather learn a new programming language or algorithm. I also feel it breaks my flow, if I work on a problem and have to learn about my editor at the same time. For the same reason, I don't use any plugins. If I want to find out who to do something, I'd rather google it than using the build-in help. I guess, at that point I just want to answer the question at hand, not know everything about a command.
I don't even really like vim, I think it many quirks. At some point it segfaulted times for me on MacOS. Copy & pasting from another application (browser) is annoying. The vim community seems to celebrate odd hacks like ":w !sudo tee %", which doesn't even always work. I use things like "!grep foo `find . | grep py$`" for code search. In many ways not the best solution.
That said I still use vim, because it's a lightweight, yet powerful editor that is universally available. Any server you ssh into has it. It's all better than an IDE, that takes 30 seconds to load.
I decided to give atom.io a try. It seems like atom has many of the benefits of vim, but it's advanced features are more easily discoverable. I just started to look into it, time will tell. Maybe I should just make a commitment to I spend one weekend to really, really learn vim.
For searching through code I like Silver Searcher (ag) because it's blinding fast. And the vim plugin, based on the ack plugin, creates a quickfix list for you to page through.
I've hidden a lot of shit from intellij. Like you can start with the GUI and gradually remove things you don't need, it ends up looking like a text area with a side bar while you're editing code, and some tabs on top.
This varies by utility and more significantly by parent project.
There are lots of ways to access help on a properly provisioned Linux system (recognizing Linux as the true heir of Unix), though there are numerous less-than-optimal systems.
First off: Linux is a system and inherits a philosophy. Kernighan and Pike's The UNIX Programming Environment[1], particularly the first couple of chapters, remains relevant despite its 1984 publication date.
Secondly: All commands should have a manpage. The Debian GNU/Linux distribution considers the absence of manpages a non-critical bug (the package can be included on the stable release, but a bug report is appropriate), and has provided a large number of manpages. Virtually all Debian-derived distributions (including the popular Ubuntu and Mint distors) benefit from this. Other projects, notably GNU, deprecate manpages for info, another format, which I find far less useful for numerous reasons. Manpages are typically brief (the median length is around 3 pages of printed text), and include a syntax synopsis. A key section is the "Examples" portion, which shows actual examples of the command in use. While not universally, or even often, filled out, this can be tremendously useful.
Third: There are numerous other documentation sources and systems. In addition to man and info pages, FAQs, READMEs, and numerous other sources of information. Again, Debian requires that every installed software package have an entry under /usr/share/doc/<packagename>/ with certain required entries (copyright and changelogs), and often additional documentation including manuals and examples.
Fourth: Again, Debian includes a tool to make all of this information readily available via a locally-exported Web facility, dwww. This provides a Web interface at http://localhost/dwww/ with a searchable hierarchy of all installed system documentation: man and info pages, /usr/share/doc/, and additional READMEs, FAQs, manuals, RFCs, and other documentation, all installable via Debian packages. It's pretty fucking awesome, actually. The extent of the documentation (especially for large packages such as tetex) is often a, or the, major consumer of system space.
All of which sounds a bit overwhelming, but there's a pretty small set of knowledge you really need to get started at the commandline. The additional information is there if you need to dig into it.
Fifth: The fundamentals change slowly, if at all. Again, K&P is 30 years old, and yet the philosophy sections are still largely relevant. Even of the material that's changed, much of it is still a reasonably good guide. I've been using Unix-like environments for nearly 30 years, and one of the most useful aspects about it is that knowledge is almost always additive. Rather than having to learn and then unlearn things, I can stick additional bits of knowledge and understanding on my established base. This isn't always the case (sound, video, and firewall configuration, notably, have changed several times, the system startup mechanism is changing now with replacements to sysv-init battling it out), but compared with the other platforms I've learned and since forgotten, it's vastly more true: Commodore BASIC, CP/M and DOS, VM/CMS, TSO/ISPF, and PCL, DEC DCL, Windows 3.x, NT, and onwards, Mac System 1-9, Mac OS X. If you stick at this game long enough, you'll find that forgetting things is as important as learning new things, and a system which doesn't force you to forget frequently is a huge bonus.
Linux has good bones.
That's also why many commands are as complex as they are: they've got upwards of 40 years of context applied to them. Why is dd so weird? It's a mainframe command, ported with syntax (spend time with JCL and you'll recognize it). ar begat tar. Various compression utilities subsume changes in formats (though gzip tends to include many of them). vim is based on vi is based on ex is based on ed. Each has extended the capabilities of its precusors (and for me to use a canonical vi such as nvi is absolutely painful).
Understand that an you're a long way to understanding the power of Linux.
Vim requires so much documentation just to be usable. There is no GUI to hint at how to do anything. No toolbars, no application menus, no context menus or buttons. Vim's documentation is probably somewhat responsible for its popularity. I've never not found something I needed in Vim's documentation.