@@key aliases cause new prompt?

An alias like @@key=`activate "..."` causes a new prompt to show ... use it several times and the console fills up with unused prompts. Is there a way to suppress the new prompt? If not, perhaps there will be in V12.

 

On Fri, 21 May 2010 20:56:50 -0400, rconn <> wrote:

|---Quote---
|> An alias like @@key=`activate "..."` causes a new prompt to show ...
|> use it several times and the console fills up with unused prompts. Is
|> there a way to suppress the new prompt? If not, perhaps there will be
|> in V12.
|---End Quote---
|WAD, and there's no way to suppress it (nor will there be in v12).

What if a plugin keyhandler used Command(), during command line entry, to
execute something like ACTIVATE ... would that cause a new prompt, or mess up
the current command line?
--
- Vince

 

On Fri, 21 May 2010 21:57:58 -0400, rconn <> wrote:

|---Quote---
|> What if a plugin keyhandler used Command(), during command line entry,
|> to execute something like ACTIVATE ... would that cause a new prompt, or
|> mess up the current command line?
|---End Quote---
|No new prompt, provided you pass 0 as the second arg to Command(). If you
|use the same buffer as the original command line entry, it will definitely
|destroy the current command line. If you copy the original buffer to a new
|one and use that for Command(), then the only thing you'll mess up is the
|batch debugger.

I tried it like this and **did** get a new prompt.

if ( lpKeyInfo->nKey == F7 )
{
WCHAR szCmd[32] = L"ACTIVATE \"V - *\" 2> NUL";
Command(szCmd, 0);
return 0;
}
--
- Vince

 

On Fri, 21 May 2010 22:55:35 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|What if a plugin keyhandler used Command(), during command line entry, to execute something like ACTIVATE ... would that cause a new prompt, or mess up the current command line?
|---End Quote---
|If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?

None. I didn't even think of it.

--
- Vince

 

On Fri, 21 May 2010 22:55:35 -0400, Charles Dye <> wrote:

|If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?

Now that I think of it (and having tried it) ... you can't put the "2> NUL" in
ACTIVATE's arguments. Rex, ACTIVATE could use a /q(uiet) option.
--
- Vince

 

On Sat, 22 May 2010 12:25:18 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|On Fri, 21 May 2010 22:55:35 -0400, Charles Dye <> wrote:
|
||If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?
|
|Now that I think of it (and having tried it) ... you can't put the "2> NUL" in
|ACTIVATE's arguments. Rex, ACTIVATE could use a /q(uiet) option.
|---End Quote---
|I haven't tried it myself, but I imagine it wouldn't be difficult to do your own redirection via DuplicateHandle(). (Just be sure to save the original stderr handle, and put it back when you're done!)

Actually, Command() worked OK (not causing a new prompt) when I added

lpKeyInfo->nKey = 0;

before returning. This actually leaves the command-line-in-progress untouched
so it can further edited and executed.

I'm experimenting with the file viewer "V". I wrote a user tool for V which
gives foreground to V's parent and assigned the tool to F7. With my F7 routine
(previously mentioned, added to a keyhandler already in my 4CONSOLE plugin) I
can switch seamlessly between V and the console, leaving command lines intact
(perhaps if I wanted to copy something from the viewed file and paste it into
the command).

I like this kind of key mapping, in which some action happens invisibly
regardless of the position in the current command line (unlike keystroke
aliases). But implementing it in a way in which the user could specify
key/command combinations would be tedious; I'd need a routine for turning
user-specified key names into TCC's internal key codes (see the end of
TakeCmd.h).
--
- Vince

 

On Sat, 22 May 2010 18:35:33 -0400, rconn <> wrote:

|---Quote---
|> Rex, ACTIVATE could use a /q(uiet) option.
|---End Quote---
|What good would that do? ACTIVATE doesn't display any text.

I meant an option to suppress error messages.
--
- Vince

 

On Sat, 22 May 2010 21:07:49 -0400, rconn <> wrote:

|---Quote---
|> |---Quote---
|> |> Rex, ACTIVATE could use a /q(uiet) option.
|> |---End Quote---
|> |What good would that do? ACTIVATE doesn't display any text.
|>
|> I meant an option to suppress error messages.
|---End Quote---
|/Q never suppresses error messages -- I don't think it'd be a good idea to
|introduce a /Q option to ACTIVATE that worked differently than the /Q in
|every other command!

Do **any** commands have an option to suppress error messages? If so, that's
what I had in mind for ACTIVATE.
--
- Vince