Textadept: fast, minimalist, and Lua-extensible cross-platform text editor
foicica.com
foicica.com
If there was a screenshot without this (is there a terminal version?), I would regain interest. Screenshots are important especially to people like me who may or may not care. They're the fastest way for a potential user to answer the question: is this worth caring about at all.
Some questions you can answer with screenshots:
- Does it run on my platform?
- Are there any glaringly ugly things about it that will be a dealbreaker?
- Is it more beautiful/cool than what I'm already using?
- To what extent can it be customized?
- What kind of people are using it (if you have user screenshots)?
buffer.v_scroll_bar = false
Scrollbar issue is with my XFCE theme, not textadept.
> If there was a screenshot without this (is there a terminal version?), I would regain interest
Gnome terminal, windowed: http://i.imgur.com/Dfh6o.png Gnome terminal, fullscreen: http://i.imgur.com/6yoil.png
> Does it run on my platform?
Runs on Windows, Linux, and MacOS.
> Are there any glaringly ugly things about it that will be a dealbreaker?
I don't see any.
> Is it more beautiful/cool than what I'm already using?
Well, it depends on what you find more beautiful/cool :) For example, it's similar to my current GVim setup: http://i.imgur.com/djaLS.png
> To what extent can it be customized?
It seems that most of it is written in Lua (except the core), so it seems pretty extensible http://foicica.com/textadept/11_Scripting.html
> What kind of people are using it (if you have user screenshots)?
Can't help you with this :)
Looks good otherwise. Not to my taste, but it is refreshing to see a new text editor that actually seems like it was written by someone who understands the variety of use-cases of text editors.
http://img267.imageshack.us/img267/4600/screenshot20121119at...
The save dialog is standard GTK as well, not OSX.
A bold claim to make when your competition includes Vim and Emacs.
Is there some kind of feature comparison somewhere? Or any particular highlights? The feature list is a nice start, but basically what I would expect of any decent editor anyway (except for code completion).
That being said, I did have a quick look through the Textadept manual, and there are quite indeed a few useful and unique features... Whether or not this indicates "unparalled" extensibility though, is another matter all together.
I don't think even most Vim fans would claim vim is "as extensible" as Emacs -- while maybe on paper -- not really. I prefer Vim, but it's hard to argue with the sentiment that "Emacs is a nice operating system".
Still with proper support for Lua, I suspect it might be forced to do a lot of the same things Emacs can be forced to do (such as email, for instance). Not sure if I want an editor that does all that.
Yes, I'm aware Vim can be made do a lot of stuff like that as well, I just don't think quite as many users actually enjoy using Vim like that -- as does Emacs users. I might be wrong of course.
Vim fan reporting. Apart from async(which Vim can't do), Vim is as extensible as Emacs in letter and spirit. Considering that you are vowing vim allegiance, I think tpope's plugins would have made it pretty obvious how extensible vim is.
> Still with proper support for Lua, I suspect it might be forced to do a lot of the same things Emacs can be forced to do
Again, async. Vim can't and won't do async. If vim starts supporting async execution, vimscript will wrap existing imap, smtp implementation and update the ui. I am guessing emacs does the same. If it doesn't, I am in complete awe - not by the extensibility but by the pointlessness of implementing smtp server in elisp.
without knowing Emacs how could you claim that.
Actually Emacs comes with smtp written in elisp[1] and IMHO Emacs is more customizable than Vim. But I won't say Emacs is better than Vim.
Peace..
[1] http://www.gnu.org/software/emacs/manual/html_node/smtpmail/...
Where did I say I don't know emacs? I don't know what is emacs's mail support implemented in doesn't mean I don't know emacs.
> Actually Emacs comes with smtp written in elisp[1]
I said:
"If it doesn't, I am in complete awe - not by the extensibility but by the pointlessness of implementing smtp server in elisp."
Implementing a smtp lib that talks to a smtp server is different from implementing a smtp server.
> IMHO Emacs is more customizable than Vim.
I have used Vim and Emacs for considerable length of time. I ended up choosing Vim and use it as my main editor. I have read source for many plugins in both Vim and Emacs. Vim is as extensible as Emacs. I won't debate how elisp is better or worse than Vimscript, because that doesn't affect extensibility.
If we agree with "extensibility depends on how much/many internals exposed to its extensible language", I would say Emacs is more extensible than Vim in comparison to their current status.
Agian It doesn't mean Emacs is better or worse than Vim. I think we are heading to endless discussion. I will stop here.
I've even written a language [1] that compiles to Vimscript because it sucks so bad.
Vimscript is similar to JS. Both have lot of pitfalls, and don't have traditional OOP. The reason JS exists is to script the browser, and vimscript exists to script vim. Coffeescript attempts to add syntactic(and sometimes semantic) sugar to JS. Riml seems to be in similar vain. Despite that, there are people who would still work on dicts rather than using the Ruby style classes your script seems to introduce. == has the same rules as == in JS - don't, unless you are really sure.
I like the default scope thing your language does, but I feel a developer should at least know vimscript variable scopes. Your classes are nice syntactic sugar, but I am used to Lua and JS plain old object based oop, and I am Ok with using OOP that way.
Vimscript has its warts(like JS) but does its job. Some people swear by Coffee and disavow JS; some people prefer JS. I don't have a fanatical position - I use both Coffee and JS. Your extensions look good - I will play with it some.
Generally, when I take a position defending Vimscript is when the person talking about "how vimscript is devil's spawn" has 0 ideas about Vimscript and is regurgitating what he read somewhere. I don't deny the warts(== vs ==# vs ==?), but I do deny the fact that somehow Vimscript makes the job difficult. In fact, if you know Vim, you don't have to learn tons of api functions(though you still need to learn some). You directly use the vim commands(is there a better word for it?). I prefer it vastly over learning a new set of artificial api calls("normal! `<v`>y" over some crappily named copy_marks....). Oh, you don't know Vimscript and you find it difficult to read? Tell me more about how every language in existence should read easy to you(not directed towards you; general comment)
> Apart from async(which Vim can't do), Vim is as extensible as Emacs in letter and spirit. Considering that you are vowing vim allegiance, I think tpope's plugins would have made it pretty obvious how extensible vim is.
I've not come across anyone advocating something along the lines of mush or gnus for vim(x) though. That is more what I meant -- I use Vim as "just" an editor.
Also looking at the code for pastie.org support in Vim and Emacs -- I would definitively prefer extending Emacs -- and I don't even like Lisp much. I suppose one could use another scripting language to extend Vim, such as Python -- but my impression is that the focus is a little (note not a lot) different between Emacs and Vim wrt. these type of extensions:
http://emacswiki.org/emacs/pastie.el https://github.com/tpope/vim-pastie/blob/master/plugin/pasti...
I do use pathogen, though: http://www.vim.org/scripts/script.php?script_id=2332
(x) Well, there is notmuchmail, which I suppose is somewhat similar. But as far as I understand mush is well ahead in many respects.
[1] http://www.vim.org/scripts/script.php?script_id=1624
[2] http://www.vim.org/scripts/script.php?script_id=2219
edit: formatting, spelling
To each its own, but tpope's pastie is doing a lot more than the emacs pastie. Compare the usage https://github.com/tpope/vim-pastie/blob/master/doc/pastie.t... to emacs http://emacswiki.org/emacs/pastie.el
tpope's pastie supports registers, regions, windows, buffers, files and snoops the login cookies from firefox. If it were to be reduced to pasting whole buffer, region and reading a paste, it will be incredibly simple.
See http://www.gnu.org/software/auctex/img/preview-screenshot.pn... for an example.
The code base is actually small and mostly written in Lua, so that it is actually possible to change the editor to your liking.
When I say extensibility, that's not what I mean. Code is available and it's small and mostly written in Lua - that's all good. But I don't want to mess with core because then syncing upstream is a huge pain. The only interface I want to deal with the extension interface. I haven't looked at the api yet, but I am skeptic about the claims. Vim has vimscript, Emacs has elisp, sublime has python...Editors has been providing extension interface for a long time.
http://nilnor.github.com/textredux/tour.html
No need to sync back upstream.
I agree with you that 'Unparalleled extensibility.' might be a bold and difficult to actually prove claim.
The canon doesn't need my changes but I need the canon changes. If I change the core, I will have to selectively merge whenever updates happen. It's great that core is small and can directly be changed, but I think that should be advertised as the last resort.
Textadept does not appear to have multiple select features on par with SublimeText. But then again who does?
And it doesn't use Exposé for windows, at all. That's a shame. I'd like to have several editor windows open, with separate buffer lists.
I like where they're going with it, but are they there yet? Meh.
> ....0.osx/Textadept.app/Contents/Resources/core/file_io.lua:143: bad argument #1 to 'iconv' (string expected, got nil)
Open file (M-S-O) does nothing.
Tried C-u (snapopen) and get a similar iconv error:
> pt.app/Contents/Resources/modules/textadept/snapopen.lua:67: bad argument #1 to 'iconv' (string expected,
I am executing the textadept-ncurses.osx file. Thx. Please note that <backspace> is acting like a TAB but C-h is working correctly.
Not meant as an attack or anything. Just an observation and possibly a 'marketing' suggestion if you'd like more users.
edit: block commenting didn't even work when selecting it from the Edit menu.
http://foicica.com/wiki/comment-supplemental
Or install the Python language module:
Edit: why is this not there by default? I'm not sure any developer would not want a block commenting function...
http://foicica.com/wiki/lua-debugger
The styling and symbol choice is configurable.
Not sure how inline diff works though (for deleted lines), do you have an example in another editor?
> "The version of Textadept for the terminal requires only ncurses."
I notice that some keyboard bindings[1] are different in "Terminal"-mode (I suspect that means in terminal on GNU/Linux and possibly *BSD, but I suppose it might include MS Windows cmd.com (if supported) and OS X Terminal as well) -- as compared to the GUI-variants (MS Windows and OS X appear to just substitute control for command - while the "Terminal"-variant uses e.g. meta-control-n, rather than just meta-n or control-n for new file).
I think I'll stick with VIM, thanks. Still having another powerful editor available isn't a bad thing.
[1] http://foicica.com/textadept/api/_M.textadept.keys.html#Key....
It might also be possible to tweak the GTK layouts for the OS X version.
In the meantime, I guess I'll go look at the source and see what kind of changes would need to be made to use Cocoa in place of GTK on OS X.
But your story was cool too...
Especially when this is most likely to integrate in Linux, given that it will follow your GTK theme.
It's not vim. That alone will be a selling point for a vast majority.
> I didn't realize a vast majority were nincompoops.
I am a long time vim user. Where do I get in line for obtaining my free-with-vim pretentiousness and douchbagginess? Or it doesn't come with Vim and it's just you?
You are a fucking asshole.
Ha, ha. Just kidding. You just don't get my flippant sense of humor.
Sorry. This doesn't work for me. Being facetious is different from being a jerk.