Textadept: fast, minimalist, and Lua-extensible cross-platform text editor(foicica.com)
foicica.com
Textadept: fast, minimalist, and Lua-extensible cross-platform text editor
http://foicica.com/textadept
82 comments
OK, so I find Sublime Text 2 extremely perfect for my needs... now how does this thing beat pure perfection? ;)
I had a similar question, and looked through the docs...
Textadept does not appear to have multiple select features on par with SublimeText. But then again who does?
Textadept does not appear to have multiple select features on par with SublimeText. But then again who does?
I tried using Sublime Text 2 but it has no ability to toggle automatic updating of changed files, unlike Notepad++ for example.
Yeah it does auto-update changed files by default, but you can enable the option to highlight unsaved files more prominently (should be on by default really) so such cases for me always show up on my radar immediately. And then a simple Ctrl+Z reverts the file to whatever was in that editor-buffer beforehand.
> Unparalleled extensibility.
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).
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.
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?
Chocolat is an editor for the mac - very similar looks-wise to TextMate - that uses javascript for it's scripting api, though I've never used it.
http://chocolatapp.com/
http://chocolatapp.com/blog/?chocolat-node
http://chocolatapp.com/
http://chocolatapp.com/blog/?chocolat-node
there are editors fully written in js c9.io Brackets lightTable
Pentadactyl lets you browse the web from the keyboard in a way that mimics vim, and does so using Javascript. So ... kind of.
FWIW the Zeus editor is scriptable in Lua, Python, JavaScript and TCL just to name a few.
> 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.
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.
> Vim is as extensible as Emacs in letter and spirit.
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/...
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/...
> 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 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.
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.
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.
[1] https://github.com/luke-gru/riml
I've even written a language [1] that compiles to Vimscript because it sucks so bad.
[1] https://github.com/luke-gru/riml
> 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)
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.
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.
See http://www.gnu.org/software/auctex/img/preview-screenshot.pn... for an example.
Well, I would use another — more suited — tool than a text editor for that kind of task. A word processor, for example.
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.
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
> Also looking at the code for pastie.org support in Vim and Emacs -- I would definitively prefer extending Emacs
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.
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.
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.
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.
If you're already running Java, jedit.org is worthy of your attention in this area. Extensible with Beanshell, or with plugins written in Java.
IMO you can't compare an editor to Vim/Emacs if it can't run in a console.
IMO Vim is highly overrated, and its only selling point is that it can run in a console.
Textadept is build on top of the Scintilla engine like Scite and Notepad++.
> A bold claim to make when your competition includes Vim and Emacs.
The code base is actually small and mostly written in Lua, so that it is actually possible to change the editor to your liking.
The code base is actually small and mostly written in Lua, so that it is actually possible to change the editor to your liking.
> 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.
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:
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.
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.
> No need to sync back upstream.
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.
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.
Looks interesting, does it support TTY mode? I might try it.
From the link:
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....
> "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....
The terminal version works only on Unix/BSD, but it was only introduced in 5.5. (Which means there might be glitches as well on Linux.)
Have you seen the scroll bars on this thing? Or the Icon? No way I'm using this on OSX...
Imagine your friends see this app running on your computer, i mean gooosh.... whatevahhh they wouldn't invite you to their minimalism exquisite design parties anymore.
I know you Linux guys are used to every app having a completely different look and feel, but on the mac this app just doesn't feel native.
But your story was cool too...
But your story was cool too...
Wow, what a incredibly stupid troll. Could you paint a bigger "I parrot decade old OS stereotypes" on your forehead?
Especially when this is most likely to integrate in Linux, given that it will follow your GTK theme.
Especially when this is most likely to integrate in Linux, given that it will follow your GTK theme.
You might have a heart attack when you see the file picker ;)
[deleted]
Agreed. Whoever suggested this thing is a good fit for OS X should be harpooned by the ghost of Steve Jobs.
I do use this on OS X and agree that it does not look quite 'native'. It might be possible to port Textadept to be fully native. Scite, which uses the same Scintilla engine, is available as a native OS X app.
It might also be possible to tweak the GTK layouts for the OS X version.
It might also be possible to tweak the GTK layouts for the OS X version.
I don't think sticking with GTK for the OS X version is a wise idea. It really just needs to go Cocoa or not bother, since right now it's downright unpleasant to use for me. Scrolling through text using a trackpad, for example, feels completely unnatural next to the rest of the OS X UI (horizontal scrolling appears to barely work at all - vertical scrolling isn't too bad but there is something very off about it). I think the decision to go with GTK for the OS X version was just a poor choice and probably not one made by anyone who uses OS X often.
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.
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.
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.
Screenshot with dark theme: http://i.imgur.com/oqByS.png
Scrollbar chrome makes me instantly lose interest.
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)?
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)?
> Scrollbar chrome makes me instantly lose interest.
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 :)
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 :)
Does this support tiled windows in a terminal like Vim or Emacs? Relying on a terminal multiplexer to provide that is less than ideal I think.
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.
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.
I can't point you to a screenshot, but scrollbars are easy to hide:
buffer.v_scroll_bar = false
buffer.v_scroll_bar = false
A video tutorial too would be awesome.
Not a video tutorial, but a demo of some Zen-Coding-like HTML editing on YouTube from 2010: http://www.youtube.com/watch?v=DSAinGsc7dA
Unfortunately the GTK theme it is shipped with is a little off putting on OSX.
http://img267.imageshack.us/img267/4600/screenshot20121119at...
The save dialog is standard GTK as well, not OSX.
http://img267.imageshack.us/img267/4600/screenshot20121119at...
The save dialog is standard GTK as well, not OSX.
Just tried the Linux version and I like it! If the Windows version is portable, I'll carry it around on my USB stick.
The Windows version is quite portable if you manually set the .textadept home to your USB stick. A while ago I wrote a Portable Apps launcher [1] that did that automatically for you, haven't used it in quite a while though. (I wrote this before GTK was included in the Windows package.)
[1] https://github.com/rgieseke/textadept-portable
[1] https://github.com/rgieseke/textadept-portable
And a youtube video showing Textadept with some third party plugin: https://www.youtube.com/watch?v=DSAinGsc7dA
What does this do that Vim doesn't? I'm just not sure I see any selling points. You can extend Vim with Lua, vim has multiple viewports, support for hundreds of languages, and all the other features like code complete, etc... What itch is this supposed to scratch, that something like Vim, a proven project, cannot? I understand that every developer wants to carve his name out and be king of his own sandcastle. But as a rule, I don't support that unless the developer has really thought about the problem and decided that a new project was the only way to solve a problem.
> What does this do that Vim doesn't?
It's not vim. That alone will be a selling point for a vast majority.
It's not vim. That alone will be a selling point for a vast majority.
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?
> 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?
At least you found the line for cant see when someone's being facetious.
> At least you found the line for cant see when someone's being facetious
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.
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.
How did you manage to miss that?
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.
He's not trying to reimplement vim. He's doing a new thing. Part of vim's cruft is in its design. An important part of a clean break is a new interface. Obviously, getting traction with other devs will be difficult, exactly like any other tool.
let's see when will first vi plugin for it come out..
Does the "toggle block comment" option actually work (Ctrl+/)? Tried it with python (file saved with .py ext and syntax highlighting even showed up), but couldn't comment with that keybinding...
edit: block commenting didn't even work when selecting it from the Edit menu.
edit: block commenting didn't even work when selecting it from the Edit menu.
By default comment strings are not defined in core Textadept. Add them like this:
http://foicica.com/wiki/comment-supplemental
Or install the Python language module:
http://foicica.com/hg/python/
http://foicica.com/wiki/comment-supplemental
Or install the Python language module:
http://foicica.com/hg/python/
Awesome, thanks. I just added that comment string def to init.lua and it works great.
Edit: why is this not there by default? I'm not sure any developer would not want a block commenting function...
Edit: why is this not there by default? I'm not sure any developer would not want a block commenting function...
<rant>That's great. Now if you'll excuse me, I have to go back to vim and gcc, because I don't have a cross-platform open source IDE that has been "relentlessly optimized" for my language of choice, to look slick, to not consume gigs of RAM and to not stop the world while I'm typing some text. What I have is a long list of text editors. Oh, here's another one. That's great.</rant>
About that extensibility, would it be possible to implement inline diffs? (Paint margin green for added lines, show a red marker for deleted lines.)
The (deprecated) debug module has some screen shots that show margin markers:
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?
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?
Here is how Netbeans does it:
http://netbeans.org/projects/versioncontrol/pages/Git_ui#Inl...
What I see on the screenshots there should be possible in Textadept.
It's a little off-putting that the documentation brags about the low line count without mentioning the use of Scintilla, which already implements most of a text editor. Still, I'm willing to give it a try.
Sadly, on the Mac, this doesn't feel like a native application and things like changing the size of the window are broken. Also, a horizontal scrollbar appearing in an empty text window is strange. Might work great on Linux and I like the idea but the execution on Mac leaves a lot to be desired.
Yeah, I tried the 'source-map' layout but it won't remember the zoom levels when re-opening a session. http://i.imgur.com/mxYO0.png
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.
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.
Has anyone tried this out in terminal (ncurses version). I get an error on osx, so i can't load a file. I get this if I give a file on command line.
> ....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.
> ....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.
I just tried it out and parts of the ncurses UI seems less responsive than I'm used to in vim. For example, try hitting ctrl-alt-f for incremental find, then hit esc to leave it. It seems to take a second to exit incremental find mode. Does anybody else see this?
I didn't see this in the Debian repository yet? Years of experience have taught me that 99% of the time if a project isn't in the Debian repo it isn't mature yes or useful to more than a small niche and probably not worth my time. The 1% that is missing there is when I am part of the small niche.
Not meant as an attack or anything. Just an observation and possibly a 'marketing' suggestion if you'd like more users.
Not meant as an attack or anything. Just an observation and possibly a 'marketing' suggestion if you'd like more users.