-
Notifications
You must be signed in to change notification settings - Fork 783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
override peek implementation for libreoffice #1532
base: main
Are you sure you want to change the base?
Conversation
mod.apps.libreoffice = """ | ||
os: linux | ||
and app.exe: soffice.bin | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add the windows matcher
os: windows
and app.exe: soffice.bin
return (before, after) | ||
|
||
|
||
def repeat_action(action: Callable, count: int): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove this function and just inline it. It's actually fewer lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think inlining this increases clarity. In fact, I copied the function from core/edit/edit_navigation_steps.py
. So I would prefer moving this to the right place instead, whatever the right place is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Andreas, I found this harder to parse. For a two-line function I agree we should just inline it - otherwise it leads the reader to try to understand why the function was necessary (performance? etc).
While edit_navigation_steps.py
does have many functions like this, it has so many that the pattern becomes more understandable.
Apologies for being silent on this for so long. I realized that, while this works really well for a normal text, it still fails miserably when editing text in tables: then running out of words |
Feedback from the community backlog session. If we can't actually get this to work reliably in both text and tables we are kind of leaning towards actually just disabling context sensitive dictation by default in libre office with a comment about the failure mode for tables. Then we can actually merge this change and if people want to use it it's up to them. |
return (before, after) | ||
|
||
|
||
def repeat_action(action: Callable, count: int): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Andreas, I found this harder to parse. For a two-line function I agree we should just inline it - otherwise it leads the reader to try to understand why the function was necessary (performance? etc).
While edit_navigation_steps.py
does have many functions like this, it has so many that the pattern becomes more understandable.
Looks like clip.mime().html has s etc for a table selection. We could potentially use this to determine if we are in a table and in that case don't do this cursor dance. |
I don't understand how this is supposed to work. After all, by the time we can use That being said, I disagree that "just disabling smart insertion by default" is a viable option. I find it absolutely indispensable when editing normal text, even though it is utterly useless (or a major hindrance) in certain contexts. Maybe this shouldn't be a fixed setting for a given application, instead there should be a command to quickly toggle that. How would one go about implementing this? |
It might be enough to select a single character and then get the html text. This would be a pre stage before doing any further "cursor dance". We are not sure if this is a viable solution, but might be worth looking into. All Talon settings are already context based. This means you can enable or disable context sensitive dictation in any application or other matchable context. What we suggested was that it by default should be specifically disabled in libre office with a comment describing why. People can still enable it if they want to. |
This only matches for
libreoffice
on Linux. I don't have access to Windows or Mac OS, so I don't know whatlibreoffice
calls itself on those operating systems.