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).
The fact that this has a small core of C and Lua, according to the website, is a much better selling point than "unparalleled extensibility".
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.
Textadept uses Lua as scripting language. Sublime Text uses Python as scripting language. Any hipster working on a text editor that uses Javascript as scripting language?
> I don't think even most Vim fans would claim vim is "as extensible" as Emacs
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.
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.
> 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.
> Although you might not want to debate whether Vimscript is better or worse than elisp, I don't mind. Most things are better than Vimscript.
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)
One part where emacs beats vim is the ability to embed images. Emacs + AucTeX is by far the best editing platform for LaTeX because auctex converts the math snippets into images and displays them in emacs buffer. It is possible to write the backend support in vim as well, but not possible to display the image inside the vim buffer.
I guess this is a difference in philosophy. I prefer to use a te t editor for editing all types of text: code, emails, tex markup, HTML markup, etc. Hence, for me, a text editor is better than a word processor. But I do like the convenience of not having to go back and forth between a previewer (PDF reader) and the text editor, and therefore like the fact that emacs allows embedding of imaging. (Not to mention the fact that none of the word processors can beat TeX output in terms of quality and flexibility)
> 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.
Well, pastie[1] might be one of the few "advanced" plugins I've considered using (the only one I've actually used is limp[2]).
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:
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.
Don't forget about Notepad++ (Windows only though) and Sublime Text (best text rendering I've seen yet), which I'd argue are also valid comparisons - yes, even to Vim/Emacs.
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.
> 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.
Understood. I think it is still useful to have a small core base that you can read and understand and adapt if you want to. Don't like the GUI open file dialogs? Someone did a text based interface:
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.
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).