Simple but powerful enhancement suggestion: Run on Selection

[drefty]

:idea:

PROBLEM: There are *numerous* recurring feature requests for TextPad that involve 'munging' a particular subregion of the open text file (e.g., prefixing comment characters, getting context-sensitive help, code completion), but the proposed solutions for adding these features are not easy (e.g., making macro files editable, building script support into TextPad [with millions of possible language choices]).

SOLUTION: Enable TextPad to run any arbitrary 'tool' on a selected region of text within a document.

RATIONALE: Currently, TextPad does not allow a user to run a 'tool' on a selection. True, there is the $Sel parameter macro, but that only works for a *single line*. Allowing a user to run a 'tool' on a selection *inside an open text file* would allow them to write their own script in their own favorite programming language to do any concievable thing they want to do.

HOW IT COULD WORK: Step 1) Select a region of text in your document (or the entire document if you want); Step 2) Run a tool from the tool menu to munge your text; Step 3) Textpad automatically replaces the selected text with the 'munged' version returned by your script.

POTENTIAL PROBLEMS: The reason why the TextPad $Sel parameter macro currently works only with a single line is (probably) because it is tricky to run an external tool while providing a huge blurb of text as one of the arguments. The problem is, how do you delimit the huge blurb of text as a *single* argument. The only (practical) way around this problem is to export the entire blurb to a temporary file, and *then* have the tool script munge that temporary file, and have TextPad insert the newly munged file where the selection is.

COMMENTS: This can already be done in Textpad, but it is not graceful. Currently you have to create a macro to create a new file, and there is no way to close the temp file with a macro. Therefore, Textpad should have a way of doing all of this in a *single step* ...

[s_reynisson]

I would give this 5 out of 5 in a "legit" poll (ie. one with the 5 standard options).
Most tools I use only accept the $File parameter anyway.
TP creating a temp file on the fly would be awesome IMHO.

...snip...POTENTIAL PROBLEMS: ...snip...The only (practical) way around this problem is to export the entire blurb to a temporary file, and *then* have the tool script munge that temporary file, and have TextPad insert the newly munged file where the selection is.
COMMENTS: This can already be done in Textpad, but it is not graceful. Currently you have to create a macro to create a new file, and there is no way to close the temp file with a macro. Therefore, Textpad should have a way of doing all of this in a *single step* ...

[ramonsky]

Very awesome. As a programmer I could customise away to my heart's content, given this enhancement. It is a truly brilliant idea.

As a qualifier though, I still believe that the tools list should be dependent upon the document class, otherwise the list will just get too big, cluttered, and error-prone. Using the present scheme, for example, you'd end up with separate entries on the tools menu for "Comment out C", "Comment out C++", "Comment out Basic", "Comment out Python", etc.. A single item "Comment out" which calls a different tool for each different document class would obvioulsy be better.

(BTW, I don't think that selected-text-tools should be on the same menu as the whole-file-tools. A separate menu would be nice, but I guess that's just window dressing).

Oh yes ... one more suggestion ... if the "selection tools" worked like Unix filters, TP would be so powerful it'd be almost unbelievable. By this I mean that a "selection tool" should be able to read the selected text from standard input, and must write modified text to standard output. This would automatically mean that a whole load of "selection tools" already exist, and merely need to be associated with menu items. It would also mean that writing new selection tools would be a piece of cake ... and could be done in any language! For example, if you were to write a filter called MyFilter.php in PHP (instead of MyFilter.exe in C++ or whatever), you could then associate the command "PHP -q MyFilter.php" with a menu item and it would run just fine.

This is not quite as powerful as a scripting language with knowledge of PHP internals, but it would nonetheless solve most of the practical problems which people want scripting languages for, and would be considerably simpler to implement.

Give this a poll and I'll vote for it.

[dandersahn]

This is the one missing feature that keeps me from using TextPad. I keep checking back on each version to see if it has been added. I tend to use EditPlus, which I feel is inferior in many ways, but does have a very good implementation of this feature. The feature is called a "text filter" in EditPlus. It works by pipeing the selected text (or the entire buffer) into the stdin of the process that is created and replacing the selected text (or the entire buffer if no text is selected) with whatever is returned by the stdout of the process. The implementation works beautifully. There is no concern about argument length, newlines, etc. because the text is not passed as an argument. It also does not require *any* temp files. Text in an unsaved buffer can be operated on (very convenient for quick operations such as pretty-printing and XML string). It is such a simple way to allow for almost unlimited customization. I simply cannot understand why more text editors do no have this feature. Please, please add this feature

[joelcsalomon]

The acme editor for Plan 9 and Unix has this feature - it is incredibly useful if you have the right command-line tools.

Can we please have this feature?

[lionelb]

As a workaround perhaps you could use the $Clip parameter. This simply copies selected text to the clipboard (it doesn't actually supply a command line argument). Your tool could then read the clipboard, munge away and paste the result straight back into the document, thereby replacing the original (still selected) un-munged text.

Not sure if this would pan out for you, but I've used a similar technique successfully to implement (in C++) a tool that pastes selected text - with some mungeing* - from TP into another application; see: http://textpad.com/forum/viewtopic.php?t=6012

* UK spelling

Regards,

[ben_josephs]

I would welcome the addition of this functionality, which is common in Unix editors. It's elegant, simple and powerful.

I use $Clip, as Lionel suggests, as an approximation, although it's an unsatisfactory solution as it clobbers the clipboard. Also, a tool in TextPad cannot paste anything into a document. You have to do that manually after the tool has run.

If you like Perl, you can do it as in this example, which changes the selection to upper case:
Create a tool:

Code: Select all

Command:    c:\perl\bin\perl.exe
Parameters: $clip c:\script\tpclipuc.pl

[X] Run minimized    [X] Close DOS window on exit

where c:\script\tpclipuc.pl is

Code: Select all

use Win32::Clipboard ;
my $clip = Win32::Clipboard ;
my $text = $clip->GetText ;
$clip->Set ( uc $text ) ;

( I would hate anyone to think that the "e" in "mungeing" is a standard UK usage. It isn't, and there's no justification for it. )

[lionelb]

Also, a tool in TextPad cannot paste anything into a document.

Right, that would explain an unsuccessful and frustrating attempt of mine (using standard Win32 C API calls) to do precisely that. Is that documented anywhere? If it were possible to invoke user tools from a macro <gripe>why isn't it?</gripe> this mightn't be a problem.

(I would hate anyone to think that the "e" in "mungeing" is a standard UK usage. It isn't, and there's no justification for it.)

You got me bang to rights there - I made that up, of course The justification is that I kind of prefer "munge" - rhymes with "sponge" (interestingly, in UK usage "whinging" and "whingeing" are both apparently acceptable, whereas "spongeing" is definitely not).

[ben_josephs]

TextPad doesn't have a published programmatic interface to its innards (unlike some Other Editors from Another Place). And I know nothing about climbing inside TextPad at the level of the Windows API.

This would, anyway, be the Wrong Way to do it. It would require tools specially written for TextPad instead of general-purpose stdin-to-stdout filters.

It would certainly help if user tools could be invoked from TextPad macros.

Also, a tool in TextPad cannot paste anything into a document.

Right, that would explain an unsuccessful and frustrating attempt of mine (using standard Win32 C API calls) to do precisely that. Is that documented anywhere? If it were possible to invoke user tools from a macro <gripe>why isn't it?</gripe> this mightn't be a problem.

[lionelb]

TextPad doesn't have a published programmatic interface to its innards (unlike some Other Editors from Another Place). And I know nothing about climbing inside TextPad at the level of the Windows API.

In fact what I tried to do was - from a tool - use standard API calls to locate and activate (i.e. set to accept keyboard input) the most recently active TextPad window and then send it (simulated) Ctrl-V keystrokes. So nothing to do with TP innards, I would have thought, if it behaved like a "standard" Windows app. Anyhow, this didn't seem to work, although it does with some Other Applications.

As you say, stdin-to-stdout filters would be a fine thing, but hey, wrong OS ... my plan was to try to use the clipboard as a kind of crude pipe.

[ben_josephs]

Mm. Interesting. It works from a 4NT console:

Code: Select all

activate "*TextPad*" & keystack Ctrl-v

so keep trying...!

As you say, stdin-to-stdout filters would be a fine thing, but hey, wrong OS :( ... my plan was to try to use the clipboard as a kind of crude pipe.

Pipes don't work as well in Win32 as they do in grown-up systems, but I think they work well enough for this purpose. Anyway, if they don't, they can be simulated with temporary files and redirection.

[dandersahn]

Pipes don't work as well in Win32 as they do in grown-up systems, but I think they work well enough for this purpose.

I think the second part of that statement is the key. I have been using stdin/stdout type filters with two other editors for a year or two without a any problems.

[ben_josephs]

It works from a 4NT console:

Code: Select all

activate "*TextPad*" & keystack Ctrl-v

so keep trying...!

But this doesn't work from within a user tool. It seems to depend on how the keys are stuffed: AutoIt, which is designed for keyboard stuffing, can do it. So if you can find out AutoIt manages it, your problem is solved. Please let us know...!

[lionelb]

ben_josephs wrote:

It works from a 4NT console:
Code:
activate "*TextPad*" & keystack Ctrl-v

so keep trying...!

But this doesn't work from within a user tool. It seems to depend on how the keys are stuffed: AutoIt, which is designed for keyboard stuffing, can do it. So if you can find out AutoIt manages it, your problem is solved. Please let us know...!

Hi, I did eventually manage to get paste to TP selection working (from a user tool written in C). The problem I had before turned out to be an issue with clipboard "ownership", fixed by a call to the API function EmptyClipboard(). For the key stuffing, the API call SendInput() seems to do the trick. I can post some C code if anyone is interested.

[ben_josephs]

Yes, I'd be interested in this. Thanks. Perhaps by private mail if no-one else is interested.