Keystroke plugins question

[Charles Dye]

Rex:

Is there any way that a keystroke plugin can get/set the selection range of the command line, as Shift-Left, Shift-Right, Shift-End, etc. do?

 

[vefatica]

Rex:

Is there any way that a keystroke plugin can get/set the selection range of the command line, as Shift-Left, Shift-Right, Shift-End, etc. do?

Just guessing ... none that would involve the cooperation of TCC.
An observation: TCC's select/copy with keystrokes seems to be independent of Windows mouse mechanism.
With considerable effort, a keystroke plugin might watch for the selection keystrokes (letting them be processed) while trying to keep track (yourself) of what's being selected. I also suppose you could scour the command line, as it exists in the console screen buffer, looking for the alternate attributes (colors) TCC ascribes to selected text. And I suppose a keyhandler could inject TCC selection keystrokes and (try to) keep track of what they're doing. None of those sound like fun.
I'm curious. What do you want to do?

 

[Charles Dye]

Just guessing ... none that would involve the cooperation of TCC.
An observation: TCC's select/copy with keystrokes seems to be independent of Windows mouse mechanism.
With considerable effort, a keystroke plugin might watch for the selection keystrokes (letting them be processed) while trying to keep track (yourself) of what's being selected. I also suppose you could scour the command line, as it exists in the console screen buffer, looking for the alternate attributes (colors) TCC ascribes to selected text. And I suppose a keyhandler could inject TCC selection keystrokes and (try to) keep track of what they're doing. None of those sound like fun.
I'm curious. What do you want to do?

Playing with this idea: jpsoft.uservoice.com/forums/94009-take-command/suggestions/2837608-add-keystroke-to-remove-argument-to-the-left-of-cu

Moving by arguments is not terribly difficult; deleting by arguments is not terribly difficult. Selecting by arguments would just be more of the same if plugins had some way to communicate with the line editor's selection mechanism. I don't think it exists -- but would be happy to hear differently.

 

[vefatica]

Playing with this idea: jpsoft.uservoice.com/forums/94009-take-command/suggestions/2837608-add-keystroke-to-remove-argument-to-the-left-of-cu

Moving by arguments is not terribly difficult; deleting by arguments is not terribly difficult. Selecting by arguments would just be more of the same if plugins had some way to communicate with the line editor's selection mechanism. I don't think it exists -- but would be happy to hear differently.

That article deals with deleting the argument to the left of the cursor. I'm pretty sure you could do that without dealing with selection. There may be slicker ways, but I'd bet you could ... say upon Ctrl-BackSpace, examine the command line to figure out how many backspaces need to be sent, and send them with SendInput().

Slicker might be to start at pszCurrent and, working backwards, turn characters in pszLine into NULs ... possibly having to, at the same time, overwrite them with spaces in the console screen buffer ... but fRedraw might do that for you.

 

[vefatica]

The code below works and is visually fine. It's not perfectly functional since it doesn't consider words grouped into a parameter with quotes. Using a modified key would be tricky because the modifier key would almost certainly still be down when the plugin sends BACKs (and they wouldn't be processed correctly) ... I used F2 just because it was available. It can be used repeatedly since it first removes immediately-preceding spaces. It can even be used inside a parameter (good/bad?) in which case it removes lefthand portion of the parameter.

Maybe you can elaborate on it, Charles. Or maybe Rex will tell us how easy it is to do the right way. :)

    if ( lpki->nKey == F2 )
    {
        DWORD MaxBSCount = lpki->pszCurrent - lpki->pszLine;
        DWORD BSCount = 0;
        // remove trailing spaces before the current position
        for (    BSCount=0;
                BSCount <= MaxBSCount && *(lpki->pszCurrent - 1 - BSCount) == L' ';
                BSCount++ );
        // then remove until a space is encountered
        for (    ;
                BSCount <= MaxBSCount && *(lpki->pszCurrent - 1 - BSCount) != L' ';
                BSCount++ );
        lpki->nKey = 0;
        INPUT input[2] = {{INPUT_KEYBOARD, 0}, {INPUT_KEYBOARD, 0}};
        input[0].ki.wVk = input[1].ki.wVk = VK_BACK;
        input[1].ki.dwFlags = KEYEVENTF_KEYUP;
        for ( INT i=0; i<BSCount; i++ )
            SendInput(2, input, sizeof(INPUT));
        return 0;
    }

 

[rconn]

Rex:

Is there any way that a keystroke plugin can get/set the selection range of the command line, as Shift-Left, Shift-Right, Shift-End, etc. do?

No. The pointers to the start & end of the selection are not (currently) exposed outside of the command line input module.

 

[Charles Dye]

That article deals with deleting the argument to the left of the cursor. I'm pretty sure you could do that without dealing with selection.

No, I don't need it for that; I've already implemented the move-by-arg and delete-by-arg keys. I just thought it would be nice to also provide the corresponding select-by-arg keys, so they all work the same way. But if I can't tap in to Rex's selection functions, then it's not possible; providing my own incompatible selection mechanism would be (1) confusing and (2) useless.

 

[Charles Dye]

No. The pointers to the start & end of the selection are not (currently) exposed outside of the command line input module.

Thanks. I figured that was the case, but I'm wrong often enough....