I didn't think of this originally, but it actually seems only print is affected.

I tried replacing test with this:

function test(rl_buffer)
    rl_buffer:beginoutput()
    os.execute('cmd /c echo test')
end

Now Ctrl+T does print test even after the issue starts. Similarly, putting the same os.execute into the other functions works around the issue completely (although with terrible performance).

So it seems the hooks somehow breaks print, but nothing else...

It appears to be a side effect of cmd.get_errorlevel being true, and is exactly the same issue as #93.

CMD internally handles redirection in a way that is functionally reasonable, but which means the internal actual stdout handle can change whenever redirection is used. And since turning on cmd.get_errorlevel means in between every prompt Clink tells CMD that the user ran echo %errorlevel% > {clink_profile_path}\clink_errorlevel.txt, there's a lot of redirection happening.

The simplest workaround is

print = clink.print

but there are probably other things besides print() that are affected as well.

I originally made the fix for #93 run only once per session. But apparently the issue can recur again later on, so it looks like it will be necessary to repeatedly run the fix code.

Great find -- thank you for reporting it!

Also, thank you for clear descriptions, troubleshooting, and sharing the subtle observation that only print() is affected - that saved me a lot of time and I was able to quickly verify the root cause.

Thanks for the quick fix ❤️

I was looking at issues related to onendedit since I didn't encounter the issue before that script and thus missed #93. Looking at the new changes, I see you added this to the docs: cb33f8f#diff-85ed67821337d5a38659322650b33f0800def9c3ca84a584c59b7bd0bc6c65cdR112-R114

Because onendedit can be stopped, a script must be prepared to receive
onbeginedit but not receive a corresponding onendedit.

Is this referring to a function's return value blocking another function, or is there some other case where the hooks are not called?

Btw, I have some small feature requests/bug reports. Would you prefer I open a seperate issue for each or a single one explaining all of them?

Because onendedit can be stopped, a script must be prepared to receive
onbeginedit but not receive a corresponding onendedit.

Is this referring to a function's return value blocking another function, or is there some other case where the hooks are not called?

Both. The onendedit event does two things:

1. Signals end of editing.
2. Lets a script replace the edited line.

• Because of 2, it needs to be cancelable.
• Because of cancelable 1 is not reliable.
• And because of 2 there are cases where Clink doesn't want to call onendedit -- for example after expanding a doskey macro and I think another case or two where Clink has already done special processing of the input line and doesn't want to let a script alter the behavior. Update: I misremembered -- Clink does not currently skip onendedit unless a script tells it to stop.

So, onendedit ends up not fully reliable as an "editing ended" indicator if a script needs to strictly know every time editing ends.

I'm deferring exploring what to do about that, but I wanted to at least document that it isn't guaranteed to be called.

Maybe I'll make the event happen each time, but make the stopping apply only to the part about replacing the input line?

Btw, I have some small feature requests/bug reports. Would you prefer I open a seperate issue for each or a single one explaining all of them?

I don't mind either way, but if they're separate they can be tracked/closed independently, and they can be searched independently by others.

Depending on how related the issues are, it may or may not be useful to separate them.

I'm going to split onendedit into two separate events:

1. onendedit(command_line) -- this will only signal end of editing, and will be reliably paired with onbeginedit.
2. a second yet-to-be-named event that lets a script replace the edited line.

That will be a breaking change, but it should be very rare that onendedit is being used to replace the edited line, so the impact should be minimal.

Update: I misremembered -- Clink does not currently skip onendedit unless a script tells it to stop.

This is what I was wondering. I understand that other functions can cancel the rest of the chain. But as long as clink itself doesnt do it, its good for me (and assume for most people). If the cancellation only happens because of user scripts, we can always make sure that the functions are registered in the correct order to produce expected behaviour.

I'm going to split onendedit into two separate events

I really havent use this tool enough to comment on this. I'm sure you know what you are doing :D