Skip to content
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

Duplicated code to handle (sequences of) key presses #1830

Closed
rodrigogiraoserrao opened this issue Feb 17, 2023 · 1 comment · Fixed by #1926
Closed

Duplicated code to handle (sequences of) key presses #1830

rodrigogiraoserrao opened this issue Feb 17, 2023 · 1 comment · Fixed by #1926
Assignees
Labels
question Further information is requested Task

Comments

@rodrigogiraoserrao
Copy link
Contributor

rodrigogiraoserrao commented Feb 17, 2023

There is definitely some duplicated code in the codebase with regards to how keys are handled and converted from codepoints to events.
Consider these four instances, which are not necessarily the only ones:

textual/src/textual/app.py

Lines 830 to 837 in be85063

if len(key) == 1 and not key.isalnum():
key = (
unicodedata.name(key)
.lower()
.replace("-", "_")
.replace(" ", "_")
)
original_key = REPLACED_KEYS.get(key, key)

elif len(sequence) == 1:
try:
if not sequence.isalnum():
name = (
_unicode_name(sequence)
.lower()
.replace("-", "_")
.replace(" ", "_")
)
else:
name = sequence
name = KEY_NAME_REPLACEMENTS.get(name, name)

upper_original = original_key.upper().replace("_", " ")

textual/src/textual/keys.py

Lines 266 to 269 in be85063

if not character.isalnum():
key = unicodedata.name(character).lower().replace("-", "_").replace(" ", "_")
else:
key = character

I see lots of very similar bits and bobs, and things like multiple attempts at normalising key/codepoint names, etc.
These should probably be refactored into methods that we can use that will ensure consistency.

Related to: #1815

@rodrigogiraoserrao rodrigogiraoserrao added the question Further information is requested label Feb 17, 2023
@rodrigogiraoserrao rodrigogiraoserrao self-assigned this Feb 17, 2023
rodrigogiraoserrao added a commit that referenced this issue Mar 2, 2023
Throughout the code base, there are a couple of places (noted in #1830) where we take a Unicode name and make it more friendly, or take a 'friendly' name and try to recover the original Unicode name. We add a function to go from 'friendly' to the Unicode name, which tackles the issue highlighted in #1815.

Related issues: #1815, #1830.
@github-actions
Copy link

github-actions bot commented Mar 6, 2023

Don't forget to star the repository!

Follow @textualizeio for Textual updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested Task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant