31–40 of 53 posts
Any one know how do I search for a shortcut in different modes? For example, 'ctrl-r' in normal mode means redo, in insert mode means paste from register. However ':h ctrl-r' only shows the help for normal mode.
`:h help-context` tells you what you need to append for each mode. So for ctrl-r in insert mode would be: `:h i_Ctrl-r`
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).
F12 and then esc in chrome and you can test on various devices.
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
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…
> it's kind of inherently "explorable" 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")…
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.
Earlier quoted context omitted.
> it's kind of inherently "explorable" 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")…
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…
vlm@dev:~$ apropos permissions
access (2) - check real user's permissions for a file
chmod (2) - change permissions of a file
eaccess (3) - check effective user's permissions for a file
euidaccess (3) - check effective user's permissions for a file
faccessat (2) - check user's permissions of a file relative to a directory file descriptor
fchmod (2) - change permissions of a file
fchmodat (2) - change permissions of a file relative to a directory file descriptor
ioperm (2) - set port input/output permissions
WWW::RobotRules (3pm) - database of robots.txt-derived permissions
vlm@dev:~$
Earlier quoted context omitted.
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…
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.
> 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.
The Vim GUIs have all those things, try gvim on Windows or MacVim on OS X. Though admittedly I turn them all off except for the context menus.
Earlier quoted context omitted.
Which also means no GUI to get in the way. 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.
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.
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 hel…
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.
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 hel…