Community

I believe your suggestion is different from mine.

My suggestion is not that TextPad should provide programming functionality, but that it should provide the means to integrate it with other tools that provide that functionality.

Hmm...interesting...you suggest simply providing an API of sorts then letting the community go to town? Lovely idea!

How about the macro capability then? The programmer of an API-based "plugin" must have access to the keyboard I/O stream, of course.

Helios could provide a COM API, perhaps. The API would have to include methods to register call backs for plugin lifecycle events as well as keyboard events and so on.

Dear Helios, your user community will be more than happy to help design this API with you. Just provide the API and geeks like us will create all the rest!

I have to admit: This is a lot of fun.

How about this?

Develop your own text-manipulation program using the language of your choice (so that you can have the ultimate set of custom features), set it up as a user tool, and call it from within TextPad.

It is astonishing to see there is still energy and momentum behind the "Editable Macros in Textpad" issue.

There is a 5+year old solution to this feature request (and many others like it) that other long-time TextPad users supported. The simple solution is to let the user run any tool or script against a selected region of text spanning 1 or more lines (not just one line, and not requiring $Clip).

(see e.g.,)
http://forums.textpad.com/viewtopic.php?t=4890
http://forums.textpad.com/viewtopic.php?t=5224
http://forums.textpad.com/viewtopic.php?t=7223

This feature is already implemented in other editors. It works. No speculation or feasibility analysis is required.

This issue can be very easily resolved. If it becomes a priority, it will get addressed. If it doesn't, it won't. If history is a good indicator, it won't.

.02 for ya

TextPad is useful. TextPad is efficient. Unfortunately, TextPad's author doesn't make enough money from TextPad license sales (so it seems) to justify the hiring and maintenance of a team of developers to evolve the product. Perhaps TextPad's author does, but has decided not to mess with a good thing (I wouldn't blame our anonymous author, which I currently assume is a single person). Regardless, watching TextPad evolve to suit the needs of its user base (in a more complete way) is like watching protons decay. Will I still use TextPad? Yes. Will I still pay for a new license in v6 when (if, ever) it comes? Yes. Am I a sucker? No, since the product is still very good for what it does.

Then again, none of us knows what the code base looks like. Perhaps it is like the old WordPerfect code base and is a jumbled Ball of Mud and very, very difficult to change. (The inability for WordPerfect to evolve swiftly and effectively was one reason for its market share loss.) In that case, if I were the author I would be really, really reticent to change it as well. (This would be a really good case of, "If it's not broke, don't fix it!")

[sighs heavily]

"If Helios didn't put in a macro editor, then it probably had a good reason not to."

Simply Specious.

This is mainly in response to drefty's excellent post:

http://forums.textpad.com/viewtopic.php?t=4890

I believe that there is a way to have a TextPad macro close a file. It is just a matter of discovering what that way is; it may involve setting up a few unusual keyboard shortcuts or something, in order to navigate the focus in an unusual way so that access to a command eventually becomes possible--and recordable by the macro facility.

One frustrating thing I've noticed is that Alt key mappings are not recordable by the macro facility. (But I don't yell at Helios, because I suspect that they had a good reason to allow this situation.) But Ctrl key mappings are recordable; it's just that most of them are already taken--but not all. . . .

For example, map the available "Ctrl+Q, 2" to "ActivateSelector," and then see whether the macro facility will be able to record your press of the context menu key on the keyboard. Bringing up the context menu on the Document Selector will allow you to access the "Close document(s)" command via the arrow keys and Enter key, which the macro facility should be able to record.

If that doesn't work, use your brain to come up with something else!

Wait a minute! There's a "FileClose" command. Just map "Ctrl+Q, 2" directly to that. Of course, you should use a dedicated instance with a limited number of files, and Ctrl+F6, to get the focus to the right file. It's just a matter of figuring out how to work.

http://forums.textpad.com/viewtopic.php?p=31351

There are so many things that programs can do that folks never get around to discover because they are too busy creating and sending wish lists to developers.

"It would be great if I could just type "Alt+D" and have TextPad do my work for me, so that I can just go out and play golf instead. Can you implement the 'Do-My-Work-for-Me Function' Helios? Please?"

I apologize if I have been snarky about this topic, but I guess it has become somewhat of an emotional issue for me. I have been using TextPad for a few years now and have maintained a paid license for the product. I develop software professionally, and I am expected to support my customers in manners they are accustomed to. In the way of "do unto others as you would like them to do unto you" I would expect the professional developer of TextPad to treat me in kind. My customers keep me up to date with their wish lists, and I wish to provide mine to Helios. My customers want transparency in terms of prioritization, workflow and release expectations and I wish the same from Helios. Instead, I get nothing but silence from Helios and the occasional "throw the dogs a bone" release. If the product wasn't so good at precisely what it did then I probably wouldn't bother using it anymore.

In some respects I was happier when I thought TextPad was an abandoned product. If, on the other hand, TextPad is an actively developed product then I would like to know the author is supporting his or her customers in a manner similar to the way I would support my own. I am not demanding all the features I ask for, but it would be nice to know if they are being considered or not. Heck, even if TextPad's author was to say that it would not be possible to release any specific wish of mine any time soon because of the fix backlog or whatever, I would like to hear that. Even knowing that taking care of TextPad is not the author's "day job" would also be helpful. (Golly, dear Great Anonymous TextPad Author, just admit it!)

There certainly exists many work-arounds for the features I wish TextPad had, and I certainly appreciate knowing what those work-arounds are. However how would the Great Anonymous TextPad Author know what it is I am wishing for unless I discussed the details of those wishes here? I am a professional developer myself and I appreciate what it takes to create and maintain a product such as TextPad, but I do wish to be treated as a customer in a way similar to how my customers demand to be treated by me.

May I compliment you, Ms. Tedesco, on the eloquentness of your writing?

Yes, voicing preferences is . . . preferable to voicing none.

I could imagine some of the demands that some customers might place on a person in your position and understand that it would be inappropriate to respond to them in some of the ways by which, uh, I have responded in this forum. The purpose, however, of my responses is ultimately a noble one, as I am attempting to instill, into those whom I feel are capable of comprehending, what I truly believe is, and follow as, the better way.

By the way . . .

Disclaimer: My frequent defense of Helios's design in no way incriminates me; I am merely an innocent third party, who really just loves the program.

NicoleTedesco wrote:
...

In some respects I was happier when I thought TextPad was an abandoned product. If, on the other hand, TextPad is an actively developed product then I would like to know the author is supporting his or her customers in a manner similar to the way I would support my own. I am not demanding all the features I ask for, but it would be nice to know if they are being considered or not. Heck, even if TextPad's author was to say that it would not be possible to release any specific wish of mine any time soon because of the fix backlog or whatever, I would like to hear that. Even knowing that taking care of TextPad is not the author's "day job" would also be helpful. (Golly, dear Great Anonymous TextPad Author, just admit it!)

...

Nicole, all you said fell on sympathetic ears! For a while there I thought that the maker of Textpad/WildEdit had died and left this website on autopilot. I was in complete shock when a Vista compatable version of Textpad came out. Frankly, I guess, the maker simply ran his source code through a Microsoft Vista aware compiler and now you have a new Vista compatible version of Textpad. The fact that I noticed some enhancements means to me that the maker of Textpad is not dead yet.

Maybe he is too busy at his real job? What a shame that this - his hobby - caught on so well and that his interest in it is a fraction of the community he or she spawned.

(See? I'm not the only one with sarcastic remarks. LOL)

Right now I'm almost tempted to disassemble the Textpad macros and reverse engineer them. Fortunately or unfortunately it is faster for me to write a quick script in Visual Basic to get my intelligent text editing done rather than reverse engineer a Textpad macro. I wish I had a lot of free time on my hands to do it as it sounds like fun.

What a great failing that this product has this macro capability but if you make a slight mistake, it is worthless. You can't edit it and, obviously, you can't program any intelligence into it. If he didn't include Macro in Textpad, would we be so annoyed about its shortcomings?

Ryck wrote:". . . it is faster for me to write a quick script in Visual Basic . . ."

VB is a full-blown language with eight (8) loop constructs! Write some code, man, and set it up as a user tool. Feel the power!

Ryck wrote:"If he didn't include Macro in Textpad, would we be so annoyed about its shortcomings?"

The foregoing is a very excellent hitting of the proverbial nail's head.

There are so many things that we can do!

Consider implementing a macro using a number of calls to smaller submacros: A main macro can call a series of individually pretested small submacros. Use top-down design!

Adding one more voice to the desire to be able to modify macros.

I don't feel the need for a full macro programming language. I'd be happy with three additions:

1) When recording, allow Undo -- which would both undo the edit and remove the step recorded.

2) When I start recording and have an unsaved macro, offer me the option of continuing to record. Undo prior to the resume point would be blocked, since the state of the document would differ from the state of the macro.

3) And therefore, also allow me to delete steps from the end of the macro without a corresponding edit undo.

Arguments that say "just do it in VB" don't sway me -- though I've been programming for 40 years, VB is a tool I haven't learned (and it's ugly compared with most tools I've used), and like non-programmers I have another job I want to get done.

I think it's very likely that this scheme would be fairly safe to implement even if the macro code is spaghetti.

And no, TextPad does not have to be a choice between a non-macro editor or a programming language. I can do things with TextPad macros which would be infeasible without macros, mainly because they are complex edits I need to do a large number of times. Yet TP can accomplish many such tasks without forcing me to go into another tool, so even with these limitations, macros have added a lot of value. (Yesterday I converted some files in a proprietary format to CSV, which required about 15 steps in a TP macro.)

It's just jarring that TP is so good in so many ways -- despite (or more likely because of) so few changes in recent years -- but this one blockage seems so 1970 to me.

Edward

Well, another year has come and gone.

I'd like to take this opportunity to request for the umpteenth time that either:

(a) an interface for editing macros be included in the next release of TextPad (the best darned text editor known to man) OR

(b) A complete file format specification for the macro file be published, so I could boil up a tool myself.

Either would be lovely, but neither (the current state) is a pain.

I second the motion for the umpteenth time. A macro editing language, or at least public disclosure of the textpad macro file format, is ten years overdue.

I just felt like adding my voice here, as I too would badly need to create something like a macro, just to aggregate multiple search and replace operations. I purchased both TextPad and WildEdit, and none has a simple way to performe a list of multiple search & replace operations.

I don't need a macro editor. Very simply, the saved macros should be in plain text, not in binary format. I don't mind whether that's INI, XML, or whatever, as long as the search and replace operation can be edited, copied and pasted within the macro.

How much would it take to save as text rather than in binary format? One hour of work?