It is a good idea to use with open(filename) as f: instead of using a combination of open and close.
Python ensures the resources are closed with the context.

The files to be changed are -

• history.py
• commandline.py

Hi, I think it would be nice if mitype could also support other languages like Italian, French, Spanish and so on.

Solution i'd go with
Add other tables to database. Something like data_it, data_es, data_fr... with the same columns as data
Add a commandline feature -l or --lang that let you specify which language you want to write in.
Add a function in database.py that select the text given the id from a given table.
Add a function load_based_on_language to commandline.py

I'd like to work on this. I can also populate the italian db with some phrase.

Currently there is no way to view history
It would be great if I could see how much I'm improving using this typing test if we stored all the previous WPM, Accuracy scores in a local file.

Solution
At the end of a typing run, pressing a button should show the entire history as a list
Something like this:

| date     | time  | wpm   | Accuracy |
---------------------------------------
| 01/10/20 | 21:00 | 40.86 | 94%      |
| 01/10/20 | 21:05 | 45.34 | 95%      |   

And also maybe color-code each entry in the history based on 'below average', 'average', 'above-average', 'master'

I just installed oh-my-zsh to my zsh and i reinstall mitype but when i run mitype on my iTerm2 it says zsh: permission denied: mitype

I already re-install and un-install mitype but it still doesn't work

Subject of the issue

When I start mitype with mitype in cmd on windows I get the error ModuleNotFoundError: No module named '_curses' In some research I found out, that curses is not really supported on windows. To fix this problem I had to runpip install windows-curses. I think that should be documentated.

Your environment

• windows
• mitype: 0.2.0
• python: 3.8.5
• terminal: windows terminal

Steps to reproduce

after a fresh installation of mitype run mitype on windows

Expected behaviour

It should be able to start.

Actual behaviour

PS C:\Users\user> mitype
Traceback (most recent call last):
  File "c:\users\user\appdata\local\programs\python\python38-32\lib\runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\user\appdata\local\programs\python\python38-32\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\user\AppData\Local\Programs\Python\Python38-32\Scripts\mitype.exe\__main__.py", line 4, in <module>
  File "c:\users\user\appdata\local\programs\python\python38-32\lib\site-packages\mitype\app.py", line 3, in <module>
    import curses
  File "c:\users\user\appdata\local\programs\python\python38-32\lib\curses\__init__.py", line 13, in <module>
    from _curses import *
ModuleNotFoundError: No module named '_curses'

Your proposed fix (if any)

run pip install windows-curses

Since mitype is seeing some docstring improvements (#52), it would be a good time to also work on the sphinx documentation.

Currently the Sphinx setup lies in docs folder.

There were several changes to the project like moving from README.rst to README.md and the setup is very outdated.

Sometimes user might not realize he's typing incorrectly and continue typing multiple words. In such a scenario, one may prefer erasing the entire word with the help of the ctrl + backspace combo.

For example -
Current string is "quqick brown"

Pressing the key combo should erase the latest word -
Current string becomes "quqick "

And hitting a second time should erase the other word too
Current string becomes ""

It would be nice to be able to hit a key to restart the program instead of closing out and calling mitype after every run.

Pressing ESC key while the test has already started should reset the text. Note: Currently replay mode cannot detect ESC key. So this issue applied to test mode only and not replay mode.

Steps to reproduce

Start mitype. Reduce the size of the terminal vertically. It will crash after a certain point where screen becomes smaller than what is required to print the text.

Expected behaviour

Mitype should:

1. Print to stdout a user friendly text message like "Window too small to print given text"
2. Exit

Actual behaviour

Crashes with traceback -

  File "/home/mithil/p/mitype/mitype/app.py", line 354, in resize
    self.setup_print(win)
  File "/home/mithil/p/mitype/mitype/app.py", line 173, in setup_print
    win.addstr(2, 0, self.text, curses.A_BOLD)
_curses.error: addwstr() returned ERR

Your proposed fix

We have implemented a size check in the initialize method in app.py already which warns the user that the terminal is smaller than the amount of lines required. We can use a similar check in resize method.

Mistyped characters are highlighted during the test. Similarly, all the mistyped characters should be highlighted at once at the end of the test.

Example:

Please refer to #81 for the proposed solution mentioned here.

Thanks to @CorentinGaillard for suggesting this issue and for their contributions to it!

I'd love to be able to visualize the error I made during the run, as in the screenshot.

Also, the same app (here) displays a "fluidity" score, which is higher the more stable you are while typing.
I believe it can be calculated from something like the variance of the time interval between two keystrokes.

1. Support Chinese
2. Ignore the comment. The comment start identifier (such as #) can be specified by the user or determined by the file suffix name
3. Ignore multiple spaces and merge multiple Spaces into one. or just ignore tailing blank spaces

Subject of the issue

Following the contributors guide, running tox -e 2.7 on mitype gives error.

line 5, in <module>
        with open("README.md", encoding="utf-8") as f:
    TypeError: 'encoding' is an invalid keyword argument for this function

Expected behaviour

Should work fine.

Actual behaviour

Command errors out with exit status 1

Your proposed fix (if any)

We gotta modify that line under setup.py. But please be careful, because this file decides how mitype appears on pypi.

Pin the red color on the mispelled letter

Steps to reproduce

• If the user misspelled a word, the red color will be pinned exactly on the first misspelled letter

Expected behaviour

Actual behaviour

Your proposed fix (if any)

I would like to work on this enhancement, if possible. I believe that it is a good enhancement because the actual behaviour for new users can be quite confusing. At first I did not understand that I mispelled a word and I continued to type.

Also, I am having some troubles to run the code locally. My changes does not have any effect on the application. I read the build.md file, can you explain with more details how to run in development mode?

Is your feature request related to a problem? Please describe.
It's not much of a problem but a way to bring more traction to this project, you must have seen websites where you can do some things and share your results on social media which brings more people into the project from there following and so on.....

Describe the solution you'd like
When the user completes the test we can provide a key combination which will open Twitter with pre-typed results like number of words, time taken, Words per minute, and a tag to your Twitter handle as a creator or you can create a Twitter handle of this project itself :p

If it is not related to any problem
I already did :)

Additional context
Not sure about this, but if there is any way to capture the window the user typed into and use this captured image in the tweet will be more awesome and no one can tampure with that kind of result compared to some pre-typed text

Is your feature request related to a problem? Please describe.
It's a one-step simple problem that is people need to install two pip packages separately to run mitype on windows

Describe the solution you'd like
There are a lot of examples of how to deal with dependencies that are OS-dependent. Check out some on stackoverflow, another stackoverflow and the docs on PEP 508

If it is not related to any problem
It's more of a convenience thing more than a problem

Currently we are only displaying the typing speed. We can add other attributes like Accuracy and Time taken nearby.

Got the project running on windows with your instructions , pressing the windows key during the typing test causes it to crash.

Platform: Windows 10
Version: Clone from master @ commit d14b810
Stacktrace:

Traceback (most recent call last):
  File "local_test.py", line 5, in <module>
    obj.start()
  File "F:\PythonProjects\mitype\mitype\app.py", line 192, in start
    curses.wrapper(self.main)
  File "C:\Users\Kriticalflare\AppData\Local\Programs\Python\Python38-32\lib\curses\__init__.py", line 105, in wrapper
    return func(stdscr, *args, **kwds)
  File "F:\PythonProjects\mitype\mitype\app.py", line 169, in main
    self.KeyPrinter(win, key)
  File "F:\PythonProjects\mitype\mitype\app.py", line 107, in KeyPrinter
    win.addstr(self.LineCount, 0, self.CurrentWord)
ValueError: embedded null character

Subject of the issue

I clicked the replit link out of curiosity, but It's missing a main.sh, so it won't run

Your environment

Windows 10 - Edge
replit environment:
python 3.8.10 (at the time of writing)
GNU bash 4.4.20

Expected behaviour

The program should launch automatically when the environment loads, or be a few steps from launching

Actual behaviour

We get an error saying unable to run, main file "main.sh" not found.
I tried installing mitype with pip install . --user and then launching with python mitype/__main__.py but I got ModuleNotFoundError: no module named mitype

After completing the test, we see the stats -

The cursor is placed at the end.

Let's hide the visibility of the cursor when displaying stats after test. But the cursor must be visible for the rest of the time.

Refer to the python curses documentation here.

Subject of the issue

The keyboard and star struck emojis dont render properly

Your environment

• operating-system - Windows 10 1903
• version of Mitype - cloned @ 8a51950
• version of Python - Python 3.8.0
• terminal - cmd

Steps to reproduce

clone and run local_test.py

Expected behaviour

The emojis to render

Actual behaviour

Emojis dont render

Subject of the issue

The backspace key instead of deleting the previous character , it acts as invalid input.

Your environment

• Windows 10
• Cloned @ 9091830
• Python 3.8.0
• cmd prompt

Steps to reproduce

Press the backspace key

Expected behaviour

Delete the previous character

Actual behaviour

It doesnt delete the previous character but rather acts as invalid input ( as it doesnt match any of the characters)

For example, if currently I am on text with ID=450.
Pressing right arrow key should load text with ID=451.
Similarly, now pressing the left arrow key twice should load text with ID=449.

This situation doesn't exist by itself without creating manually.

If the ~/.mitype_history.csv exists without header, only as empty file, mitype crash with a StopIteration exception.

It can be reproduced easily :

$ mv ~/.mitype_history.csv .mitype_history_save.csv   # Save your record logs
$ touch ~/.mv .mitype_history.csv                                 # Create an empty file without header
$ mitype --history                                                          # Try to print records history
Traceback (most recent call last):
  File "/home/romain/.local/bin/mitype", line 8, in <module>
    sys.exit(App())
  File "/home/romain/.local/pipx/venvs/mitype/lib/python3.9/site-packages/mitype/app.py", line 42, in __init__
    self.text = resolve_commandline_arguments()[0]
  File "/home/romain/.local/pipx/venvs/mitype/lib/python3.9/site-packages/mitype/commandline.py", line 29, in resolve_commandline_arguments
    show_history(opt.history)
  File "/home/romain/.local/pipx/venvs/mitype/lib/python3.9/site-packages/mitype/history.py", line 39, in show_history
    next(history_reader)
StopIteration

Hey everyone 👋

I am very happy to see all the love this project has been receiving! 💟

This thread is dedicated for discussions related to improvement of mitype and a place to share your ideas.

We would love to have your sugestions, so feel free to comment them below 😄

Steps to reproduce

Start a new test.

Expected behaviour

Set the cursor position to start of text.

Actual behaviour

Tell us what happens instead
The cursor's default position is at the end of text.

Is your feature request related to a problem? Please describe.
Not a problem but an enhancement to the application.

Describe the solution you'd like
It will show up on the top left corner of the screen and as the user types, it will update the value automatically in real-time.

If it is not related to any problem
It is not a problem but an enhancement to show realtime WPM speed to users.

Additional context

Subject of the issue

I would go look at it now, but I am busy, but here is the traceback of the error I've come across.

Your environment

Ubuntu 16.04.7 LTS
Mitype version 0.2.3
Python 3.8.11
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)

Steps to reproduce

I finished almost all of the typing test, but then when I missed the period around the end and hit and then tried backspacing and correcting my mistake, it crashed with the following:

Traceback (most recent call last):
File "/home/user1/.pyenv/versions/3.8.11/bin/mitype", line 33, in
sys.exit(load_entry_point('mitype==0.2.3', 'console_scripts', 'mitype')())
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/site-packages/mitype/app.py", line 85, in init
curses.wrapper(self.main)
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/curses/init.py", line 105, in wrapper
return func(stdscr, *args, **kwds)
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/site-packages/mitype/app.py", line 117, in main
self.typing_mode(win, key)
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/site-packages/mitype/app.py", line 176, in typing_mode
self.key_printer(win, key)
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/site-packages/mitype/app.py", line 276, in key_printer
self.update_state(win)
File "/home/user1/.pyenv/versions/3.8.11/lib/python3.8/site-packages/mitype/app.py", line 372, in update_state
self.text[i],
IndexError: string index out of range

Expected behaviour

Not error.

Actual behaviour

Error.

Your proposed fix (if any)

If I am able to get to it soon, I'll edit this section later.

Subject of the issue

Unfortunately if I try to take the test with a German text with the -f flag I am not able to input characters needed for some words (like ä, ö, ü).

Your environment

• OS: Debian 10
• MiType: 0.1.3
• Python 3.7.3

Steps to reproduce

Grab yourself a German text like this:

Zu meiner Familie gehören vier Personen. Die Mutter bin ich und dann gehört natürlich mein Mann dazu. Wir haben zwei Kinder, einen Sohn, der sechs Jahre alt ist und eine dreijährige Tochter.

Save it to an file and run
$ python3 -m mitype -f <file-name>
And try to get pass the gehören word.

Expected behaviour

We should expect Mitype to handle special characters.

Actual behaviour

Sadly you can not press the special char keys, they will just be ignored.

Subject of the issue

Mitype crashes upon typing more characters than text length.

Steps to reproduce

Load any text of length 'n'. Type any character except spacebar, n times or more. Then hit spacebar.

Expected behaviour

The app should continue working fine.

Actual behaviour

Crashes with traceback:

mitype/calculations.py", line 73, in get_space_count_after_ith_word
    while text[index] == " ":
IndexError: string index out of range

Your proposed fix (if any)

The traceback is very clear. We could use a simple check to see if index isn't out of range.

This issue is concerning the desire to fix some inconsistent docstrings as well as to fix a minor typo or two.

For docstrings, the desire is to more consistently format them in accordance to pydocstyle, and as requested, I'll also try and add some additional ones on existing functions/methods.

For typos, I have found one or two spelling errors that I would like to tackle at the same time.

These are some of the changes required to achieve this -

• Remove any version checks and code supporting Python 2
• Remove __future__ imports
• Remove Python 2 classifier from setup.py
• Update any comments or docstrings written for Python 2
• Update README

Subject of the issue

Input text is being repeated on resizing window

Your environment

• operating-system - Windows 10 1903
• version of Mitype - cloned @ 8a51950
• version of Python - Python 3.8.0
• terminal - cmd

Steps to reproduce

clone the repo.
Open cmd , it should open unminimized by default
Run local_test.py
Maximize cmd window

Expected behaviour

The typing window to resize to properly utilize the full width of cmd screen

Actual behaviour

On typing the text from second line is being moved to the first line

Before typing

After typing

Steps to reproduce:

Start mitype, preferably with a relatively lesser width terminal window.
Spam any wrong keys so that the text overflows to next line as shown below.

Try to clear those keys by pressing backspace.

Expected behaviour

Backspace should clear all the keys consistently.

Actual behaviour

The logic works as expected and does indeed clear text but doesn't update the screen visually for the lines below, but works fine for top line.

Proposed fix

Maybe we need to clear the entire screen if that is feasible.

Subject of the issue

Pressing arrow keys at the beginning of the test changes the text to the new text. But resizing the window afterwards would reset the text to the initial text.

Steps to reproduce

• Start mitype.
• Press arrow keys to change the text to subsequent values.
• Resize the window.

Expected behaviour

Text should stay as the latest value.

Actual behaviour

Text resets to the previous text.

Proposed fix

Text is reset with the help of original_text_formatted here -

There is enough space to fit in the ID of the current text from database at top left.

This is a good feature as the user might like a particular text, but there is no way to retest on the same text.
With this feature user can get the ID and rerun mitype -i ID

App crashes when certain keys are pressed.

Steps to reproduce

Run mitype. Press any of these keys:

• Any key on numpad when numlock is off.
• Arrow keys
• fn + function keys

Expected behaviour

These key presses should be ignored.

Actual behaviour

Traceback:

  File "/home/mithil/p/mitype/mitype/app.py", line 84, in main
    self.typing_mode(win, key)
  File "/home/mithil/p/mitype/mitype/app.py", line 108, in typing_mode
    self.key_printer(win, key)
  File "/home/mithil/p/mitype/mitype/app.py", line 198, in key_printer
    self.appendkey(key)
  File "/home/mithil/p/mitype/mitype/app.py", line 239, in appendkey
    self.current_word += key
TypeError: can only concatenate str (not "int") to str

Your proposed fix (if any)

Add functions to keycheck.py to check for such keys for their string value or integer value.

Subject of the issue

The app is not quitting in test or replay mode using ctrl+c. It only quits in test mode pressing esc.

Your environment

Windows 10
0.2.0
3.7.3
Windows cmd

Steps to reproduce

1. Run the app
2. Press ctrl+c

Or

1. Run the app
2. Finish a test
3. Press enter
4. Press ctrl+c

Expected behaviour

The app should exit

Actual behaviour

In test mode, "^C" appears in the lower area where the current word usually appears. On the other hand, nothing happens in replay mode. In fact, the app can only be closed by closing the cmd window from that point on.

Your proposed fix (if any)

I believe the app is registering ctrl+c as a keystroke for the typing test and not as the usual "exit program" command. I would like to fix this for this year's Hacktoberfest.

Whenever i finish typing on a dataset in mitype it will show only two of the following option.

Enter to see replay, Tab to retry

So, to type on new dataset i have to restart it.
Their should be a third option to type on a new dataset.

Subject of the issue

When I try use text larger that the screen the code broke.

Your environment

• operating-system
  Mac OS X Catalina
• version of Mitype
  0.1.6
• version of Python
  python 3.7.3
• which terminal and it's version if applicable
  iterm

Problem may be in wrap_text method.

Steps to reproduce

1. Attempt a test.
2. Note the time taken.
3. Play the replay.
4. Notice that the time taken is more.

Expected behaviour

Replay should reflect moderately similar speed.

Actual behaviour

Replay is slower and takes longer to finish. There's much more time difference between 2 key presses.

Your proposed fix (if any)

A better way to catch the ESC key without timeout would really be helpful. Although, the timeout was introduced to fix #12.
Is there a way to register a signal for the ESC key, just like we have for ctrl-c in signals.py?

When inside replay mode, sometimes exit would take a long time. Applicable to all environments.

Steps to reproduce

Run any Mitype session, wait for at least about 5-6 seconds in between any 2 keys so that the delay is noticeable. Then during replay press Esc key as soon as that particular key-press is being replayed.

Expected behaviour

Mitype should exit as soon as Esc key is pressed

Actual behaviour

The exit is delayed till the next key is displayed.

Subject of the issue

While using mitype with Plover for stenography, Plover will add a space before each word you type, which makes mitype say the word is invalid.

Your environment

• Arch Linux 5.8.12-arch1-1
• mitype 0.2.0
• Python 3.8.5
• kitty 0.18.3

Steps to reproduce

Install Plover and try to do a typing test in mitype with it enabled.

Expected behaviour

Mitype should accept the input as valid.

Actual behaviour

Mitype says the word is invalid.

Your proposed fix (if any)

#47

Subject of the issue

Typing window doesnt adapt to resizing cmd window

Your environment

• operating-system - Windows 10 1903
• version of Mitype - cloned @ 8a51950
• version of Python - Python 3.8.0
• terminal - cmd

Steps to reproduce

clone the repo.
Open cmd , it should open unminimized by default
Run local_test.py
Maximize cmd window

Expected behaviour

The typing window to resize to properly utilize the full width of cmd screen

Actual behaviour

The typing window doesnt adapt to the change in cmd window size.

Steps to reproduce

• Install mitype in a fresh virtualenv

Expected behaviour

• A mitype script should be generated in <venv-path>/bin

Actual behaviour

• Nothing is generated and you have to use python -m mitype to launch the app

Your proposed fix

• I can try and make a PR but if your goal is to learn more about package management you should try and fix this yourself 😛

Nice app by the way :)

The formatting is messed up for the return section with multi-line description.
For example https://mithil467.github.io/mitype/api.html#mitype.keycheck.is_escape.

Expected behaviour

Formatting should be the same for all lines.

Actual behaviour

Your proposed fix

With reference to the solution mentioned in issue sphinx-contrib/napoleon#4, all the docstrings with multi-line return section need to be indented accordingly as -

    Returns:
        bool: Returns `True` if pressed key is ESC key.
        Returns `False` otherwise.

Subject of the issue

One of my CPU cores gets maxed out at a 100% the moment I start mitype

Your environment

• Linux
• Mitype 0.1.8
• Python 2.7.12
• GNOME Terminal 3.18.3

Steps to reproduce

• Open mitype.
• One CPU core is maxed out at 100% until I close mitype

Expected behaviour

Normal CPU usage

Actual behaviour

100% CPU usage on one core

Currently, you can see the stats only when the test or replay has finished.

But during the replay there is no way of knowing what the stats were.

When user hits enter to replay, we should display the stats at the bottom of the screen on the last line.

It feels like some other position like top right would have worked as well, but that is because we only have 1 stat currently.
But very soon we will be having a few more (see #16 ) , so last line seems feasible.

A limit for length of characters for current_word was imposed in PR #66.
But pressing spaces once the limit is reached still adds up in current_word.

Steps to reproduce

1. Start a test.
2. Press incorrect keys till word limit of 25 is reached.
3. Press space.

Expected behaviour

Spaces should not be added once the length limit is reached.

Actual behaviour

Spaces are still added.