In the shell, the text wraps around to the next line, which is acceptable.
This is not the case for Emacs windows split vertically with C-x 3 or ECB.
Try (setq truncate-partial-width-windows nil)
On my system, the emacs.py rlcompleter interface works correctly and
outputs a string, but
On Mar 26, 2005, at 12:51 PM, Steven Huwig wrote:
That had no effect on the behavior. I guess it must actually be
an issue with the size of the incoming data vs. some buffer size
in the C code ... does this sound plausible? I will write up some
scripts to incrementally generate and test Python
Stefan [EMAIL PROTECTED] writes:
Also it would be better to fix the bugs in python.el...
Which bugs?
I don't remember them all, but apparently the sub-process fails on
Windows and someone just complained to me about an instance where
indentation failed where a word boundary should be a
Steven Huwig [EMAIL PROTECTED] writes:
Anyhow, I don't think it's appropriate for Emacs to override the
user's Python startup like that.
If nothing else in the Python environment is being overridden or having
its behavior changed by Emacs, I agree.
That's the idea, apart from needing to
Stefan Monnier [EMAIL PROTECTED] writes:
I don't myself use Python, so I don't know what such a patch could break.
Can someone who's used Python (and the new pyhton-mode) confirm that this
change is a good idea?
I notice that CVS Emacs now has a python mode. Here is a small patch to
I notice that CVS Emacs now has a python mode. Here is a small patch to
etc/emacs.py to make the Python shell display objects in a readable format
(i.e. not putting long lists into a single line but rather adding newlines
where appropriate).
Presumably Eldoc and completion will fail if the
