You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello there @murarth
Our team has been using your linefeed library in our project and while its very good, it does have some bugs (seemingly centered around Windows machines) and would like to help resolve them, if you would be kind enough to provide some attention to this.
Our developers and users do enjoy the functionality that linefeed gives you, but these flaws certainly spoil the overall image of it. Also I’m convinced that our users would be of a similar mind.
I do see some of our issues are outlined on open Issue cards, so we will do our best to summarize below.
Windows specific from what we can see - the terminal’s cursor stays statically printed on the screen at a certain line although we’ve already moved to another line (one or far away) with an active cursor, blinking.
After you reset the terminal or scroll out of the area and come back then, you cannot see it anymore as the inner area of the terminal window has been re-rendered. I assume that it’s something to do with what you’re doing with hiding and showing the cursor (for example, at on our test, we saw some suspicious escape sequences in the output, which was supposed to be blank string; this pointed us to that thought too).
Again mainly Windows, as far as we know - certain machines (the latest or modern Windows distributions) we experience unpleasantly slow backspacing. It’s most noticeable if you have long sequence of chars at the command line and you want to delete a bigger amount of them. If you just press backspace for a whole you will see that although you draw your finger back the cursor continue going back deleting some more characters. In this way you cannot control how many characters should be deleted exactly.
Its preferred to give our users possibility to use some of those standard key combinations meant to tell to carry out certain action. For example, we’d like to have ctrl+c working. However, despite your library contains API for handling signals, these signals turn out unresponsive in the end. And this time it seems like it groups all platforms together (Linux, Windows, Mac) in this matter.
Note: ctrl+d is the only signal that can be currently handled.
The text was updated successfully, but these errors were encountered:
I'm sorry, I no longer have the time to maintain this project or to make improvements. If you want to make improvements to linefeed, I welcome you to fork it and publish to crates.io under a new name.
Hello there @murarth
Our team has been using your linefeed library in our project and while its very good, it does have some bugs (seemingly centered around Windows machines) and would like to help resolve them, if you would be kind enough to provide some attention to this.
Our developers and users do enjoy the functionality that linefeed gives you, but these flaws certainly spoil the overall image of it. Also I’m convinced that our users would be of a similar mind.
I do see some of our issues are outlined on open Issue cards, so we will do our best to summarize below.
Windows specific from what we can see - the terminal’s cursor stays statically printed on the screen at a certain line although we’ve already moved to another line (one or far away) with an active cursor, blinking.
After you reset the terminal or scroll out of the area and come back then, you cannot see it anymore as the inner area of the terminal window has been re-rendered. I assume that it’s something to do with what you’re doing with hiding and showing the cursor (for example, at on our test, we saw some suspicious escape sequences in the output, which was supposed to be blank string; this pointed us to that thought too).
Again mainly Windows, as far as we know - certain machines (the latest or modern Windows distributions) we experience unpleasantly slow backspacing. It’s most noticeable if you have long sequence of chars at the command line and you want to delete a bigger amount of them. If you just press backspace for a whole you will see that although you draw your finger back the cursor continue going back deleting some more characters. In this way you cannot control how many characters should be deleted exactly.
Its preferred to give our users possibility to use some of those standard key combinations meant to tell to carry out certain action. For example, we’d like to have ctrl+c working. However, despite your library contains API for handling signals, these signals turn out unresponsive in the end. And this time it seems like it groups all platforms together (Linux, Windows, Mac) in this matter.
Note: ctrl+d is the only signal that can be currently handled.
The text was updated successfully, but these errors were encountered: