If you're curious, Emacs does all this—and more—with various C-h commands. If you want to see a full list of these, start with
C-h ?
Here are my favorites:
If you want to see a specific keybinding, like checking what C-w is bound to:
C-h k C-w
If you want to see the documentation for a function:
C-h f function-name
If you want to see details about your current mode:
C-h m
This is incredibly useful because it lists all the mode-specific keybindings. That's how I learn how to use new modes!
If you want to see or interact with a variable:
C-h v
If you want to see something where you remember just part of the name:
C-h a *regexp*
(a stands for "apropos")
If you want to see the incredibly detailed manual for Emacs or all of the info manuals on your computer:
C-h r
C-h i
If you want to see info about your input mode (how do I type ℕ in TeX-input-mode?):
C-h I
Actually, for that one, I have another handy trick: copy and paste an ℕ into your buffer, go over it and use
C-u C-x =
which brings up detailed information about the given character... including how to type it in your current input mode (if applicable). This also includes useful info like its Unicode designation and category.
I've found all of these tricks exceptionally helpful when learning more about Emacs. They also help me overcome my fear of memorization: its so easy to look stuff up, I don't have to bother. Then, if I use something enough, I remember it without especially effort. It's like a cache in my mind.
Better still, if you want to execute a command and if you approximately know what it could be called as, you get list of potential commands in an alternative buffer, by Alt-x, and then start typing part of the command. This I feel is great to explore commands as you need them, before binding new keys to those commands.
Without getting into emacs vs vim war, the author would be impressed in a bigger way once the emacs documentation is explored!
I'm sure I would be. I actually like emacs very much, and used to use it in my uni days. These days though, I like the modal way of editing more.
I think emacs' documentation does come close but I still think Vim's help is much more easy to use and to search for. For example, a new user coming to emacs can't search for help on C-x C-f by invoking C-h C-x C-f
> If you want to see the incredibly detailed manual for Emacs or all of the info manuals on your computer:
And you really should want seeing your info manuals - they are incredibly high quality resources for the most part. Emacs, Emacs Lisp, Org Mode, Magit infos, for example, are all full fledged books, properly split into chapters, filled with all the details you'd ever need. They are indexed and searchable and they are easy to navigate.
Just install info+ and some related scripts before starting with infos - this will give you syntax highlighting and colors in the info viewer. I don't remember if bookmarks are part of the vanilla Emacs, but if not you probably would want to install some bookmarking plugin too. After that is done it becomes the most pleasant technical reading experience ever.
I think if the idea is to help newcomers with Vim, this is the wrong approach. Nobody tries to learn something new by checking out what a random key does, using :help X. When I was trying to learn Vim, the most useful info was actually search results for "how to do X with Vim", because everybody knows A) another editor, probably B) what they want to achieve. After that you slowly discover features one after the other, which can only happen by using the editor a lot. It's good to have a "help X" around, but most of the time, if you're starting out, you don't know that X is what you need in the first place.
People learning git don't start with typing "git rebase --help" just to see what it does. You learn to add, commit, push, (probably from a tutorial) and then go from there.
Hence vimtutor. The "going from there", in git, does consist in part of "git rebase --help" or "man git-rebase", which are roughly equivalent to :help.
Not to start with no. But as I started to become familiar with Vim enough, I realized I reached for :h more than go search google, and for the most part, I found what I was looking for in Vim's help pretty easily and much faster than google. Vim's help is easy enough to use that you can `:helpgrep topic` or just `:help top<tab>` to list all the help topics and go from there.
Sure you can achieve the same thing by searching online. However, I believe that reading Vim's help motivates you to learn more commands and be more efficient with it. There's so many things in `:h motion.txt` that online articles don't mention and I would probably never come across them.
Similarly, with Git, I did learn to add, commit push but then I learned to reach for `git help topicname` if I want some documentation on that topic name.
> 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.
The documentation is so good, you need a beautifully crafted website with english sentences, standard typography / web styles, and acommpanying visual diagrams...simply to learn how to use the "help" feature.
Well I wrote this partly for a friend who wants to give Vim a try. I noticed if I told him to read the help on a topic, he would just google the question himself (maybe he doesn't like the terminal interface to read the help doc).
I've also noticed some people will manually go search a plugin on Github just to read the plugin's doc folder, when the same help doc is available right inside vim!
So I thought I would help explain why Vim's help is so awesome that people should use it more and using it more means that you learn more things about vim.
But I appreciate that you like my website, thanks! :)
The tricky thing about vim help, to me, is that it feels nearly impossible to navigate until you're already pretty comfortable with moving around in Vim. Making all of the most basic things so different from the WYSIWYG editors most people know generates a huge mental load at first, just trying to get the most basic things done.
When I started using Vim, I found for a while that I couldn't stand writing code with it for more than an hour or so, because it was too difficult to think about what the code is doing and how to use the Vim commands to actually edit the text at the same time. I think it took me several months of poking around and training myself in basic movement commands to get to where I could actually work in it effectively.
Does no one check their page layout on anything but 4k resolution any more? Here's what the page looks like on one of my 1280x1024 screens: http://i.imgur.com/w6WXYF6.png
Since the screen is physically on my left, it's very annoying to try to read the text.
Hmm, thanks for that, I'll see what I can do. I don't have a 4k monitor but I do have a retina MBP. I tested it on mobile and the retina MBP but I don't have access to a lower resolution computer (hehe).
I use vim (after years of being a happy emacs user — switched due to RSI), but I've never liked its help system. Compared to emacs, it's incredibly hard to navigate and it just doesn't have anything as powerful as C-h k (what does this key do?).
What do you feel that Vim's help in that area is lacking?
I think searching for a key binding is pretty straightforward with `:h {key}`. I like how it's short and simple they are most of the time too so you can read and get back to whatever you were doing.
I just find Vim so much faster. There is a learning curve (http://www.thejach.com/imgs/vim_learning.jpg), but once you're over that curve, you can't stand regular text-editors anymore! Fewer key-presses and your hands not needing to leave the keyboard (or at least, infrequently) = fast.
I should add, I don't just use Vim, I use the IdeaVIM plugin for PHPStorm and Webstorm, for development zen. :-)
If you want to see a specific keybinding, like checking what C-w is bound to:
If you want to see the documentation for a function: If you want to see details about your current mode: This is incredibly useful because it lists all the mode-specific keybindings. That's how I learn how to use new modes!If you want to see or interact with a variable:
If you want to see something where you remember just part of the name: (a stands for "apropos")If you want to see the incredibly detailed manual for Emacs or all of the info manuals on your computer:
If you want to see info about your input mode (how do I type ℕ in TeX-input-mode?): Actually, for that one, I have another handy trick: copy and paste an ℕ into your buffer, go over it and use which brings up detailed information about the given character... including how to type it in your current input mode (if applicable). This also includes useful info like its Unicode designation and category.I've found all of these tricks exceptionally helpful when learning more about Emacs. They also help me overcome my fear of memorization: its so easy to look stuff up, I don't have to bother. Then, if I use something enough, I remember it without especially effort. It's like a cache in my mind.