Vim ported to iOS
applidium.com
applidium.com
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)
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.
So, when your iPad is a laptop Vim is great!
If I remember correctly, iSSH hasn't been updated for quite some time now. Though I might be wrong.
Yes, and a lot more. I use Vim for all my text editing.
I used vim to write my latest blog post. It would have been (and will be) awesome to do that on my iPad instead.
http://yieldthought.com/post/12239282034/swapped-my-macbook-...
Also, ":Explore" and then "-", "-", "-"... works to browse the file system, or at least the parts allowed by the app sandbox
Try to find a few other apps on the App Store that you can exit from within the app, to get a sense of just how much of a "guideline" this really is.
Maybe they got a pass since ":q" is a basic Vim command. People are going to type it - what should they do instead? Nothing?
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.
Emacs a mountain of a mole-hill, that one.
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 mean, you're almost never offline these days, so local storage can't be it, right?
I suggest mapping 'jj' to ESC rather than '\'
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.
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.
I just right now remapped caps-lock to control and use CTRL-[ to escape instead.
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.
Great effort!
The font is pretty ugly too - I can't easily tell the difference between q and g.
However, it is a neat hack, if not very usable.
However, I can't actually figure out a way to do so; ":set guifont" doesn't appear to work.
[1]: https://github.com/applidium/Vim/commit/be572d759e857de58453...
:e /etc/passwd
It's read only, but still, omgwtf.
:dir doesn't seem to work.
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
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?
Besides once you can edit faster, it's surprising how your "speed of thinking" also improves dramatically :D.
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.
I'm constantly mortified at how rarely my co-workers/employees use vim macros. I make vim do the hard parts for me.
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.
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.
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.
Sadly, most of the network stuff is not or only partially implemented yet, such as clone and push. They have an example for 'fetch', though.
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 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)
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.
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.
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.
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.
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".
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.
I wonder if it supports plugins.
nnoremap jk <esc>http://www.pieceable.com/view/bundle/p/a2a89/com.applidium.V...
As the docs say, if you want to leave insert-mode, you have to use the '\' key since there's no ESC.
"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."
source: http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...
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
is so funny it hurts! Still, A for Effort.
I guess running a terminal locally causes some pain too?
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.
I imagine _intuitive_ navigation through the FILE SYSTEM will come shortly.
Namely: 90 degree angle on the elbow joint while making sure you don't slant your wrists up to reach the keys.
And no, it doesn't.
I think I'm crying.