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

Buggy linewrap in Mac OSX Terminal (Mountain Lion) #3329

Closed
1st opened this issue May 16, 2013 · 13 comments
Closed

Buggy linewrap in Mac OSX Terminal (Mountain Lion) #3329

1st opened this issue May 16, 2013 · 13 comments
Milestone

Comments

@1st
Copy link

1st commented May 16, 2013

I have the same problem as described here #206

I installed readline via pip, and after this installed python via pip. I made it in virtualenv.

I see that history has wrapped lines, and sometimes I have wrapped lines if I insert line of code and navigate to middle of line.

Please fix this bug on MacOS.

@minrk
Copy link
Member

minrk commented May 16, 2013

Do you not get any message about libedit on startup? This bug has historically only affected libedit, not proper readline (note that pip does not reliably install readline, it is better to use easy_install -a readline).

@1st
Copy link
Author

1st commented May 17, 2013

Hello.

I have this message on startup:

111: RuntimeWarning: 
******************************************************************************
libedit detected - readline will not be well behaved, including but not limited to:
   * crashes on tab completion
   * incorrect history navigation
   * corrupting long-lines
   * failure to wrap or indent lines properly
It is highly recommended that you install readline, which is easy_installable:
     easy_install readline
Note that `pip install readline` generally DOES NOT WORK, because
it installs to site-packages, which come *after* lib-dynload in sys.path,
where readline is located.  It must be `easy_install readline`, or to a custom
location on your PYTHONPATH (even --user comes after lib-dyload).
******************************************************************************
  RuntimeWarning)
Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
Type "copyright", "credits" or "license" for more information.

IPython 0.13.2 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

@1st
Copy link
Author

1st commented May 17, 2013

@minrk Thank you for help!

I just deleted via pip uninstall readline and installed via easy_install readline

It's works in virtual environment. Good.

How can I fix this problem system wide? I see that I have not easy_install tool outside virtual_env.

@takluyver
Copy link
Member

You could install easy_install systemwide, or try installing readline by downloading it, untarring and running setup.py install.

I'm going to close this because the libedit problems aren't a bug we can fix. You should still be able to comment, or take it to the mailing list or Stackoverflow.

@1st
Copy link
Author

1st commented May 17, 2013

I think that installing additional package - in't good solution. Is is able to fix this problem in your project? Thanks.

@takluyver
Copy link
Member

As far as I know, no. If we could easily fix it in IPython, we would have done so a long time ago. If you can find a fix, we'd love to hear about it.

@minrk
Copy link
Member

minrk commented May 17, 2013

This is a bug in libedit / Python readline, not a bug in IPython, so there is nothing for us to fix other than trying to write a big message that hopefully people will not ignore.

@1st
Copy link
Author

1st commented May 17, 2013

I don't know what do you use in iPython internally to read lines. Do you work with lines via libedit or readline?

Do you have ability to integrate readline to iPython? Or, maybe you can make a fix for MacOS. I see this bug only on MacOS, and not found this bug on Ubuntu Linux.

I think that "maybe" problem in \r'n symbols in end of line on MacOS. If so, than you can handle this situation to replace \r\n to \n as used on Ubuntu Linux.

Thanks you for feedback.

@Carreau
Copy link
Member

Carreau commented May 17, 2013

What you ask is like asking :
"My old computer keybord do not have an @ key, I have this new black keyboard which is functional, but I prefer to keep my old one because it is white, maybe your software could come in a box with a bundled white-keyboard. ".

@takluyver
Copy link
Member

@1st: Macs can't ship with readline for licensing reasons (namely: it's GPL), so they have libedit instead to do the same job. Python's readline module therefore tries to use libedit, but it doesn't work properly. Ubuntu doesn't have the problem because it has 'real' readline. (To be fair, I don't know if libedit is still buggy, or if Apple just uses an old version of it)

I don't see us shipping readline with IPython, both for licensing reasons and technical ones.

@1st
Copy link
Author

1st commented May 17, 2013

I understand your position. I am not familiar with readline and libedit. I think that these libs allow you to read lines and go to history back and forward.

Does libedit return incorrect data to iPython, or iPython incorrect represent these data? Maybe you can handle data from libedit to work properly?

@minrk
Copy link
Member

minrk commented May 17, 2013

libedit is actually the one doing the line wrapping, not IPython. The fixes belong in libedit (or the Python readline module), and there isn't really anything IPython can do about it other than warn people that libedit is horribly broken.

@takluyver
Copy link
Member

To be clear, these don't work by returning values that IPython does things with: we just initialise readline (or libedit), which then directly controls your interaction with the terminal. So when you press up to look through your history, that's handled entirely in readline, without invoking any IPython code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants