Community

Just to throw my $.02 in. I think editable is fine (and I assume easier to implement). If we do go with a language, what I think would be slick would be to use whatever they've done with Windows Scripting Host where it's language independent. Yes, you can use more than VB. *shudders at the thought of VB* At least, I assume WSH is what the activeX scripting uses in DTS within SQL Server. This way, you can use VBscript, JavaScript (JScript), PerlScript and even that Python thing. Not that I know anyone who uses Python...

highly recommended, I have just entered the forum to find a possibility to do this.

And I´m not the only at my work who needs this feature.

Obviously this is a huge subject. I almost shouldn't be posting since I don't have any great ideas. However my opinions would be these:
a) what talleyrand wrote about doing what WHS does sounds right on.
b) it would make the appeal of textpad greater, especially in the emacs camp, thus broadening the horizons of this product
c) I myself probably wouldn't use it much as I've never found macros in a program editor to be all that important
d) That being said I might eventually come to need them.

Conclusion: design it right then do it as time allows.

I voted with great enthusiasm for editable macros .. but that was some time ago.

In the meantime, I've found several other applications that integrate very neatly with TextPad (eg: Beyond Compare, grep for windows, autocomplete, etc.) .. And just recently I discovered Autoit v3 for macros, following a lead from one of the postings in these forums.

Which all leads me to wonder: is it really all that important to motivate for TextPad to have it's own editable macros? Perhaps any effort in this direction would be better spent tweaking TextPad in very subtle minor ways to be more compatible with external macro apps like Auotit. ((There are one or two little quirks I've come across in my fiddling with Autoit + TextPad .. just can't think of them right now, which just goes to show how minor they are!))

LOL .. I almost feel like a traitor! Hope no-one takes offence at my suggestion to let Helios off the hook for this.

That's OK for you to change your mind trids, we already got your "FOR" vote.

I also use a separate macro program, Macro Scheduler which is the best (IMHO).

Well, a script language like EMACS (and no, I'm not suggesting LISP here) allows you to do things like:
You wouldn't be able to do this with AutoIt, which merely encodes Windows events. EMACS allows you to manipulate EMACS internal objects, such as anchor points and so on. Further, it allows you to call EMACS actions like select_word, transpose_chars, and so on.

Now, I know some folk are going to point out that you CAN do this by just encoding Windows events, providing that every action you want to perform has its own keyboard shortcut - BUT, if your macros are dependent on a particular keyboard mapping then they are not portable, and will stop working if you change the mapping.

I'd still go for a TextPad-oriented scripting language, although I do appreciate that this is a big job.

Jill

You raise a good point, ramonsky (and Bob too): that we all have our own preferences for a scripting/macro language.

"Vive la Difference" .. Pardon my French

I would hate anyone to feel that he has no option but to learn to love Autoit3, but I would similarly hate to be forced to learn yet another scripting language myself - especially one that is limited to the specific context of use within a single application.

So maybe it was wise indeed of Helios to leave this option open!

Anyway, I've had my say .. so I won't go on about it anymore.

I totally agree with Ramonsky. I would love to see a macro language that gives access to Textpad internals. It would be great, for instance, if a macro could control the content of the clip-library pane (and then selecting something in the clip library pane could run a macro -- or am I getting carried away?).

I think a comprehensive macro language could swell the add-ons section of this website with a lot of great stuff. I've been using Textpad for 8 years; before that I used Programmers File Editor, which had an editable macro language. It's the one thing I really missed, and still miss. *sniff*

To get more specific about my motives -- since I've been doing more ASP.NET programming lately I've been feeling pressure to move to Visual Studio. But I've really tried to use VS and, like many times in the past, have come back to Textpad because of its efficiency and its familiarity (or maybe I'm just stubborn). I don't want to clutter up Textpad, but I do want to see it become easier to extend so that it can be a powerful IDE if it wants to be. And to Helios I say, my wallet is on quick-draw mode for the next major version of Textpad.

Thanks!

But...

to my mind folding is more important. Whilst a macro language would be a nice to have, the only thing I can't achieve in TextPad that I want to achieve is folding code.

On the topic of macro code though, I fully agree with the 'don't reinvent the wheel' approach and the 'vive la difference!' - using a scripting host seems to make the most sense to me, although I have no idea how TP is implemented, so I don't know how easy it would be to expose the (hopefully) underlying object model.

Having written a script editor, using a scripting host, which was embedded into our main product, i do know that if the main app is oop providing scripting is easy - if it isn't, well, it is less so!

Additionally, the ability to merge several macros. I am currently working aproject where I have nine (9) macros. I have to execute each macro against each file. If I could merge these into one macro the process would reduce my effort by ~90%. Also, if I could execute this macro against all files in a particular folder, without having to open each file individually, would improve even on that (somewhat like the Search in Files function - an Execute Macro(s) on Files function).

1. You can create macros in TextPad to call other macros. So, make one macro that calls all nine in proper sequence?

2. In the meantime consider using Macro Scheduler which will allow you to open TextPad, run any TextPad macro, wait until it is done, run another one, wait, etc. until all are done, save results, and then close TextPad when finished. This is a simple example of what can be done with it.

Folks,
I think that a Macro Language for TextPad would be great and I would use it alot but...... As a first step I would like to see the ablity to at least edit the KeyStroke macros. I use them alot and somtimes they are complex so being able to simply edit them would be extremely helpful.

A proper macro/scripting language would be my top priority for TextPad. I would however like it to be a seperate tool from the current key-stroke macros which are great for doing things like doing a quick re-format of a data file.

Having a full scripting language similar to VBA/VBS would make TextPad complete for me.



Roy

I would really like to see scriptable macros added to TextPad. But if TextPad 5 was released next week and had support for macros written ONLY in Ruby, I would be incredibly disappointed. Because I don't want to learn Ruby.

I'd be happy if there was scripting support using Perl, Java, JavaScript, VB, or PHP because I already know all of those languages. But everyone has their own favorite language, and it will be difficult to please everyone. Of course, a brand-new TextPad-only scripting language will please no one.

So, what I suggest is that there is a three-layer scripting system:

Layer 1: TextPad
Layer 2: Glue
Layer 3: Scripting Platform

The scripting platform could be any languge. Perl. Python. Ruby. VB. C++. Java. Whatever.

The Glue would be a layer of code, implementing a standardized interface, that would facilitate communication between TextPad and the scripting platform. Helios could provide a sample implementation for a given scripting platform (such as JavaScript). And then third parties (such as me) could write their own Glue layers, based on the Helios example, for other languages (such as Perl).

The glue layer would probably have to be written in C or C++ in order to facilitate fast low-level interprocess communication.

For me, that would be the ideal solution.

I see from Jeffy's summary on http://www.textpad.com/forum/viewtopic.php?t=3811 that this is still running among the top two requests.