Add apps to the AppContexts for which `c-y` does not work

[kendonB]

AFAIK, more text editors on Windows use cs-z and not c-y for "Redo". Though I may be wrong. However, "Redo" should be included in each App, if the app redo differs from the default in nav.py.

So, this issue is about:

• deciding whether to use cs-z or c-y as the default
• including the other one in all apps for which the default does not work

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/71818332-add-apps-to-the-appcontexts-for-which-c-y-does-not-work?utm_campaign=plugin&utm_content=tracker%2F1825907&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1825907&utm_medium=issues&utm_source=github).

[LexiconCode]

That's Reasonable. Why don't we take the time to test each app. To see if cs-z is the preferred method "Redo". As you test post name of the apps and I'll check them off here.

X=Success F=Fail Applications require redo c-y remapping.

Applications	cs-z	c-y
atom	- [x]	- [x]
chrome	- [x]	- [x]
eclipse	- []	- []
emacs	- []	- []
excel	- [f]	- [x]
explorer	- [f]	- [x]
firefox	- [x]	- [x]
flashdevelop	- []	- []
foxitreader	- [x]	- [f]
gitter	- [x]	- [x]
jetbrains	- [x]	- [x]
kdiff3	- []	- []
lyx	- []	- []
msvc	- []	- []
notepadplusplus	- [x]	- [x]
outlook	- [f]	- [x]
rstudio	- [x]	- [f]
sqldeveloper	- []	- []
ssms	- []	- []
sublime	- []	- []
totalcmd	- []	- []
typora	- [x]	- [x]
visualstudio	- []	- []
vscode	- [x]	- [x]
winword	- [f]	- [x]

[kendonB]

Some apps allow for both, so there should be two lists.

rstudio:         cs-z works and c-y fails
chrome:          cs-z works and c-y works
firefox:         cs-z works and c-y works
notepadplusplus: cs-z works and c-y works
outlook:         cs-z fails and c-y works
winword:         cs-z fails and c-y works
excel:           cs-z fails and c-y works
explorer:        cs-z fails and c-y works

[drmfinlay]

There is an aenea class I use in these situations called ContextAction. It executes different actions depending on the first dragonfly context in a list that matches, falling back on a default action. It isn't dependent on any part of aenea to work.

An example for "redo" would be:

redo = ContextAction(default=Key("c-y"), actions=[
    # Use cs-z for rstudio
    (AppContext(executable="rstudio"), Key("cs-z")),
])

I find it very useful as an Emacs user. Maybe caster could use something like this?

[LexiconCode]

There is an aenea class I use in these situations called ContextAction. It executes different actions depending on the first dragonfly context in a list that matches, falling back on a default action. It isn't dependent on any part of aenea to work.

I love the idea and it's something that's really needed. There are other inconsistencies besides Redo between editors that could be fixed by such an implementation.

However it will need to be reworked a bit. ensure_execution_context needs to be eliminated and context needs to utilize AppContext

[drmfinlay]

Oh oops. I didn't notice that function was used there. It should be possible to use Window.get_foreground() instead if there is no data.

Yep it simplifies things a lot, especially with CCR.

[LexiconCode]

After talking to @Danesprite he is looking into including ContextAction as part of the Dragonfly framework. Even with ContextAction implemented it is still worthwhile changing windows use cs-z for "Redo". The exceptions can be handled with ContextAction.

[LexiconCode]

ContextAction class is now part of dragonfly v13. Academics are going to keep me busy for the next few weeks but I wanted let you know I hadn't forgotten about this.

[kendonB]

493 starts to fix this issue. However, we need to other add or check other apps. i.e. Emacs. Emacs will be a little tricky, however, because Emacs users can choose between "traditional" and "Emacsy" undo and redo commands, I believe. Someone should correct me if I'm wrong. And we should talk about a way to handle that particular user preference e.g. using an entry in settings.toml

[LexiconCode]

I'm not familiar with using Emacs. Is this part of the setup process to choose between "traditional" and "Emacsy"or is there a default? If it's part of the install process something like settings.toml will have to be used to specify.

[kendonB]

Emacsy is the default in the distributions I've tried. The alternative is known as Cua mode: https://www.emacswiki.org/emacs/CuaMode

I also shouldn't call it "traditional" since Emacs is a very old program and probably predates the Windowsy options.

If I recall correctly, switching to Cua is a menu item but I'm sure you can activate it with a config file too.

[LexiconCode]

As a general rule of thumb it's best to support application defaults in this case Emacsy.

[LexiconCode]

What's the current status of this issue?

[kendonB]

This can be closed once we add Emacs to the action. There is the bigger design question of whether to use ContextAction for these types of things or redefine them in the particular app files as in https://github.com/dictation-toolbox/Caster/pull/530. I actually think I prefer the latter approach.

[LexiconCode]

To clarify, defining them in particular app files?

[kendonB]

Yes just like this one is "redefined" in their right now (obviously this particular one was redefined in error as it's actually the same in firefox).

https://github.com/dictation-toolbox/Caster/blob/36345de83f49010db5c402e4c0768e42b845a5bf/castervoice/apps/browser/browser_shared_commands.py#L50-L51

https://github.com/dictation-toolbox/Caster/blob/36345de83f49010db5c402e4c0768e42b845a5bf/castervoice/apps/browser/firefox.py#L13-L14

[LexiconCode]

The grammar standard API have been removed except as an example. The reasoning for for this change can be found here.

Therefore we can utilize ContextAction or defined them individually within applications.