Missing letters and invalid motion python3 car

[Talos878]

Describe the bug Most if not all the python ccr commands for writing python code ignore the first few letters from their rules and also jump outside parenthesis.

To Reproduce Running python3.9.5 on a Mac 11.4 (20F5055c) I installed Kaldi following the instructions here: https://dragonfly2.readthedocs.io/en/latest/kaldi_engine.html and modified the batch files for installing and running caster turning them into Mac bash scripts

when running the ccr python rules using 'enable python' rules are loosing their first letters upon being run in vim or miswrites. For example, running:

vim

'sub class test' 'convert to integer' 'convert to string' 'convert to character'

produces

ass Test(): nt() tr() r()

also the cursor moves to before the parenthesis instead of inside of them for class. function doesn't seem to write anything

Probable Reason

Caster/castervoice/rules/ccr/python_rules/python.py seems to have a Store() function and occasional typos in the Key("left:3") functions located sparse around the file. Given that this is on OS X I don't want to mess up someone's fix for another os. However, there should probably be some workaround for pulling out these functions on osx. I'm going to make a branch and edit this file to get it working on my box, unless there is something I'm missing or I should be changing something in the Store() function itself.

Thank you for any feedback, it'll be great help with my asses. *whoops meant classes

[LexiconCode]

I appreciate the report! I do not have any mac hardware to test on so this is especially helpful.

Our 1st let's make sure keys are being emulated correctly. Run the following bit of code and see if it produces item instead of tem missing its 1st letter,

from dragonfly import Text

Text("item").execute()

store and retrieve functions uses the following function read_selected_without_altering_clipboard during which Key("c-c").execute() is executed. For some applications like or OSs the shortcuts to copy/paste may be different.

'convert to integer' in Python

        SymbolSpecs.TO_INTEGER:
            R(Store() + Text("int()") + Key("left") + Retrieve(action_if_text="right")),

Does the issue still occur if you remove the store and retrieve from the action?

        SymbolSpecs.TO_INTEGER:
            R(Text("int()") + Key("left")),

[Talos878]

For the basic Text function test everything ran just find it seems

Python 3.9.5 (default, May  4 2021, 03:36:27)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dragonfly import Text
>>> Text("item").execute()
itemTrue
>>> item 

If I take out only the Store() function, it seems to work properly.

        SymbolSpecs.TO_INTEGER:
            R(Text("int()") + Key("left") + Retrieve(action_if_text="right")), 

The above code produces:

>>> int()
0
>>>

and if I take out everything:

        SymbolSpecs.TO_INTEGER:
            R(Text("int()") + Key("left")),

produces the same output as with the Retrieve:

>>> int()
0
>>>

Vim tests show the same output (when I am in insert mode) as the output in the python interpreter.

int()
int()
nt()

I think that the control-c command change may be having a effect on other vim commands like you say though. Even if it isn't this specific one.

For example, if I say 'function'

def ():

I get the expected output, however in vim I get pulled out of insert mode into command mode and nothing is written. Also if I say function while on another word, that word is deleted. Seems like 'function' in vim is escaping back to command mode, then interpreting the 'de' in def as a delete command. Taking the Store() out of Function seems to remedy this also.

[Talos878]

My general takeaway is that the effect of control-c in the Store command does different things for different applications. Vim pulls you into command mode, in the python interpreter it causes keyboardInterrupts on commands.

>>>
KeyboardInterrupt
>>> int ()

For the original intended application that the python stuff was written for it seems the control c and clipboard stuff was useful or necessary for them? Do you know what the original intended use of the Store() functions is? if the implementation of store can check what OS and program it's writing to, then it could possible be altered, otherwise I'll probably just rip them all out and see where that leaves me.

[LexiconCode]

My general takeaway is that the effect of control-c in the Store command does different things for different applications. Vim pulls you into command mode, in the python interpreter it causes keyboardInterrupts on commands.

>>>
KeyboardInterrupt
>>> int ()

For the original intended application that the python stuff was written for it seems the control c and clipboard stuff was useful or necessary for them? Do you know what the original intended use of the Store() functions is? if the implementation of store can check what OS and program it's writing to, then it could possible be altered, otherwise I'll probably just rip them all out and see where that leaves me.

The store and retrieve allows you to highlight text then copy it into the clipboard. If the clipboard is blank it would do not do anything. if there's text you could perform conditional an action on it then pasted the contents of the clipboard. For instance say I have a number 3563763433 I could select that number with the mouse and say and say convert integer produces int(3563763433)

As for the underlying issues. 1st I need to update the clipboard classes in caster as much of that functionality is now built in the dragonfly itself. With my testing on Windows it seems it was a breaking change that went unnoticed.

pip install dragonfly2==0.29.0 it works pip install dragonfly2==0.31.2 does not

2nd There's a way to contextually handle key shortcut differences across OSs and applications. Usually simpler to include just a new grammar vim. However in certain edge cases like this in exception can be made.

If you downgrade dragonfly as shown above does this issue continue to happen and doesn't happen in other programs?

Last but not least what are the shortcuts for mac and vim for copy and paste?

[Talos878]

The store and retrieve allows you to highlight text then copy it into the clipboard. If the clipboard is blank it would do not do anything. if there's text you could perform conditional an action on it then pasted the contents of the clipboard. For instance say I have a number 3563763433 I could select that number with the mouse and say and say convert integer produces int(3563763433)

ooohhh, that's pretty cool

As for the underlying issues. 1st I need to update the clipboard classes in caster as much of that functionality is now built in the dragonfly itself. With my testing on Windows it seems it was a breaking change that went unnoticed.

Yeah, poking around in dragonfly's source, I noticed they really only have clipboard code for windows and some x11 stuff. Are dragonfly developers responsive to requests? Might be able to save you some pain writing that clipboard stuff.

Last but not least what are the shortcuts for mac and vim for copy and paste?

for Mac copy and paste use the command key, which is basically the windows equivalent of the windows key. it sits between control and option (alt)

If you downgrade dragonfly as shown above does this issue continue to happen and doesn't happen in other programs?

ERROR:engine:See https://dragonfly2.readthedocs.io/en/latest/kaldi_engine.html#updating-to-a-new-version
Exception while initializing kaldi engine: Incompatible kaldi_active_grammar version
ERROR:command:Exception while initializing kaldi engine: Incompatible kaldi_active_grammar version

I'm getting this error when trying to downgrade, I downloaded the last 3 Kaldi_model's from the active grammar releases page on Kaldi's GitHub. However, I still get the same error. Any ideas which one will make it happy?

[LexiconCode]

As for the underlying issues. 1st I need to update the clipboard classes in caster as much of that functionality is now built in the dragonfly itself. With my testing on Windows it seems it was a breaking change that went unnoticed.

Yeah, poking around in dragonfly's source, I noticed they really only have clipboard code for windows and some x11 stuff. Are dragonfly developers responsive to requests? Might be able to save you some pain writing that clipboard stuff.

Dane is responsive. However this is something that is an issue Caster side.

There was a time when dragonfly in the original was not developed for years. Dane and I had the idea to fork the repo and he's taking lead on that since. When it was not developed the caster community created their own clipboard class to handle some functionality that was not original dragonfly repo. read_selected_without_altering_clipboard Functionality now exists I believe natively in dragonfly.

Last but not least what are the shortcuts for mac and vim for copy and paste?

for Mac copy and paste use the command key, which is basically the windows equivalent of the windows key. it sits between control and option (alt)

All right

I'm getting this error when trying to downgrade, I downloaded the last 3 Kaldi_model's from the active grammar releases page on Kaldi's GitHub. However, I still get the same error. Any ideas which one will make it happy?

Don't worry about this as it is a bit complicated to downgrade with Kaldi. Kaldi specific questions Could be answered by daanzu in kaldi-active-grammar

[Talos878]

If I go back to 0.31.2 I can swap out

Key("w-c").execute()

for the control command and that works. Apparently the windows key and mac's command basically are interchangeable here.

[Talos878]

Okay, If I come up with anything else like this I'll try to compile a little thing of Mac differences for ya,

[LexiconCode]

Here's an example work with different keys based on different contexts. It's pretty messy in my opinion which is why it's not used frequently. We should be able to do something very similar checking the OS. possibly leveraging FuncContext instead of AppContext.

FuncContext is a class that evaluates a given function/lambda/callable, whose return value is interpreted as a bool, determining whether the context is active vs AppContext which is based on the application context, i.e. foreground window executable, title, and handle

from dragonfly import ContextAction        
        "redo [<nnavi10>]":
            R(
                ContextAction(default=Key("c-y")*Repeat(extra="nnavi10"),
                              actions=[
                                  (AppContext(executable=["rstudio", "foxitreader"]),
                                   Key("cs-z")*Repeat(extra="nnavi10")),
                              ])),

castervoice\lib\contexts.py utilizing FuncContext via MACOS_CONTEXT = FuncContext(is_macos)

Untested but something like the following.

from dragonfly import ContextAction        

           ContextAction(default=Key("c-c"),
                              actions=[
                                  (MACOS_CONTEXT,
                                   Key("w-c")),
                              ]).execute()

[LexiconCode]

@Talos878 and that would be great

[LexiconCode]

@Talos878 see if this temporary branch resolves the issue for you https://github.com/LexiconCode/Caster/tree/clipboard

[LexiconCode]

@Talos878 the bring me command won't work as expected until someone with Mac implements exposing clipboard formats in dragonfly.

[LexiconCode]

Thanks for bringing this up. I've created a new issue to keep track of Mac OS improvements that need to be made.

https://github.com/dictation-toolbox/Caster/issues/895