71–80 of 83 posts
Suggestion about the website: Please include a separate section called "Screenshots". A lot of people directly click there to get a feel of the software before they download.
http://img267.imageshack.us/img267/4600/screenshot20121119at...
The save dialog is standard GTK as well, not OSX.
OK, so I find Sublime Text 2 extremely perfect for my needs... now how does this thing beat pure perfection? ;)
Earlier quoted context omitted.
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.
Uuurrgghl. Images in a text editor. I'm quite happy Vim doesn't support that.
See http://www.gnu.org/software/auctex/img/preview-screenshot.pn... for an example.
Earlier quoted context omitted.
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.
IMO you can't compare an editor to Vim/Emacs if it can't run in a console.
Earlier quoted context omitted.
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 t…
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?
Earlier quoted context omitted.
Vim is cool but... crufty. It seems like the point of this project is to be both extensible and simple/comprehensible. For that, there's nothing like starting from scratch.
and yet every single project to reimplement vim "cleanly" has failed. the only successful other implementation out there essentially ported the vim codebase directly to java. i can only conclude that vim has built up a tremendous amount of sheer value along with the cruft that is not easy to reproduce.
Earlier quoted context omitted.
> without knowing Emacs how could you claim that. 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…
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. [1] https://github.com/luke-gru/riml
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! `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)
Earlier quoted context omitted.
> 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…
> 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…
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.
Earlier quoted context omitted.
Uuurrgghl. Images in a text editor. I'm quite happy Vim doesn't support that.
Images are useful if you are authoring a math heavy document (and don't want to go back and forth between a previewer and the editor). See http://www.gnu.org/software/auctex/img/preview-screenshot.pn... for an example.
Earlier quoted context omitted.
I didn't realize a vast majority were nincompoops.
>> 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?
