Discussion:
Textadept reviews (was Lua IDE)
Patrick Mc(avery
2011-03-24 12:19:52 UTC
Permalink
I've played around with this editor a bit but I am curious what others
have to say about it:

http://caladbolg.net/luadoc/textadept/manual/1_Introduction.html

Much of it is written in Lua and it is Lua scriptable

Thanks for reading-Patrick
Jon Akhtar
2011-03-24 14:56:18 UTC
Permalink
What is the difference between this and SciTE. Is it possible to do
more with the lua scripting component in Textadept than with SciTE?

On Thu, Mar 24, 2011 at 8:19 AM, Patrick Mc(avery
I've played around with this editor a bit but I am curious what others have
http://caladbolg.net/luadoc/textadept/manual/1_Introduction.html
Much of it is written in Lua and it is Lua scriptable
Thanks for reading-Patrick
Ryan Pusztai
2011-03-25 02:53:48 UTC
Permalink
Hi,
Post by Jon Akhtar
What is the difference between this and SciTE. Is it possible to do
more with the lua scripting component in Textadept than with SciTE?
On Thu, Mar 24, 2011 at 8:19 AM, Patrick Mc(avery
Post by Patrick Mc(avery
I've played around with this editor a bit but I am curious what others
have
Post by Patrick Mc(avery
http://caladbolg.net/luadoc/textadept/manual/1_Introduction.html
Much of it is written in Lua and it is Lua scriptable
I really like this editor a lot. It is so customizable. Most everything can
be configured in Lua. I can't believe how well thought out and well
documented all the API is. The developer is helpful and there is an active
community. I just asked a few questions and they helped me every time. SciTE
has debugging support, but I know you can make debugging work in TextAdept,
it just has not been written yet. I find configuring it to be way easier
than SciTE. It is maintained well and updated often with many new features.
It has many features that I find easier to use than in SciTE, but there are
no tabs. I like tabs, but this editor is showing me that they are not a
necessity. The infinite splitting windows is very helpful and after you
learn the keyboard shortcuts you can be amazingly efficient. The
auto-complete for Lua is quite amazing. The editor is blazing fast and
remembers the window size even after it is restarted (SciTE still doesn't do
that :( ) I am not sure it is for everyone though. It only has a menu and
editor, but I really like it.
--
Regards,
Ryan
kevin beckford
2011-03-25 05:53:06 UTC
Permalink
Vim is lua scriptable.
steve donovan
2011-03-25 06:12:49 UTC
Permalink
Post by Ryan Pusztai
I really like this editor a lot. It is so customizable. Most everything can
be configured in Lua. I can't believe how well thought out and well
documented all the API is.
I really wanted to like this one when I tried it out some time back;
it has a minimal C core of 2000 lines, the rest is Lua. It uses
Scintilla and comes from the same guy that brought LPeg lexers to
Scintilla (now supported in mainline SciTE). However, there is a
learning curve which does not make it a friendly first code editor.
(Translation: I was confused.)

And it does require the GTK runtime on Windows, which makes it an
awkward replacement for SciTE on that platform.

steve d.
Ryan Pusztai
2011-03-25 11:31:24 UTC
Permalink
Post by steve donovan
Post by Ryan Pusztai
I really like this editor a lot. It is so customizable. Most everything
can
Post by Ryan Pusztai
be configured in Lua. I can't believe how well thought out and well
documented all the API is.
I really wanted to like this one when I tried it out some time back;
it has a minimal C core of 2000 lines, the rest is Lua. It uses
Scintilla and comes from the same guy that brought LPeg lexers to
Scintilla (now supported in mainline SciTE). However, there is a
learning curve which does not make it a friendly first code editor.
(Translation: I was confused.)
Yes, it is different. That is why I think it isn't for everyone. I totally
agree about the menu not having the keyboard shortcuts. I think I will add a
feature request for this. But until then there is a new wiki article [1]
with them all listed.
Post by steve donovan
And it does require the GTK runtime on Windows, which makes it an
awkward replacement for SciTE on that platform.
I believe GTK is part of the download. No need for anything else, but the
.zip download.
--
Regards,
Ryan

[1] http://caladbolg.net/luadoc/textadept/manual/14_Appendix.html
mitchell
2011-03-28 02:44:49 UTC
Permalink
Hi,
Post by steve donovan
Post by Ryan Pusztai
I really like this editor a lot. It is so customizable. Most everything can
be configured in Lua. I can't believe how well thought out and well
documented all the API is.
I really wanted to like this one when I tried it out some time back;
it has a minimal C core of 2000 lines, the rest is Lua. It uses
Scintilla and comes from the same guy that brought LPeg lexers to
Scintilla (now supported in mainline SciTE).  However, there is a
learning curve which does not make it a friendly first code editor.
(Translation: I was confused.)
Yes, it is different. That is why I think it isn't for everyone. I totally agree about the menu not having the keyboard shortcuts. I
think I will add a feature request for this. But until then there is a new wiki article [1] with them all listed.
If I could, I would have added shortcuts to menus a long time ago. As I
understand, GTK needs an accelerator group in order to show keybindings,
but the dynamic nature of textadept's key commands renders such a thing
useless.

mitchell
Wesley Smith
2011-03-28 06:07:43 UTC
Permalink
Post by mitchell
If I could, I would have added shortcuts to menus a long time ago. As I
understand, GTK needs an accelerator group in order to show keybindings, but
the dynamic nature of textadept's key commands renders such a thing useless.
It's possible to dynamically modify GTK's accelerator groups.
wes
steve donovan
2011-03-28 06:48:42 UTC
Permalink
Post by mitchell
If I could, I would have added shortcuts to menus a long time ago. As I
understand, GTK needs an accelerator group in order to show keybindings, but
the dynamic nature of textadept's key commands renders such a thing useless.
Yes, having looked at the code I can see the problem. One solution is
to embed parse-able accelerator strings in the menu strings
themselves, and use that as the preferred way to change key bindings.
This of course has other implications, like messing up the
localizations, which suggests that a menu definition should consist of
three things: the caption, the accelerator, and the action.

(Nice piece of work by the way.)

steve d.
mitchell
2011-03-28 15:21:27 UTC
Permalink
Steve,
Post by steve donovan
Post by mitchell
If I could, I would have added shortcuts to menus a long time ago. As I
understand, GTK needs an accelerator group in order to show keybindings, but
the dynamic nature of textadept's key commands renders such a thing useless.
Yes, having looked at the code I can see the problem. One solution is
to embed parse-able accelerator strings in the menu strings
themselves, and use that as the preferred way to change key bindings.
This of course has other implications, like messing up the
localizations, which suggests that a menu definition should consist of
three things: the caption, the accelerator, and the action.
Even so, I don't think GTK accel groups handle keychains (e.g. Alt+S, ').

We're getting off topic on the Lua list though; if you want to continue
this discussion, we can do it on the textadept mailing list. I'm open to
ideas.

mitchell
Christof Schardt
2011-03-26 08:55:28 UTC
Permalink
Post by steve donovan
learning curve which does not make it a friendly first code editor.
(Translation: I was confused.)
And it does require the GTK runtime on Windows, which makes it an
awkward replacement for SciTE on that platform.
That is exactly my experience.
First it sounds totally promising: Lean, fast,
lua-scriptable, cross-platform. That's, what
I always looked for.
But when I tryed it out on windows, I immediatly
faced many shortcomings (which apparently are results
of using gtk):
shortcuts not working as expected, menus not working
as expected, no system-fileselector with a really different
behaviour,...and more.
And it is not obvious, what can be tweaked and what not.

Christof
steve donovan
2011-03-26 09:15:19 UTC
Permalink
On Sat, Mar 26, 2011 at 10:55 AM, Christof Schardt
Post by Christof Schardt
But when I tryed it out on windows, I immediatly
faced many shortcomings (which apparently are results
Yes, the GTK file chooser, not everyone's cup of tea! At least 'go
native' at this point (20 extra lines of C to give the user the system
dialog.)

With a small C core like that, true Windows/Mac ports would not be
terribly difficult, but would it be worth it?

The points of customization are not clear. I just went in a played
with the source, which does not feel like the 'correct' strategy ;)

steve d.
Wesley Smith
2011-03-26 17:28:54 UTC
Permalink
Might there be a way to go native via bindings and a lua module? I haven't looked at it, but if there are hooks in the right places, I presume one could divert flow to native functions.

wes
Post by steve donovan
On Sat, Mar 26, 2011 at 10:55 AM, Christof Schardt
Post by Christof Schardt
But when I tryed it out on windows, I immediatly
faced many shortcomings (which apparently are results
Yes, the GTK file chooser, not everyone's cup of tea! At least 'go
native' at this point (20 extra lines of C to give the user the system
dialog.)
With a small C core like that, true Windows/Mac ports would not be
terribly difficult, but would it be worth it?
The points of customization are not clear. I just went in a played
with the source, which does not feel like the 'correct' strategy ;)
steve d.
steve donovan
2011-03-27 08:35:17 UTC
Permalink
Might there be a way to go native via bindings and a lua module?  I haven't looked at it, but if there are hooks in the right places, I presume one could divert flow to native functions.
Totally possible - the TextAdept executable exports all the Lua
symbols, so one could write a little extension and link against it.

I just thought it would be a nice thing to have in the core, but it's
not difficult to monkey-patch the Lua code for this task.

Although I have my doubts about it being my next, best editor, it
certainly is fun to play with and does have nice documentation. I've
just done an interactive Lua prompt, pretty straightforward.

steve d.
steve donovan
2011-03-25 09:57:53 UTC
Permalink
Post by Ryan Pusztai
be configured in Lua. I can't believe how well thought out and well
documented all the API is.
Now this is very true - it's a great example of LuaDoc done well. See e.g.

http://caladbolg.net/luadoc/textadept/modules/events.html

And yes, the pane splitting is very cool. A little grumble: the menu
does not show the associated keyboard shortcuts, which makes
self-learning a little harder than it should be.

steve d.
Michal Kottman
2011-03-25 10:10:29 UTC
Permalink
Post by Jon Akhtar
What is the difference between this and SciTE. Is it possible to do
more with the lua scripting component in Textadept than with SciTE?
It would be interesting to try to port lua-inspect [1] to TextAdept to
try to answer your question :) However, with the scite.lua module in
lua-inspect having over 1500 lines of code this would not be so easy. If
only the day had more than 24 hours...

[1] https://github.com/davidm/lua-inspect
Cosmin Apreutesei
2011-03-25 22:07:06 UTC
Permalink
Still looking for an editor that can do split screen and moving editor
windows to multiple monitors. Unfortunately, neither scite nor
textadept can do that nor they can be extended in that direction.
Alessandro Delgado
2011-03-25 22:44:45 UTC
Permalink
On Fri, Mar 25, 2011 at 7:07 PM, Cosmin Apreutesei
Post by Cosmin Apreutesei
Still looking for an editor that can do split screen and moving editor
windows to multiple monitors. Unfortunately, neither scite nor
textadept can do that nor they can be extended in that direction.
I'm quite happy running GNOME+XMonad+gnome-terminal+vim :-)

It works well with multiple monitors and splits screen like nothing else!
Gaspard Bucher
2011-03-29 14:40:04 UTC
Permalink
Has anyone got a good lua.vim syntax file: something that recognizes
function names, not just lua keywords ?

Example (highlights "thisMethod"):

local *function thisMethod*()
end

G.
Post by Alessandro Delgado
On Fri, Mar 25, 2011 at 7:07 PM, Cosmin Apreutesei
Post by Cosmin Apreutesei
Still looking for an editor that can do split screen and moving editor
windows to multiple monitors. Unfortunately, neither scite nor
textadept can do that nor they can be extended in that direction.
I'm quite happy running GNOME+XMonad+gnome-terminal+vim :-)
It works well with multiple monitors and splits screen like nothing else!
Peter Odding
2011-03-29 14:51:52 UTC
Permalink
Post by Gaspard Bucher
Has anyone got a good lua.vim syntax file: something that recognizes
function names, not just lua keywords ?
local *function thisMethod*()
end
If you create ~/.vim/after/syntax/lua.vim and add the following two
lines you should have what you want:

syntax match luaLocalFunc /\(local\s\+function\s\+\)\@<=\w\+/
containedin=luaFunctionBlock
highlight def link luaLocalFunc Function

If you remove the local\s\+ bit it will highlight all functions instead
of just local functions.

- Peter Odding

Kyle Cordes
2011-03-25 23:10:09 UTC
Permalink
On Friday, March 25, 2011 at 5:07 PM, Cosmin Apreutesei wrote:
Still looking for an editor that can do split screen and moving editor
Post by Cosmin Apreutesei
windows to multiple monitors. Unfortunately, neither scite nor
textadept can do that nor they can be extended in that direction.
It is a truism of software design, that when using a system designed to be extensible and flexible in numerous ways, users will quickly end up wanting extensibility in a direction that the software does not accommodate well.
--
Kyle Cordes
http://kylecordes.com
Loading...