Vim is for coding. How does this work out on the iPad?
Does one edit remote files locally, and compile/run remotely? (the benefit is the editing feels instant - no keystroke latency.)
Or has Apple let up on the "no coding for you!" iPad/iPhone terms? (I thought they would eventually, once their dev environment is firmly established - and they'll have to, if/when they adopt iOS on their {lap,/desk}tops - but maybe today is not yet that day. iOS devices sell macs as dev machines)
Vim is for coding. How does this work out on the iPad?
With a bluetooth keyboard and a charging dock or a stand, iPad is a great platform for Vim coding.
Does one edit remote files locally, and compile/run remotely? (the benefit is the editing feels instant - no keystroke latency.)
With Dropbox support this would be possible.
Or has Apple let up on the "no coding for you!" iPad/iPhone terms?
There is no such term. The term used to be that you cannot bundle a compiler with your app, but even that has been lifted recently with Lua interpreter embedded in many games.
Can even connect to an Amazon instance or similar. There was a submission a while back about someone who did this for a month (IIRC), but the editor was on the remote machine.
I can see two likely scenarios why this got passed:
1. The reviewer has never used vim. As someone unfamiliar with vim, it never occurred to them to type :q, and thus they never saw that behavior.
2. The reviewer has used vim before, and knows how it works. With that familiarity, the reviewer understood that :q quitting the app was the behavior that users would expect.
This may be the one-in-a-million chance to disregard that guideline. A big rule in interface design is to do what users expect. In Vi/Vim, this means quitting on :q. Assuming that this is non-standard enough that Apple would go find somebody who knows Vim to handle the review, that person would (and obviously did) know this.
How many apps need an exit button? Just because you look around the App Store and don't see a bunch of apps with exit buttons doesn't mean it's because they aren't allowed. It never even crossed my mind to put an exit button in my apps because it's not a use case for my apps. I'm sure it's the same with a majority of the other apps.
Especially as the guideline is clearly there so as not to give users the misleading impression that the app's crashed. That's obviously not the case when a vim user is using the expected command to close the program.
If it can sync .vimrc, could it also sync a directory over iCloud? That would be amazing. I'm a die-hard Emacs user, but this would be enough for me to use Vim for at least some work.
I've been wanting vim support on the iPhone for a while.
I actually think it's a big thing that would work well on the iPhone. The whole point of vim is that, with only a few keys, you can navigate anywhere you want extremely quickly. Most of the limitations of the iPhone are things like "can't see many keys at once", and "hard to go to specific lines by dragging your finger around the screen", etc. Vim on the iPhone can fix all that.
Haven't seen this app though, off to play with it. Hope they did a good job :)
I always thought the difference was personal preference, but there is actually 1 good reason to use "jk". If you get used to pressing "jk" all the time, you'll probably end up using it in Normal mode as well as insert mode. "jj" will move up 2 rows in Normal mode, while "jk" doesn't do anything. Therefore you can use "jk" as a reflex every time you get to the keyboard, and it won't screw you up.
Yes, except ctrl-c moves you off home row, which I wanted to avoid.
Also, technically, ctrl-c is not the same as escape - it also sends a cancel signal. I actually have no idea what the practical difference is, I just know that some commands treat it differently.
It doesn't check for abbreviations and doesn't trigger InsertLeave, which essentially means that any pending command is aborted, but you're totally right about not leaving the home row.
I just right now remapped caps-lock to control and use CTRL-[ to escape instead.
Even if you're online, the connection may have much more latency than you want to deal with. Depending on what you're doing a split second of latency can mean a lot.
Nice work. It would be nice to add a few extra keys like you were suggesting like "tab", "ctrl" and "escape". Maybe slide them down from the top when you swipe the edges.
Another comment, this looks great for editing a fresh file on the run, but it would be nice to ssh into a server with existing files.
As explained on the splashscreen, they've remapped that to backslash. I suspect it'd be much more useful with a BT keyboard - lack of ctrl and tab for a start.
The font is pretty ugly too - I can't easily tell the difference between q and g.
I'll check this out app out. I've tried using the touch screen keyboard on an ipad thru ssh and using vim. it was unbearable, to say the least.
i ended up getting an asus transformer prime that has a keyboard dock and the keys can be rebound to your like (esc, ctrl, etc) and it's the closest to the "real thing" experience i have found on a tablet
Yet another emacs/vim article, and I always look for an excuse to get excited but never can.
It seems that the speed at which I think/code is much slower than the speed at which I type. So I can't imagine that I would benefit from skills in emacs/vim-fu.
Is this preconception valid, or can anyone debunk?
VIM is not only about typing. It's about editing, which involves making a small change in one place, then navigating somewhere else, and making another different small change etc. This is where VIM is unbeatable, because of ridiculously many fast ways to navigate and edit intelligently (in a very small amount of keystrokes). You don't have to type 120 WPM do be faster in VIM, but if you are a fast touch typist, you can get insanely fast in VIM.
Besides once you can edit faster, it's surprising how your "speed of thinking" also improves dramatically :D.
Agreed. Navigation through a file without using the mouse or arrow keys greatly speeds up misc. edits in a large tree of files.
Other upsides are the ability to delete text without the backspace or delete key, and to perform more complicated operations on a file, such as full regex search-and-replace, macros, and so on.
Really what it boils down to is a powerful text editor that lets you keep your hands on the keyboard at all times- which of course is not appropriate for all tasks, but very useful for many.
This is a huge deal, and you've done a great job expressing it. I definitely find that I think faster as a result of being a vim user / being in vim. Since most of the actual editing gets thrown to muscle memory, all I have to do is think 'gosh it'd be nice if that refactoring happened' and it does, while I'm on to thinking through the next step.
I'm constantly mortified at how rarely my co-workers/employees use vim macros. I make vim do the hard parts for me.
It's not so much about the speed at which you think as about how quickly you can execute the changes once you've thought of them. I find it discouraging to have to fight my editor once I've thought of the change I want to make. Also debugging speed counts too. I find there are a number of "oh I should tweak that changes" which don't really require much thought.
This is a circular argument (or some sort of thing like that), but if you ever find yourself at a *nix command line prompt and need to edit a file, you can be certain that vim will be available. Basic familiarity with it can be helpful.
Personally, I used to write a ton of perl inside Vim as a student, but these days I'm in VS all the time, and only use Vim like I would use Notepad - when I want to do quick edits in a file that isn't worth the heavy handed-ness that is starting my IDE.
I'm like you - I spend more time thinking about my problems, and typing them isn't usually a hindrance. If I find that my typing/keyboard navigation speed is holding me back, it's a sign that I designed myself into a corner where I have to write a ton of boilerplate/repetitive code.
> but if you ever find yourself at a nix command line prompt and need to edit a file, you can be certain that vim will be available. Basic familiarity with it can be helpful.
True, but I've been getting by for the last 20 years with little more than 'i', 'x' and ':wq' (or ':q!') for changing system settings. The point of mastering vim as an efficient code editor is far beyond what you need to get your nix settings sorted.
If you're willing to spend $99, viemu is a wonderful vim emulator for Visual Studio.
For a little more you can get it for SSMS, too. What's really fun is highlighting stuff with visual mode and just hitting F5. Need to run a subquery? Get the cursor somewhere in there and vi( F5. And macros sure help with repetitive sql constructs.
Once you get used to a good editor (Vim or, for me, Emacs) you don't have to think about how to edit a file, even you're doing something relatively complicated: it becomes a natural, almost instinctive action. This not only increases the speed you enter text or navigate, but also reduces the friction when actually entering your thoughts into the computer.
Definitely. Unfortunately Git is GPL, and given the trouble we went through with VLC we decided not to work on that feature. It's definitely sad though.
Other way around - the app store does not allow distributing the source along with the app. So, strictly speaking, publishing GPL software in the App Store is in violation of the GPL.
If you - as a rights holder - are okay with having the source downloadable at another location, you can definitely publish GPL software using the App Store. Case in point: Battle for Wesnoth.
You do not have to distribute the source code of a GPL application with the binary. You merely have to make it available. For example, I have an Ubuntu Linux install CD with lots of GPL binaries and no source. It's perfectly legal for that binary-only CD to be distributed.
AFAIR from the VLC case, software distributed on the AppStore has extra restrictions on the user (You can only use it for personal reasons, you can only install (use?) it on 5 (or so) machines, etc.) GPL software cannot be distributed under these extra clauses.
If you are the sole programmer & copyright holder, then you are free to relicence/release your work under some other licence that is OK with these.
However if you are incorporating other GPL software (like in the VLC case) then you do not hold the copyright on that software, so the person who does have copyright on it is letting you distribute the software so long as you agree to certain terms. You cannot distribute someone else's GPL software on the Apple App Store because you would not be meeting the GPL requirements of "do not place any other restrictions on the software".
I delibrately phrased it as "Apple doesn't allow GPL" because this is not a technical problem, but a legal/contractual/business problem. Apple could choose to allow GPL. They do not. Microsoft, who called the GPL cancer, allow GPL Apps on Windows.
Okay, thanks for the detailed explanation and the reasoning behind that sentence. Yes, Apple did not take any special action to support GPL in the app store.
Personally, I find it surprising that Apple, which leveraged open source to a huge effect and took stewardship of some high-profile OS projects (webkit, llvm/clang, CUPS), but allows other companies to position themselves as "open source friendly" alternatives. Especially as one of those companies is Microsoft.
Apple did not take any special action to support GPL in the app store.
You do not need to take any special action with any operating system to get it to support the GPL. What Apple have done is done special action (lots of EULA/contracts/etc.) that explicitly disallow the GPL.
The reason (I think) Apple are explicitly disallowing the GPL is because it would be incompatible with the DRM type systems that Apple use. It's more a case of 'If Apple distribute GPL software on their App Store, they might have to give away the DRM keys and allow anyone to run any programme on their iPhone'. That situation is something Apple don't want.
GPL programmes are still allowed on OSX obviously, and I think some of Microsoft's mobile and/or app store thingie explicitly ban GPL as well.
Yes, you do (sometimes) have to take special action to support the GPL. For example, Ruby recently changed its license to allow the bundling of readline 6 with MRI. This was a distribution problem as well.
Show me the places where Apple EULA "explicitly" disallows the GPL (and not just includes things that are incompatible with the GPL). There certainly is GPLed Software in the app store, even with a notice included (see Battle of Wesnoth). If it was explicitly forbidden, that would not happen.
My interpretation is that Apple just doesn't care. The want Apple-signed code on their devices and if your license doesn't allow signed code, they won't help you. This by itself is sad and I would very much hope for that to be different, but not "explicitly disallowing".
I think MS were the ones that explicitly mentioned the GPL.
Apple do not explicitly mention it, however they have chosen to add extra restrictions to their licence, which goes above and beyond a normal "Download software from this web host". Explicit clauses that make the GPL incompatible are the same as "explicitly banning GPL apps".
The GPL is a massively popular licence, I believe Apple would have considered it. They appear to have rejected it.
Also, you don't have to make it available forever, I think the GPL says you only have to do it for 3 years. So you don't have to worry about someone in 50 years demanding some source code.
Does the App Store explicitly disallow bundling the source code inside the app? What if you added a .zip with the source into the app, and on app startup you copy the .zip out of the Application directory into the app's Document folder, which is accessible via iTunes (as long as you set the appropriate flag in the app descriptor plist to enable document sharing)
Bundling of source code with binaries is not required under the GPL. You can have it on your website. However the App Store EULA etc. are incompatible with the GPL (cf. http://news.ycombinator.com/item?id=3489115)
"You may not copy (except as expressly permitted by this license and the Usage Rules), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, or create derivative works of the Licensed Application, any updates, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or to the extent as may be permitted by the licensing terms governing use of any open sourced components included with the Licensed Application)"
I assume this is what makes the LGPL okay to use? (LGPL explicitly requires allowing reverse engineering of the entire application, even the non-LGPL parts)
(I don't know much about iOS development, so will take your word that this is the standard licence that software on the AppStore goes to the customer under)
There are numerous parts of that licence that are incompatible with the GPL and other Free Software/Open Source licences:
e.g.:
This license does not allow You to use the Licensed Application on any iPod touch or iPhone that You do not own or control, and You may not distribute or make the Licensed Application available over a network where it could be used by multiple devices at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Licensed Application.
If $COMPANY (e.g. Canonical gives me a Linux kernel) gives me a piece of GPL software, I am allowed to install that on numerous devices, I am allowed to sell that software myself and keep all the money myself, I am allowed to install that software on my friend's computer. All of these actions are prohibited by that Apple Licence, and hence in order for Apple to give/sell me a GPL programme they would have to change that.
Apple have chosen to get around this situation by not giving me any GPL licenced software.
There is, though. I don't understand... personally I've been using a combo of iSSH into my own iphone. ~/ is located at /private/var/mobile and there's no latency (you ARE connecting to localhost). Git and vim installed means that basically, you can be self sufficient from your iPad/iPhone, without even needing an additional workstation to SSH into. Hell, even Python and Ruby can be installed on the jailbroken iphone. It's basically a portable POSIX-compatible system, after you install all the necessary packages (network-cmds for ping, for example) you're all set.
"Unfortunately, without an escape key it’s not possible to leave insert mode. That’s why by default the backslash key (‘\’) is mapped to the ‘Esc’ key. You’re free to overwrite this setting by unmapping the backslash key."
That's great for browsing but I can't picture coding in an editor where I need to stop and look for common command keys. At the moment vim is efficient because [esc]10dd or something but it's just not viable without a keyboard. For reviewing code or making quick edits however this could be incredible.
Why? It's quite convenient for my left-hand pinky on nearly every keyboard that I use, and I've picked up the habit of doing periodic `jk` movements as I'm examining some code. I tried the `jk` combination that some people recommend, but it doesn't work for me.
I've never used a keyboard where escape was convenient to press. I personally use inoremap so 'jk' only does something in insert mode, I hit jk repeatedly all the time in normal mode while I'm thinking.
I think you have to slide two fingers to opposite sides of the screen for they keyboard to split. (At least that is what was showed in the iOS 5 videos, I don't have an iPad)
Apple pulled it due to it being copyright infringement. The VLC author released their code under the GPL licence, and Apple do not distribute software on the AppStore in a way that meets the GPL, and hence they were in breech of the licence and could not distribute it.
ahahahahahahahahaha. This is hilarious. The author of vi says:
"It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.
The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens.
So they could have funny commands with the screen shimmering and all that, and meanwhile, I'm sitting at home in sort of World War II surplus housing at Berkeley with a modem and a terminal that can just barely get the cursor off the bottom line.
It was a world that is now extinct. People don't know that vi was written for a world that doesn't exist anymore - unless you decide to get a satellite phone and use it to connect to the Net at 2400 baud, in which case you'll realize that the Net is not usable at 2400 baud. It used to be perfectly usable at 1200 baud. But these days you can't use the Web at 2400 baud because the ads are 24KB."
In other words, the PRIMARY design constraint with VI was how long it took to update a screen. All these keyboard modes and so on are about getting as little over the wire as possible while still having a full screenful to look at locally.
Sure, this idiom actually is very useful on a locally-running vi too (not to mention vi over an ssh), the keyboard commands are a powerful way to interface with the text.
But the idea of porting this to a machine that 1) will run vi locally (not on the remote machine through an SSH session), and 2) has no keyboard
no, not at all. In fact I administer my own computer with vi (meaning vim), from a local terminal instance.
But the fact remains that porting an app like that to a touchscreen device meant to hide systems administration (as iOS does) is getting so far BOTH from the history of vi AND its most prevalent current usage.
That doesn't mean it's not very cool. I just thought it would be interesting to reflect on the background.
I guess what some people say about a bluetooth keyboard...almost makes this somehow useful. Still, that keyboard is not always going to be there.
It makes more sense than many other editors, since you get a ton of functionality without modifier keys thanks to the modal interface, but it's still way better with a bluetooth keyboard.
Just like with a standard keyboard you need to get yourself in a decent ergonomic position before doing prolonged iPad typing. The temptation is a lot stronger on the iPad to fudge a little on the positioning which can very quickly be disastrous.
Namely: 90 degree angle on the elbow joint while making sure you don't slant your wrists up to reach the keys.
Does one edit remote files locally, and compile/run remotely? (the benefit is the editing feels instant - no keystroke latency.)
Or has Apple let up on the "no coding for you!" iPad/iPhone terms? (I thought they would eventually, once their dev environment is firmly established - and they'll have to, if/when they adopt iOS on their {lap,/desk}tops - but maybe today is not yet that day. iOS devices sell macs as dev machines)