Line break breaks everything

[ghost]

So this is related to the last issue that I opened. Na2hiro mentioned that he mapped the line-break ("enter") to restarting the drill because 1. it was handy and 2. the line break broke things anyway. My issue with the hotkey was that I sometimes stroked R*R by mistake. I was explained how to remove the hotkey.

However, while before I mentioned that if you backstroke then you can safely continue, I discovered today (more than once) that it was not the case. When you do a line break the "text cursor" goes down one line to a phantom line. Neither undoing the stroke with *, backspacing with the "regular keyboard" backspace nor clicking with the mouse on the "real line" prevents everything from going bananas on the next strokes.

I do not know what exactly causes it and not being a JS programmer I'm not much of help, but still from my perspective I see one possible work around. When things work properly, you type in words that get marked green or red in accordance to whether they were typed correctly or not. As you type, the words on your tail "disappear": they are "submitted" and you can no longer edit them --- if you "delete everything" then you are back only so many words, not to the very beginning of the exercise. Perhaps "enter/ line breaking" can be used as a command to "submit all"? It would "submit" all the words you have typed before the current word and clear the input box. The reason I think this would fix the issue is that while backspacing does not help preventing the app from going bananas, "selecting all" and "deleting" does, although at the expense of deleting the five or so last words you have typed. Having "enter" being a "submit and clear" command you prevent the program from going crazy and "keep" the last words you already typed. Just one idea.

Cheers and thanks again for the great jig!

[JoshuaGrams]

Yeah...I'm afraid there's no quick fix for that. I made the mistake of using a contenteditable div for the input, and they're generally just horrible to work with. So it doesn't get newlines at all: when you enter a newline the browser makes each line a separate div, and getting the textContent of the input sees the two words before and after the newline concatenated together with no whitespace in between. And for some reason it also seems to confuse the saveSelection/restoreSelection code which handles the cursor position. Which is not my code (I just grabbed it from a Stack Overflow answer) so I have no idea what's going on there.

So it really needs a rewrite to use a hidden textarea and copy the contents to the visible "input" element for display. Before I lost interest about a year ago, I started doing that on the new-display branch: you could try using that instead and see if it works for you?

Honestly, steno-jig is mostly unmaintained at this point: it has been 11 months since I did any real work on it, and nearly two years since I came to the conclusion that the core open steno community is never going to provide what I'm interested in (a theory and a path into steno that is oriented toward being as consistent, easily memorizable, and quickly learnable as possible) and quit practicing steno. I've been trying to keep doing the easy fixes and incorporating pull requests because I know a bunch of people have gotten good use out of it. But this one is probably a WONTFIX. Sorry...

[ghost]

I see. That's a pity you were disappointed by the open steno community. Anyhow, thanks for still doing the easy fixes and pulls! Cheers,