My humble suggestions for TextPad

[Mournblade]

Here's the things I want to see for a version of TextPad:

+ Better macro support. The first change is macro types. Distinguish between file creation (accessable evern when there are no documents open) and textual. The second is the ability to hand modify the macro when you want to expand it.
+ Scripted macro support. This would probably require a rewrite of the macro engine so is unlikely to happen in version 4.x.
+ Intelligent Autocomplete. This is a biggie and would probably require a large rewrite of major sections.
+ Ability to change the tool icons.
+ Plugins + free developer SDK for free tools. This is the largest change of all. Probably not likely to see this before version 5.

[b-urn]

free developer SDK for free tools.

I was pondering about whether this was available already or not. Made a search through the forums and this was all I came up with, so apparently it doesn't.

I'd like to see a SDK that lets me communicate with the Textpad-application through programming.

For instance: if it was an easy way to programmatically read/write contents in the current textpad-window, we could implement some of the functionality we'd like to see ourselves. (Code-pasters, auto-completing, complex macros..)

This would probably improve the availability of new add-ons, because it would allow all the programmers out there to experiment with new ideas.

If some ideas turns out to work well, the Textpad developers can latch on and implement more streamlined solutions in Texpad itself.

Thus it would benefit both the community and the future development of Textpad.



Just my 2 cents.

[LDR]

Here's the things I want to see for a version of TextPad:

+ Better macro support. Agreed!
+ Scripted macro support. Agreed!
+ Intelligent Autocomplete. Agreed!
+ Ability to change the tool icons. Okay
+ Plugins + free developer SDK for free tools.
A good scripting language, like Perl, and macros invocable from the command line, plus command line options to allow TextPad to operate as a filter in a pipe sequence in either r-only or rw modes, would make an SDK superfluous. Or, maybe that's what you mean by an SDK?

[Mournblade]

An SDK so you can properly create tools like Doxbar/Visual Assist (my two favourite plugins of all time).

Also Perl is not "a good scripting language". It's a scripting language, but not a good one:-)

[LDR]

Also Perl is not "a good scripting language". It's a scripting language, but not a good one:-)

Okay Ace, what's a good scripting language? & Why, hotshot?

[Mournblade]

Version 1.0 of Perl was released in 1987. Since then it has been rifling through all the languages that has been released and adding it to it's own. Unfortunately instead of adding the best bits in a defined manner, it has just been bolting them on the sides. If I remember correctly the first four languages were awk, sed, sh, and yacc (I could be wrong on those 4 - I know the 4 are unixy things).

Despite version 5 of Perl being available for the last 9 years, the fact that it's heritage spans back to the time before Object Orientated makes it very clunky for adding detailed work to another program that wasn't originally designed for it.

Admittedly my own experience with Perl is very limited - I program in C (Kernel programming), C++, Java (Servlets mainly with JSP), and Visual Basic (for rapid tool development). Notice the fact that the last 3 are all Object Orientated.

A good scripting language is Visual Basic. VB has been given a bad rap over the years (even I slagged it off for it's Basic connetations (I remember basic on the C64)) especially the use it recieves in Virus's. That's not the languages fault - that is the fault of Microsoft. Microsoft never wrote VB - they bought it off a company in 1991. VB is a very good scripting language. There are some other scripting languages like Lua and Python, which I haven't used but I have heard good reviews of Python from a couple of friends who use it in their build chain.

[LDR]

...

Actually, you answered the question about why Perl is not your choice, which I didn't ask. Even then there was lots of generalities, no specifics.

VB sux. It's proprietary; it's tied to a single platform and environment.

Python is a good and truly elegant OO language. Moreover, it supports modules and programs written in any other language, and on almost any platform. Good yob, Guido.

But, Perl has the mindshare, the modules, and the tech support environment.

Long ago and far away, there was a version of emacs that ran an interpreted version of C. It's benefit was not that C was good, but that almost everybody that used Microemacs, also programmed in C.

There's always a tradeoff between elegance and mainstream infrastructure. In this case the tradeoff isn't even close.

The last thing that TextPad needs is a new languiage. The next worst thing they need is a proprietary single platform language. Most of what I write in TextPad is destined for a Linux system.

I'm still waiting for selective invocation of macros from the command line so that TextPad can be really useful in 'bash' scripts under Cygwin.

The rest of this sounds really academic, to me, at this point.