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

Last character at the end of the input is echoed #2144

Closed
ghost opened this issue Jul 20, 2020 · 1 comment
Closed

Last character at the end of the input is echoed #2144

ghost opened this issue Jul 20, 2020 · 1 comment

Comments

@ghost
Copy link

ghost commented Jul 20, 2020

Hi! Pry is awesome and I like it! But one small issue, I dont know how to resolve.
Every time any input is evaluated in pry, I have this weird last character doubling going on.

output

Dont know whether it is a pry thing or my OS's misbehaving. Pry works very well despite the bug though. But its really getting on my nerves over time.

I've tried so far:

  • googling + looking thru the issues branch:
    and it got me this topic, similar thing but yet not the same.
  • removing my terminal settings, using default settings for pry.
  • using other terminals (urxvt, alacritty) with their default settings.
  • disabling syntax highlighting in pry.
  • customizing pry output.
  • using irb, and it works fine.

My environment:

  • Manjaro LInux Cinnamon Edition
  • Pry version: 0.13.1
  • No Pry plugins installed

However when I was testing it in virtualbox, using the exact image I installed my current OS from, this bug wasnt there.
I installed Manjaro Linux Cinnamon Edition on top of Linux Mint several months ago. Maybe settings from my previous system are messing up something, I dont know.

Honestly, I would appreciate any suggestions how to fix it. Dont wanna install a new system from scratch, exporting god knows what settings.

@ghost ghost changed the title Last character in the end of the input is echoed Last character at the end of the input is echoed Jul 20, 2020
@ghost
Copy link
Author

ghost commented Jul 27, 2020

After doing some tests on the input and reading through the pry wiki, I've come up with a solution myself. I left a mini log of what I did for anyone interested. Sorry, if my solution is not the most elegant in the world, beacuse I'm new to programing in general and Ruby in particular.

TLDR: an extra whitespace after the input was the right thing to do.
But who wants to add a whitespace every time to their input, its a pain, right? The last thing to figure out was where the input was evaluated in pry. I stumbled upon this, while I was reading through the wiki:

Indentation correction makes use of ansi codes that most terminals should support, but some may not. If you find that indentation correction is causing strange behavior on your terminal, you should consider turning this option off.

And thats what I did. I turned the correct indent option off. And from that moment pry started working as expected! But I want that auto indent correction thing back! It's super usefull!
That's when I 'hacked into' indent.rb, the correct_indentation function. I tried to plant a whitespace here and there. In most cases, it caused wrong indentation for the output in my 'broken' terminal and in the terminal in virtualbox (same GNOME terminal), where pry doesnt have that bug and works well. So the only place, where it did not break anything in both 'broken' and 'sound' terminals, was this part of the code in the if statement: move_down = "\e[#{lines}B\e[0G". Prepending \s (whitespace) to the string, fixed the issue for me! Several tests on deep nested structures returned nothing out of the ordinary in terms of indentation.

fix
Again, if it works fine in the terminal in virtualbox, why should you change something drastically. That's why this fix, that doesnt impact on anything really for me, is the easiest solution. Again, I'm not a pro. Yet :-)

@ghost ghost closed this as completed Jul 27, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants