Review: Textadept
yfl.bahmanm.com
yfl.bahmanm.com
For a while, you could only get ed on most *nix systems. Doesn't mean this couldn't become a new "standard."
Vague title? In what way? It's someone's review of why they're using Textadept. (or is this a case where HN changed the title after the fact?)
(Fast, flawless rendering, not relying on regexps for syntax highlighting, proper fullscreen, graphical UI instead of text-based, nicest extension language...)
* It's difficult to add new motions to vim. EasyMotion and Surround.vim are the only two real attempts I know of. EasyMotion gets by on marks while surround.vim is baroque.
* There's little/no context awareness built into the syntax highlighting/grammar files. Textmate's scope stuff is really the best feature of the editor. If the vim maintainers/community could decide on syntax groupings and a query system was added it'd be doable but I'm not really expecting it.
* There's limited context awareness built into the mapping system. ST's system is quite nice here.
* No support for multiple cursors. The support that's built into ST is fairly primitive compared to the multicusor whitepapers from MIT (I believe around 2000) which did generic editing stuff.
* No repl. This goes against the philosophy of the editor but having a repl is really convenient when doing lisps. Foreplay is sufficient but doesn't fill me with joy.
* I've wanted to set up what I call 'regions' in the file where one part of the file is a computed version of another. The obvious use case is xml tags where editing one tag name in the pair updates the other but I think it could be generic. I had more use cases when I was thinking about it but they're not coming to mind at the moment.
I think there is potential for interesting display/visualization stuff for the HTML based editors and integration into the runtime like Smalltalk environments. I'd also like to see some sort of AST manipulation server pop up and to provide IDE-like services in a cross-editor manner. Finally, I spent time with LEO in the early 2000s and while I hated the editing, the text node organization was interesting and I haven't seen a similar attempt elsewhere.
Don't get me wrong, there ARE new things in Vim that are unique/cool like conceal and I can do fun/weird stuff with UltiSnips which I haven't been able to do with other snippet systems. I doubt I'll move off any time soon but it's far from inconceivable.
Going back to the XML example. The contents of the ending tag are the contents of the first WORD of the starting tag. A syntax file could set up a region between the two so that changing one tag alters the other.
Similarly a syntax file could set up a one way region from function arguments to local uses such that altering the argument name updates the local uses.
It's possible to do this via AST manipulation at build time but I don't think it's practical.
As for motions, what kind of motions do you think are difficult to create? I have dabbed in creating a fundamental new motion for vim which is analogous to f but takes two characters instead, and it does not rely on f's implementation to work. You can see it here http://github.com/goldfeld/vim-seek
Regarding lack of context, I agree, but I can't say I've done enough vim plugin development to say whether I think it's beneficial or detrimental to vim to be limited so.
Regions do actually sound like something with an infinite number of advanced and creative applications (stuff like Emacs org-mode). Do you know of editors that have such a feature? I'd be crazy for that.
It's mostly text objects. Text objects for scope, variable references, etc. I think there are motions I have not yet discovered that operate on syntax trees. These are nonlinear the way surround is nonlinear.
I was introduced to multiple selection and generalized cursors when one of the DabbleDB guys implemented a generalized cursor editor. I thought it was awesome and did a bunch of research:
http://static.usenix.org/events/usenix01/full_papers/miller/...
http://scholar.google.com/scholar?q=related:7040sK6UgeAJ:sch...
After reading a bunch, I got around to thinking what I'd have to do to implement an editor that could handle generalized cursors based on my experience with vim and hacking on it.
I came up with the idea for an edit core consisting of motions as compositions of partially applied functions. Takes a position returns a list of ranges, applying the list of ranges to an operator produces an edit. The jump from there to regions is pretty straightforward. The system also provides a clear path to how keyboard mapping would work (along with stealing the context ideas from ST).
I'm unaware of an editor that works this way but I find it difficult to believe I'm the first person to think of this. If I can successfully maneuver my job into building web development tools, I expect to gut Codemirror and replace the core operations with these primitives as a top priority but I haven't gotten there yet.
For context sensitive stuff: You can do clever stuff with it. As an example, if you're in a JSON file, after an identifier, and you type a : the editor can automatically put quotes around the key if it's not already quoted. My intro to the usefulness of context sensitive keys was that the ruby textmate bundle would insert Ruby interpolation (#{|} with | for cursor) when you hit # in a string.
That all sounds terrific, and if you get to implement these ideas on top of web technologies (or anywhere else would still be half as good) I'd love to hear about and possibly contribute. Do you have a blog or twitter or app.net I can follow?
I'm on twitter and use the same username everywhere.
In particular, the multi-cursor mode is there : http://emacsrocks.com/e13.html The stuff you call 'regions' is available for a bunch of languages with org-mode and org-babel (http://orgmode.org/worg/org-contrib/babel/intro.html).
I strongly encourage you to give it a try...
I am just kidding, but seriously, every time i read such "i found a vim replacement"-articles, it turns out the author was not really a vim power user. It's strange, i know.
As in: "No TRUE vim user would think any other program was better!"
I would like to see articles like this demonstrate things that simply aren't possible in Vim (or something implemented with relative ease in comparison)
I also like the file chooser (I am on Mac OS X), much faster for me than the system wide.
That's my "first 4 minutes" impression.
And when you do, you don't need to run the editor on the machine where the file lies. What's missing is a nice integration of ssh into the editors.
On the wiki there was only one other theme available for the latest 6.3 release, so I tried an older Solarized theme, but TA crashes when I try to load it.
I feel having to press a keyboard shortcut to bring up the auto-complete menu is a step back in productivity compared to ST, but the built-in API help is a nice idea.